WireGuard-handtrykket verkar, men det er ikkje internett: følg pakken

Tunnelen er oppe, wg show rapporterer eit ferskt handtrykk, du kan pinga tunneladressa til tenaren, og ingenting bortanfor svarar. Den første tanken er å generera nøklane på nytt eller dela konfigurasjonen igjen. Det endrar nettopp den delen av vegen som allereie er prova at han verkar.

Eit fullført handtrykk seier at dei to partane er samde om nøklane, at UDP når endepunktet, og at kryptorutinga godtek pakka. Det seier ingenting om pakka deretter kan forlata tenaren.

Følg derfor éi pakke i staden for å gjetta. Det er fire stader ho kan døy, og kvar stad etterlèt eit ulikt spor.

Kva handtrykket faktisk provar

WireGuard er ein UDP-protokoll som etablerer ein sesjon med eit Noise-handtrykk og krypterer deretter pakker for ein peer. Når wg show viser eit handtrykk som er nokre sekund gamalt og ein stigande overføringsteljar, er endepunktet, nøklane og den offentlege nøkkelen til peeren alle riktige.

Det provar ikkje at klienten i det heile sender internettretta trafikk inn i grensesnittet, at tenaren er viljug til å videresenda han, eller at eit svar kan finna vegen tilbake. Det er ruting- og brannmuravgjerder i kjernen, og dei vert tekne utanfor tunnelen.

Derfor er ping mot tunneladressa til tenaren ein så misvisande test. Den pakka er adressert til tenaren sjølv, så ho sluttar lokalt. Ho treng aldri videresending, aldri omsetjing og aldri ein returveg frå internettet.

AllowedIPs er eit ruteavgjerde

På klienten gjer AllowedIPs to jobbar. Det er kryptonøkkelrutetabellen som avgjer kva måladresser som vert sende inn i tunnelen til denne peeren, og det er lista over kjeldeadresser som peeren vil godta frå deg. Viss klientkonfigurasjonen berre listar opp 10.8.0.0/24, kjem offentlege mål aldri inn i grensesnittet, og den vanlege standardruta di fører dei utanom tunnelen. Då verkar tunnelen perfekt og gjer ingenting av det du ønskte.

Sjå på kva klienten faktisk installerte, i staden for kva konfigurasjonsfila seier:

wg show wg0 allowed-ips
ip route get 1.1.1.1

Den andre kommandoen er den avgjerande. Viss svaret namngjev det fysiske grensesnittet ditt og den vanlege gatewayen, er pakka ikkje tunnellert, og inga endring på tenarsida vil retta det. Legg til 0.0.0.0/0 for IPv4 og ::/0 for IPv6 kvar for seg; ei regel som fangar alt for den eine familien, lèt den andre bli på den opphavlege vegen sin, og det er ein vanleg årsak til ein fungerande IPv4-tunnel og eit fastlåst IPv6-oppslag.

Kvar pakka døyr på gatewayen

Viss ruta er riktig og pakka framleis ikkje kjem nokon stad, kjem ho til tenaren og stoppar der. Fire kontrollar dekkjer dei fleste gatewayar.

Videresending. sysctl net.ipv4.ip_forward som returnerer 0 er det klassiske svaret, og mange distribusjonar har framleis 0 som standard. Det må vera 1, og setjast varig i ei sysctl-fil i staden for med ein kommando som forsvinn ved omstart. Videresending av IPv6 er ein eigen brytar.

Filterpolicyen. Ei FORWARD-kjede med standard drop-policy vil kasta tunnellert trafikk medan ho tillèt trafikk til verten sjølv, noko som passar nøyaktig på symptomet. Les det levande regelsettet, ikkje ei lagra fil: nft list ruleset eller iptables -S.

Omsetjing eller ruting. Klientar med private tunneladresser treng anten kjelde-NAT på det utgåande grensesnittet til tenaren eller eit ruta prefiks som nettet ovanfor veit korleis det skal returnera. Valet mellom dei følgjer adresseplanen. Å leggja MASQUERADE til eit nettverk som allereie rutar prefikset ditt tilbake, er ufarleg men meiningslaust, og å utelata det der det ikkje finst noka rute, lèt svar vera adresserte til eit ikkje-rutbart privat område.

Returvegen. I ruta design treng rutaren ovanfor ei rute som peikar på tenaren din. Nettverket til leverandøren kan også blokkera det: fleire skyer slår på ein kjelde- og målkontroll på instansen, som stille slepp pakker der kjelda ikkje er den eigne adressa til instansen, til den kontrollen vert deaktivert.

DNS feilar annleis enn ruting

Ei pakke til ei kjend adresse og eit namneoppslag er to ulike feil, og feilmeldingane villeder i motsette retningar. Viss ping 1.1.1.1 verkar og ein nettlesar ikkje får lasta noko, er ruta i orden og namneoppslaget ikkje. Viss sjølve pinget feilar, er DNS irrelevant, og du er tilbake i førre avsnitt.

wg-quick kan setja ein resolver frå linja DNS = i konfigurasjonen, og systemd-resolved har si eiga åtferd per lenkje. Ein VPN som skriv over resolveren med ei adresse som berre er tilgjengeleg inne i tunnelen, vil feila kvart oppslag i det augneblinken tunnelen fell, noko som ser ut som at tunnelen øydelegg internettet.

Ein rekkjefølgje som gir prov

Køyr kontrollen på klientsida først, fordi det er éin kommando og han utelukkar halvparten av moglegheitene. Stadfest deretter om tenaren i det heile er meint som ein internettutgang; ein gateway bygd for privat tilgang er ikkje øydelagd når offentlege mål feilar.

På tenaren, følg med på grensesnittet medan du sender eit ping frå klienten: tcpdump -ni wg0 icmp skal visa førespurnaden, og tcpdump -ni eth0 icmp skal visa at han går ut, omsett eller ikkje. Viss han visest på den første og aldri på den andre, er stoppen lokal på tenaren. Viss han går ut og ingen svar kjem tilbake, er problemet lenger oppe, og det er ein annan samtale.

Til slutt, sørg for at rettinga overlever ein omstart. Videresending høyrer heime i ei sysctl-fil, brannmurreglar høyrer heime i tenesta som lastar dei, og klientruter høyrer heime i konfigurasjonen som reiser grensesnittet, ikkje i eit skal du vil gløyma. Kopla til på nytt, gjenta dei same to testane, og stadfest at teljarane rører seg.