Rokovanje WireGuard deluje, a interneta ni: sledite paketu
Rokovanje dokazuje le ključe in dosegljivost. Sledite enemu paketu od AllowedIPs skozi posredovanje, NAT in povratno pot, da vidite, kje se ustavi.
Tunel je vzpostavljen, wg show poroča o nedavnem rokovanju, lahko pingate naslov tunela strežnika, in nič onkraj njega se ne odziva. Prvi nagon je znova ustvariti ključe ali znova deliti konfiguracijo. To spremeni natanko tisti del poti, za katerega je že dokazano, da deluje.
Zaključeno rokovanje pove, da se obe strani strinjata o ključih, da UDP doseže končno točko in da kriptografsko usmerjanje paket sprejme. Ne pove ničesar o tem, ali lahko paket nato zapusti strežnik.
Zato sledite enemu paketu, namesto da ugibate. Obstajajo štiri mesta, kjer lahko umre, in vsako pusti drugačno sled.
Kaj rokovanje dejansko dokaže
WireGuard je protokol UDP, ki vzpostavi sejo z rokovanjem Noise in nato šifrira pakete za drugega. Ko wg show prikaže rokovanje, staro nekaj sekund, in naraščajoči števec prenosa, so končna točka, ključi in javni ključ drugega vsi pravilni.
Česar ne dokaže: da vaš odjemalec sploh pošilja internetni promet v vmesnik, da je strežnik pripravljen posredovati in da lahko odgovor najde pot nazaj. To so odločitve usmerjanja v jedru in požarnega zidu, sprejemajo pa se zunaj tunela.
Zato je ping na naslov tunela strežnika tako zavajajoč test. Ta paket je naslovljen na sam strežnik, zato se konča lokalno. Nikoli ne potrebuje posredovanja, nikoli prevajanja in nikoli povratne poti z interneta.
AllowedIPs je odločitev o usmerjanju
Na odjemalcu AllowedIPs opravlja dve nalogi. To je tabela kriptoključnega usmerjanja, ki odloča, kateri ciljni naslovi gredo v tunel tega drugega, in to je seznam izvornih naslovov, ki jih bo drugi sprejel od vas. Če konfiguracija odjemalca navaja le 10.8.0.0/24, javni cilji nikoli ne vstopijo v vmesnik in vaša običajna privzeta pot jih odnese mimo tunela. Takrat tunel deluje brezhibno in ne naredi ničesar od tega, kar ste želeli.
Poglejte, kaj je odjemalec dejansko namestil, namesto kaj piše v konfiguracijski datoteki:
wg show wg0 allowed-ipsip route get 1.1.1.1
Drugi ukaz je odločilen. Če odgovor navaja vaš fizični vmesnik in običajni prehod, paket ni tuneliran in nobena sprememba na strežniku tega ne bo popravila. Dodajte 0.0.0.0/0 za IPv4 in ::/0 za IPv6 ločeno; pravilo, ki ujame vse za eno družino, pusti drugo na njeni prvotni poti, in to je pogost vzrok delujočega tunela IPv4 in zataknjenega iskanja IPv6.
Kje paket umre na prehodu
Če je pot pravilna in paket še vedno ne gre nikamor, prispe na strežnik in se tam ustavi. Štiri preverjanja pokrijejo večino prehodov.
Posredovanje. sysctl net.ipv4.ip_forward, ki vrne 0, je klasičen odgovor, in številne distribucije so privzeto še vedno na 0. Biti mora 1 in trajno nastavljen v datoteki sysctl, ne z ukazom, ki ob ponovnem zagonu izgine. Posredovanje IPv6 je ločeno stikalo.
Politika filtriranja. Veriga FORWARD s privzeto politiko zavrnitve bo zavrgla promet tunela, hkrati pa dovolila promet do gostitelja samega, kar se natančno ujema s simptomom. Berite živi nabor pravil, ne shranjene datoteke: nft list ruleset ali iptables -S.
Prevajanje ali usmerjanje. Odjemalci z zasebnimi naslovi tunela potrebujejo bodisi izvorni NAT na izhodnem vmesniku strežnika bodisi usmerjeno predpono, ki jo nadrejeno omrežje zna vrniti. Izbira med njima sledi načrtu naslovov. Dodajanje MASQUERADE v omrežje, ki vašo predpono že usmerja nazaj, je neškodljivo, a nesmiselno, izpuščanje tam, kjer poti ni, pa pusti odgovore naslovljene v neusmerljiv zasebni razpon.
Povratna pot. V usmerjenih zasnovah potrebuje nadrejeni usmerjevalnik pot, ki kaže na vaš strežnik. Tudi omrežje ponudnika lahko to blokira: več oblakov vklopi preverjanje izvora in cilja na primerku, ki tiho zavrže pakete, katerih izvor ni lastni naslov primerka, dokler preverjanje ni izklopljeno.
DNS odpove drugače kot usmerjanje
Paket na znan naslov in iskanje imena sta dve ločeni okvari, sporočila o napakah pa zavajajo v nasprotnih smereh. Če ping 1.1.1.1 deluje in brskalnik ne naloži ničesar, je pot v redu, razreševanje imen pa ne. Če sam ping odpove, je DNS nepomemben in vrnili ste se v prejšnji razdelek.
wg-quick lahko nastavi razreševalnik iz vrstice DNS = v konfiguraciji, systemd-resolved pa ima svoje vedenje za vsako povezavo. VPN, ki prepiše razreševalnik z naslovom, dosegljivim le znotraj tunela, bo vsako iskanje spodletelo v trenutku, ko tunel pade, kar je videti, kot 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 |
Vrstni red, ki daje dokaze
Najprej izvedite preverjanje na strani odjemalca, ker je to en ukaz in izloči polovico možnosti. Nato potrdite, ali je strežnik sploh mišljen kot izhod v internet; prehod, zgrajen za zasebni dostop, ni pokvarjen, ko javni cilji spodletijo.
Na strežniku opazujte vmesnik, medtem ko pošiljate ping z odjemalca: tcpdump -ni wg0 icmp bi moral pokazati zahtevo, tcpdump -ni eth0 icmp pa bi moral pokazati, da odhaja, preveden ali ne. Če se pojavi na prvem in nikoli na drugem, je ustavitev lokalna na strežniku. Če odide in odgovor se ne vrne, je težava višje, in to je drug pogovor.
Na koncu poskrbite, da popravek preživi ponovni zagon. Posredovanje spada v datoteko sysctl, pravila požarnega zidu v storitev, ki jih naloži, poti odjemalca pa v konfiguracijo, ki dvigne vmesnik, ne v lupino, ki jo boste pozabili. Znova se povežite, ponovite ista dva testa in potrdite, da se števci premikajo.