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 poslužitelja, a ništa iza nje ne odgovara. Prvi poriv je ponovno generirati ključeve ili ponovno podijeliti konfiguraciju. Time se mijenja upravo onaj dio puta za koji je već dokazano da radi.
Dovršeni handshake kaže da su se dvije strane suglasile o ključevima, da UDP dolazi do završne točke i da kripto usmjeravanje prihvaća paket. Ne kaže ništa o tome može li paket nakon toga napustiti poslužitelj.
Zato pratite jedan paket umjesto nagađanja. Postoje četiri mjesta na kojima može umrijeti, a svako ostavlja drukčiji trag.
Što handshake zapravo dokazuje
WireGuard je UDP protokol koji uspostavlja sesiju Noise handshakeom, a zatim šifrira pakete za partnera. Kada wg show prikaže handshake star nekoliko sekundi i rastući brojač prijenosa, završna točka, ključevi i javni ključ partnera svi su ispravni.
Ono što ne dokazuje jest da vaš klijent uopće šalje internetski promet u sučelje, da je poslužitelj voljan proslijediti ga ili da odgovor može pronaći put natrag. To su odluke usmjeravanja u kernelu i vatrozida, i donose se izvan tunela.
Zato je ping na tunelsku adresu poslužitelja tako zavodljiv test. Taj paket je adresiran na sam poslužitelj, pa završava lokalno. Nikada mu ne treba prosljeđivanje, nikada prijevod i nikada povratna ruta s interneta.
AllowedIPs je odluka o usmjeravanju
Na klijentu AllowedIPs obavlja dva posla. To je tablica kriptoključnog usmjeravanja koja odlučuje koje se odredišne adrese šalju u tunel ovog partnera, i to je popis 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 sučelje i vaša uobičajena zadana ruta nosi ih izvan tunela. Tada tunel radi savršeno i ne čini ništa od onoga što ste željeli.
Pogledajte što je klijent stvarno instalirao, a ne što 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še fizičko sučelje i uobičajeni gateway, paket se ne tunelira i nikakva promjena na strani poslužitelja to neće popraviti. Dodajte 0.0.0.0/0 za IPv4 i ::/0 za IPv6 odvojeno; pravilo koje hvata sve za jednu obitelj ostavlja drugu na njezinu 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 nikamo, stiže na poslužitelj 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 su na 0 po zadanom. Mora biti 1, i to trajno postavljeno u sysctl datoteci, a ne naredbom koja nestaje pri restartu. Prosljeđivanje IPv6 zaseban je prekidač.
Politika filtriranja. Lanac FORWARD sa zadanom politikom odbacivanja odbacivat će tunelski promet, dok propušta promet prema samom hostu, što se točno poklapa sa simptomom. Čitajte živi skup pravila, a ne spremljenu datoteku: nft list ruleset ili iptables -S.
Prevođenje ili usmjeravanje. Klijentima s privatnim tunelskim adresama treba ili izvorni NAT na izlaznom sučelju poslužitelja ili usmjereni prefiks koji se nadređena mreža zna vratiti. Odabir između njih slijedi plan adresa. Dodavanje MASQUERADE mreži koja već usmjerava vaš prefiks natrag bezopasno je ali besmisleno, a izostavljanje tamo gdje ruta ne postoji ostavlja odgovore adresirane na neusmjerivi privatni raspon.
Povratni put. U usmjerenim dizajnima nadređeni usmjerivač treba rutu koja pokazuje na vaš poslužitelj. Mreža pružatelja usluge također to 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 drukčije od usmjeravanja
Paket na poznatu adresu i pretraga imena dva su različita kvara, a poruke o pogreš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 kada 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 uklanja pola mogućnosti. Zatim potvrdite je li poslužitelj uopće predviđen kao izlaz na internet; gateway napravljen za privatni pristup nije pokvaren kada javna odredišta ne rade.
Na poslužitelju promatrajte sučelje 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 poslužitelju. Ako izađe, a odgovor se ne vrati, problem je uzvodno i to je drugi razgovor.
Na kraju neka popravak preživi restart. Prosljeđivanje pripada sysctl datoteci, pravila vatrozida pripadaju servisu koji ih učitava, a klijentske rute pripadaju konfiguraciji koja podiže sučelje, a ne shellu koji ćete zaboraviti. Ponovno se povežite, ponovite ista dva testa i potvrdite da se brojači pomiču.