Handshake WireGuardu funguje, ale internet nie je: vystopujte paket
Handshake dokazuje len kľúče a dostupnosť. Vystopujte jeden paket od AllowedIPs cez preposielanie, NAT a spiatočnú trasu, aby ste videli, kde sa zastaví.
Tunel je hore, wg show hlási nedávny handshake, ping na tunelovú adresu servera prejde a nič za ňou neodpovedá. Prvý impulz je vygenerovať kľúče znova alebo znova zdieľať konfiguráciu. To mení práve tú časť cesty, ktorá je už dokázateľne funkčná.
Dokončený handshake hovorí, že obe strany sa zhodli na kľúčoch, že UDP dosiahne koncový bod a že kryptografické smerovanie paket prijme. Nehovorí nič o tom, či paket potom môže opustiť server.
Preto vystopujte jeden paket namiesto hádania. Sú štyri miesta, kde môže zomrieť, a každé zanecháva inú stopu.
Čo handshake skutočne dokazuje
WireGuard je protokol UDP, ktorý nadviaže reláciu handshakeom Noise a potom šifruje pakety pre protistranu. Keď wg show zobrazí handshake starý niekoľko sekúnd a rastúci počítadlo prenosu, koncový bod, kľúče aj verejný kľúč protistrany sú všetky správne.
Čo nedokazuje: že váš klient vôbec posiela internetovú prevádzku do rozhrania, že server je ochotný ju preposielať alebo že odpoveď nájde cestu späť. To sú rozhodnutia smerovania v jadre a firewallu, a robia sa mimo tunela.
Preto je ping na tunelovú adresu servera taký zavádzajúci test. Ten paket je adresovaný samotnému serveru, takže končí lokálne. Nikdy nepotrebuje preposielanie, nikdy preklad a nikdy spiatočnú trasu z internetu.
AllowedIPs je rozhodnutie o smerovaní
Na klientovi robí AllowedIPs dve veci. Je to tabuľka kryptokľúčového smerovania, ktorá rozhoduje, ktoré cieľové adresy idú do tunela tejto protistrany, a je to zoznam zdrojových adries, ktoré protistrana od vás prijme. Ak konfigurácia klienta uvádza len 10.8.0.0/24, verejné ciele sa do rozhrania nikdy nedostanú a vaša obvyklá predvolená trasa ich odvedie mimo tunela. Potom tunel funguje dokonale a nerobí nič z toho, čo ste chceli.
Pozrite sa, čo klient skutočne nainštaloval, nie čo hovorí konfiguračný súbor:
wg show wg0 allowed-ipsip route get 1.1.1.1
Druhý príkaz je rozhodujúci. Ak odpoveď uvádza vaše fyzické rozhranie a obvyklú bránu, paket sa netuneluje a žiadna zmena na strane servera to nespraví. Pridajte 0.0.0.0/0 pre IPv4 a ::/0 pre IPv6 oddelene; pravidlo, ktoré zachytí všetko pre jednu rodinu, nechá druhú na jej pôvodnej ceste, a to je častá príčina funkčného tunela IPv4 a zaseknutého vyhľadávania IPv6.
Kde paket zomiera na bráne
Ak je trasa správna a paket stále nikam nejde, dorazí na server a tam sa zastaví. Štyri kontroly pokrývajú väčšinu brán.
Preposielanie. sysctl net.ipv4.ip_forward s návratom 0 je klasická odpoveď a mnohé distribúcie majú stále 0 ako predvolenú. Musí byť 1 a musí byť nastavené trvalo v súbore sysctl, nie príkazom, ktorý pri reštarte zmizne. Preposielanie IPv6 je samostatný prepínač.
Politika filtrovania. Reťazec FORWARD s predvolenou politikou zahadzovania zahodí tunelovú prevádzku, zatiaľ čo prevádzku k samotnému hostiteľovi prepustí, čo presne zodpovedá symptómu. Čítajte živú sadu pravidiel, nie uložený súbor: nft list ruleset alebo iptables -S.
Preklad alebo smerovanie. Klienti s privátnymi tunelovými adresami potrebujú buď zdrojový NAT na výstupnom rozhraní servera, alebo smerovaný prefix, ktorý nadradená sieť vie vrátiť. Výber medzi nimi vychádza z plánu adries. Pridať MASQUERADE do siete, ktorá váš prefix už smeruje späť, je neškodné, ale zbytočné, a vynechať ho tam, kde žiadna trasa neexistuje, nechá odpovede adresované do nesmerovateľného privátneho rozsahu.
Spiatočná cesta. V smerovaných návrhoch potrebuje nadradený router trasu ukazujúcu na váš server. Sieť poskytovateľa to môže tiež blokovať: niekoľko cloudov zapína na inštancii kontrolu zdroja a cieľa, ktorá potichu zahadzuje pakety, ktorých zdrojom nie je vlastná adresa inštancie, kým sa táto kontrola nevypne.
DNS zlyháva inak ako smerovanie
Paket na známu adresu a vyhľadanie mena sú dve rôzne zlyhania a chybové hlásenia zavádzajú opačnými smermi. Ak ping 1.1.1.1 funguje a prehliadač nič nenačíta, trasa je v poriadku a preklad mien nie. Ak zlyhá samotný ping, DNS je irelevantné a vraciate sa k predchádzajúcej časti.
wg-quick vie nastaviť resolver z riadku DNS = v konfigurácii a systemd-resolved má svoje vlastné správanie pre každé spojenie. VPN, ktorý prepíše resolver adresou dostupnou len vnútri tunela, zlyhá pri každom vyhľadaní v okamihu, keď tunel padne, čo vyzerá, akoby tunel kazil 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 |
Poradie, ktoré dáva dôkazy
Najprv vykonajte kontrolu na strane klienta, pretože je to jeden príkaz a vylúči polovicu možností. Potom overte, či má byť server vôbec výstupom do internetu; brána postavená pre privátny prístup nie je pokazená, keď verejné ciele nefungujú.
Na serveri sledujte rozhranie, kým posielate ping z klienta: tcpdump -ni wg0 icmp by mal ukázať požiadavku a tcpdump -ni eth0 icmp by mal ukázať, že odchádza, preložený alebo nie. Ak sa objaví na prvom a nikdy na druhom, zastavenie je lokálne na serveri. Ak odíde a odpoveď sa nevráti, problém je vyššie, a to je iná debata.
Na koniec zariadte, aby oprava prežila reštart. Preposielanie patrí do súboru sysctl, pravidlá firewallu do služby, ktorá ich načítava, a trasy klienta do konfigurácie, ktorá dvíha rozhranie, nie do shellu, ktorý zabudnete. Pripojte sa znova, zopakujte tie isté dva testy a overte, že sa počítadlá hýbu.