Handshake-ul WireGuard funcționează, dar subrețeaua biroului nu răspunde

Handshake-ul se încheie, wg show raportează un transfer recent, iar adresa tunelului serverului răspunde la ping. Un host din LAN-ul serverului nu. Trei condiții trebuie să fie valabile simultan: clientul trebuie să ruteze prefixul LAN în tunel, serverul trebuie să redirecționeze pachetele, iar răspunsul are nevoie de o cale înapoi. Când lipsește una din cele trei, simptomul este identic.

AllowedIPs este atât o listă de acces, cât și un tabel de rutare

Pe client, lista AllowedIPs decide atât ce poate fi trimis acelui peer, cât și ce rute instalează WireGuard. O intrare de peer care enumeră doar adresa tunelului serverului instalează o singură rută de host, așa că destinațiile din LAN nu intră niciodată în tunel. Adăugarea prefixului LAN este primul lucru de verificat și este totodată modificarea care lipsește cel mai des după o configurație copiată. Un peer extins la o rută implicită este alt design și va muta și traficul de internet al clientului.

Păstrați ruta de host și prefixul LAN ca intrări separate. Dacă biroul are două subrețele, ambele aparțin listei, iar al doilea prefix lipsă produce o defecțiune care pare selectivă, nu totală.

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

Redirecționarea și traducerea aparțin serverului

Serverul are nevoie de redirecționarea IP activată, de o regulă de redirecționare care acceptă traficul venit din tunel și de o regulă de traducere spre interfața sa LAN. Traducerea este cea care face designul să funcționeze fără a atinge fiecare host din rețeaua biroului. Răspunsurile se întorc apoi la server, nu la o adresă de care LAN-ul nu a auzit niciodată. Fără ea, fiecare host are nevoie de o rută către subrețeaua tunelului și de o regulă de firewall care o permite, ceea ce este rareori acceptabil într-o rețea administrată de altcineva.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Regulile adăugate manual dispar la repornire, așa că legați-le de interfață cu comenzile hook din configurația serverului. Un set de reguli care supraviețuiește interfeței sale este modul în care o mașină ajunge să traducă trafic pentru un tunel care nu mai există.

Când LAN-ul s-a mutat, iar regula nu

Înlocuirea unui router care renumerotează subrețeaua biroului este versiunea clasică a acestei defecțiuni. Tunelul rămâne pornit, handshake-ul rămâne proaspăt și nimic din spatele serverului nu răspunde, pentru că regula de traducere încă numește adresa veche. Scripturile de instalare încorporează adesea adresa LAN a serverului într-o regulă POSTROUTING, iar după o renumerotare acea adresă nu există pe nicio interfață. Pachetele sunt apoi rescrise către o destinație care nu poate răspunde.

iptables -t nat -n -L POSTROUTING
ip -br addr show

Comparați cele două ieșiri. O țintă de traducere care nu apare în lista interfețelor este eroarea, iar remedierea ei este o modificare de o linie după ce ați văzut-o. Regula poate locui într-o unitate generată, nu în configurația WireGuard, așa că reîncărcați acea unitate după editare și confirmați că următoarea pornire nu rescrie modificarea dumneavoastră.

Două locații din spatele NAT au nevoie de un loc de întâlnire

Când niciuna dintre părți nu acceptă conexiuni de intrare, răspunsul practic este un host mic cu o adresă publică și două interfețe WireGuard. Fiecare locație se conectează spre exterior, hostul din mijloc enumeră LAN-ul fiecărui peer în propriul AllowedIPs, iar redirecționarea transportă pachete între cele două tuneluri. Nimic din firewall-ul niciunei locații nu trebuie schimbat, motiv pentru care acest design se răspândește ușor.

Rutarea între locații păstrează adresele de sursă originale și, prin urmare, păstrează semnificativă jurnalizarea pe host. Traducerea pe hostul din mijloc este mai simplă când cele două LAN-uri se suprapun, dar cu prețul pierderii identității sursei în jurnale. Decideți ce proprietate contează înainte de a alege.

Separați straturile cu patru verificări

Faceți o verificare pe strat, în loc să schimbați trei lucruri și să sperați. Prima arată vechimea handshake-ului și contoarele pentru fiecare peer. A doua arată dacă clientul rutează într-adevăr acea destinație în tunel. A treia și a patra spun dacă cererea a ajuns și dacă o politică a eliminat-o după sosire.

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

O cerere care ajunge și nu declanșează niciun răspuns indică calea răspunsului sau hostul din LAN. O cerere care nu ajunge niciodată indică AllowedIPs sau ruta clientului. Aceste două rezultate necesită remedieri diferite, iar captura este ce le deosebește.