înregistrare Logare
Puncte:2
avatar Server

Cum se configurează wireguard pentru a redirecționa adresa IP a clientului (cu gateway)?

drapel jp
Daniel

Încerc să configurez wireguard să funcționeze ca server VPN. Problema principală este că gateway-ul înaintează numai IP-ul serverului VPN către alt server, nu IP-ul clientului meu.

Configurația mea este următoarea:

                                                        - server A (10.10.0.4)
                                                      /
CLIENT (10.10.1.3) -> server wireguard (10.10.1.2) -- 
                                       (10.10.0.2) \
                                                        - server B (10.10.0.3)

Serverul wireguard rulează pe o mașină cu două interfețe:

  • eth0 (10.10.0.2)
  • wg0 (10.10.1.2)

Când conexiunea VPN este stabilită, mă pot conecta la serverul A și serverul B (prin ssh). Problema este că adresa IP a serverului wireguard este redirecționată (nat) către serverul A și B. Logat prin ssh îmi arată de fiecare dată că ultima conexiune a venit din 10.10.0.2 (pe serverul A și B). Dar pe serverul wireguard, ultimul IP conectat este IP-ul meu client real (10.10.1.3).

Ceea ce încerc să fac este să configurez wireguard, astfel încât IP-ul meu (10.10.1.3) să fie redirecționat corect către serverul A și B.

Acesta este fișierul meu de configurare client wireguard:

[Interfață]
PrivateKey = xxx
Adresa = 10.10.1.3/24
DNS = 10.10.0.2, 8.8.8.8

[Peer]
PublicKey = XXX
AllowedIPs = 10.10.0.0/24
Punct final = xxx.xxx.xxx.xxx:41194
PersistentKeepalive = 15

Configurația serverului meu wireguard (wg0.conf):

[Interfață]
Adresa = 10.10.1.2/24

## Portul serverului meu VPN ##
ListenPort = 41194

PrivateKey = xxx

# Configurare Internet Gateway: nat wg1 pe internet pe ens10
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
## Cheie publică VPN pentru desktop/client ##
PublicKey = xxx

AllowedIPs = 10.10.1.3/32

Bănuiesc că configurația iptables este greșită, din cauza nat/MASQUERADE, dar nu am reușit să configurez corect gateway-ul.

Apreciez ajutorul vostru.

Actualizați

Se execută pe serverul A (la fel pe B)

link ip -br; adresa ip -br; ruta ip

Returnări (IP-ul public este mascat):

necunoscut 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0 UP 96:00:01:29:d6:9b <BROADCAST,MULTICAST,UP,LOWER_UP>
ens10 UP 86:00:00:08:9c:c5 <BROADCAST,MULTICAST,UP,LOWER_UP>
lo NECUNOSCUT 127.0.0.1/8 ::1/128
eth0 UP 10.10.0.3/32 fe80::9400:1ff:fe29:d69b/64
ens10 UP 49.xxx.xxx.xxx/32 2a01:xxx:xxx:xxx::1/64 fe80::8400:ff:fe08:9cc5/64
implicit prin 172.31.1.1 dev ens10 proto dhcp src 49.xxx.xxx.xxx metric 100
10.10.0.0/16 prin 10.10.0.1 dev eth0
10.10.0.1 dev eth0 scope link
172.31.1.1 dev ens10 proto dhcp scope link src 49.xxx.xxx.xxx metric 100
492
0 + 0
Puncte:1
A.B avatar Server
drapel cl
A.B

NAT se face prin configurație, așa că obțineți NAT așa cum este cerut. Pentru a evita utilizarea NAT trebuie să:

  • asigurați-vă că serverele finale A și B au o rută reală înapoi la client

    Dacă nu este cazul, adăugați cel puțin asta pe A și B (dacă rulați Linux):

    ruta ip adăugați 10.10.1.3/32 prin 10.10.0.2

    UPDATE: Configurarea de rutare a OP (într-un nor) face ca traficul lui A și B către 10.10.0.2 (sau chiar între ele) să treacă printr-un router suplimentar 10.10.0.1 (parte din rețea cloud). Deci traseul a trebuit să fie adăugat pe această porțiune, după cum a confirmat OP.

  • eliminați NAT pe serverul wireguard

    Eliminați doar al doilea iptables comenzile din cele două WireGuard Documenta și Documenta configurație și asigurați-vă că nu a mai rămas o intrare adăugată anterior, rulând doar de această dată:

    iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

  • opțional: actualizare IP-uri permise pe client

    Dacă clientul dorește să acceseze serverul wireguard utilizând adresa serverului de pe partea sa de tunel, mai degrabă decât partea eth0, sau să fie sigur că ICMP trimis înapoi de serverul wireguard sunt primite (de exemplu: pentru a obține traceroute la serverul A care lucrează fără * * *), 10.10.1.2 ar trebui să fie, de asemenea, în IP-uri permise a satisface Rutarea criptokey-ului WireGuard.

    Înlocuiește pe client:

    AllowedIPs = 10.10.0.0/24

    cu:

    IP-uri permise = 10.10.1.2,10.10.0.0/24
0 + 0
drapel jp
Daniel
Vă mulțumim pentru răspunsul dumneavoastră. Am încercat să adaug ruta IP pe ambele servere (ip route add 10.10.1.3/32 prin 10.10.0.2), dar am primit doar o eroare: „Nexthop are gateway invalid”. Se pare că ar putea exista o configurare greșită a rețelei?!
0
Răspunde
drapel jp
Daniel
Îmi voi actualiza întrebarea pentru a furniza rezultatul linkului ```ip -br; adresa ip -br; ruta ip```
0
Răspunde
A.B avatar
drapel cl
A.B
Cu informațiile adăugate: tot traficul pentru 10.10.0.0/16 care ar fi de obicei trafic LAN este direcționat prin 10.10.0.1, fără a lăsa trafic LAN pe serverul A sau B care ar putea avea excepții. Apoi, traseul trebuie adăugat pe 10.10.0.1, care nu apare nicăieri în întrebare.
0
Răspunde
drapel jp
Daniel
Mulțumesc că m-ai îndreptat în direcția corectă. 10.10.0.1 nu este complet scăpat de sub control. Este o rețea cloud, dar am adăugat o rută de la 10.10.1.0/24 la 10.10.0.2. Acum merge perfect. Mulțumiri!
1
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.