WireGuard handshake radi, ali interneta nema: pratite paket
Handshake dokazuje samo ključeve i dostupnost. Pratite jedan paket od AllowedIPs kroz prosljeđivanje, NAT i povratnu rutu da vidite gdje se zaustavlja.
Tunel je podignut, wg show prijavljuje nedavni handshake, možete pingati tunelsku adresu servera, a ništa iza nje ne odgovara. Prva pomisao je regenerisati ključeve ili ponovo podijeliti konfiguraciju. Time se mijenja upravo onaj dio puta za koji je već dokazano da radi.
Završen handshake kaže da se dvije strane slažu o ključevima, da UDP stiže do krajnje tačke i da kripto-rutiranje prihvata paket. Ne kaže ništa o tome može li paket nakon toga napustiti server.
Zato pratite jedan paket umjesto nagađanja. Postoje četiri mjesta na kojima može umrijeti, a svako ostavlja drugačiji trag.
Šta handshake zapravo dokazuje
WireGuard je UDP protokol koji uspostavlja sesiju Noise handshakeom, a zatim šifruje pakete za partnera. Kada wg show prikaže handshake star nekoliko sekundi i rastući brojač prijenosa, krajnja tačka, ključevi i javni ključ partnera svi su ispravni.
Ono što ne dokazuje jeste da vaš klijent uopšte šalje internetski saobraćaj u interfejs, da je server voljan da ga proslijedi ili da odgovor može naći put nazad. To su odluke rutiranja u kernelu i firewall-a, i donose se izvan tunela.
Zato je ping na tunelsku adresu servera tako obmanjujući test. Taj paket je adresiran na sam server, pa se završava lokalno. Nikada mu ne treba prosljeđivanje, nikada prijevod i nikada povratna ruta s interneta.
AllowedIPs je odluka o rutiranju
Na klijentu AllowedIPs obavlja dva posla. To je tabela kriptoključnog rutiranja koja odlučuje koje se odredišne adrese šalju u tunel ovog partnera, i to je lista izvornih adresa koje će partner prihvatiti od vas. Ako konfiguracija klijenta navodi samo 10.8.0.0/24, javna odredišta nikada ne ulaze u interfejs i vaša uobičajena zadata ruta nosi ih izvan tunela. Tada tunel radi savršeno i ne čini ništa od onoga što ste htjeli.
Pogledajte šta je klijent zaista instalirao, a ne šta piše u konfiguracijskoj datoteci:
wg show wg0 allowed-ipsip route get 1.1.1.1
Druga naredba je odlučujuća. Ako odgovor navodi vaš fizički interfejs i uobičajeni gateway, paket se ne tunelira i nikakva promjena na strani servera to neće popraviti. Dodajte 0.0.0.0/0 za IPv4 i ::/0 za IPv6 odvojeno; pravilo koje hvata sve za jednu familiju ostavlja drugu na njenom izvornom putu, a to je čest uzrok tunela IPv4 koji radi i zaglavljenog IPv6 pretraživanja.
Gdje paket umire na gatewayu
Ako je ruta ispravna, a paket i dalje ne ide nikuda, on stiže na server i tamo se zaustavlja. Četiri provjere pokrivaju većinu gatewaya.
Prosljeđivanje. sysctl net.ipv4.ip_forward koji vraća 0 klasičan je odgovor, a mnoge distribucije i dalje imaju 0 kao zadanu vrijednost. Mora biti 1, i to trajno postavljeno u sysctl datoteci, a ne naredbom koja nestaje pri restartu. Prosljeđivanje IPv6 odvojen je prekidač.
Politika filtriranja. Lanac FORWARD sa zadanom politikom odbacivanja odbacivat će tunelski saobraćaj, dok propušta saobraćaj prema samom hostu, što se tačno poklapa sa simptomom. Čitajte živi skup pravila, a ne sačuvanu datoteku: nft list ruleset ili iptables -S.
Prevođenje ili rutiranje. Klijentima s privatnim tunelskim adresama treba ili izvorni NAT na izlaznom interfejsu servera ili rutiran prefiks koji nadređena mreža zna vratiti. Izbor između njih slijedi plan adresa. Dodavanje MASQUERADE mreži koja već rutira vaš prefiks natrag je bezopasno, ali besmisleno, a izostavljanje tamo gdje ruta ne postoji ostavlja odgovore adresirane na nerutabilan privatni raspon.
Povratni put. U rutiranim dizajnima nadređenom ruteru treba ruta koja pokazuje na vaš server. Provajderska mreža to također može blokirati: nekoliko oblaka uključuje provjeru izvora i odredišta na instanci, koja tiho odbacuje pakete čiji izvor nije vlastita adresa instance, dok se ta provjera ne isključi.
DNS pada drugačije od rutiranja
Paket na poznatu adresu i pretraga imena dva su različita kvara, a poruke o grešci obmanjuju u suprotnim smjerovima. Ako ping 1.1.1.1 radi, a preglednik ne može učitati ništa, ruta je u redu, a razrješavanje imena nije. Ako sam ping ne uspije, DNS je nebitan i vraćate se na prethodno poglavlje.
wg-quick može postaviti resolver iz retka DNS = u konfiguraciji, a systemd-resolved ima svoje ponašanje po vezi. VPN koji prepiše resolver adresom dostupnom samo unutar tunela neuspješno će izvršiti svaku pretragu u trenutku kad tunel padne, što izgleda kao da tunel kvari internet.
| Symptom | Layer to inspect |
|---|---|
| Tunnel address pings, nothing else does | Client route, then gateway forwarding |
| Public IP pings, hostnames fail | Resolver selection and reachability |
| Handshake completes, no reply ever | FORWARD policy or missing NAT on the server |
| Small requests work, large transfers stall | MTU and TCP MSS clamping |
Redoslijed koji daje dokaze
Prvo napravite provjeru na strani klijenta, jer je to jedna naredba i eliminira pola mogućnosti. Zatim potvrdite da je server uopšte predviđen kao izlaz na internet; gateway napravljen za privatni pristup nije pokvaren kada javna odredišta ne rade.
Na serveru gledajte interfejs dok šaljete ping s klijenta: tcpdump -ni wg0 icmp treba pokazati zahtjev, a tcpdump -ni eth0 icmp treba pokazati da izlazi, preveden ili ne. Ako se pojavi na prvom i nikada na drugom, zaustavljanje je lokalno na serveru. Ako izađe, a odgovor se ne vrati, problem je uzvodno i to je drugi razgovor.
Na kraju neka popravka preživi restart. Prosljeđivanje pripada sysctl datoteci, firewall pravila pripadaju servisu koji ih učitava, a klijentske rute pripadaju konfiguraciji koja podiže interfejs, a ne shellu koji ćete zaboraviti. Ponovo se povežite, ponovite ista dva testa i potvrdite da se brojači pomjeraju.