WireGuard-håndtrykket virker, men det er ingen internett: følg pakken

Tunnelen er oppe, wg show rapporterer et ferskt håndtrykk, du kan pinge tunneladressen til serveren, og ingenting bortenfor svarer. Den første tanken er å generere nøklene på nytt eller dele konfigurasjonen igjen. Det endrer nettopp den delen av veien som allerede er bevist at fungerer.

Et fullført håndtrykk sier at de to partene er enige om nøklene, at UDP når endepunktet, og at kryptorutingen godtar pakken. Det sier ingenting om hvorvidt pakken deretter kan forlate serveren.

Følg derfor én pakke i stedet for å gjette. Det er fire steder den kan dø, og hvert sted etterlater et ulikt spor.

Hva håndtrykket faktisk beviser

WireGuard er en UDP-protokoll som etablerer en sesjon med et Noise-håndtrykk og deretter krypterer pakker for en peer. Når wg show viser et håndtrykk som er noen sekunder gammelt og en stigende overføringsteller, er endepunktet, nøklene og peerens offentlige nøkkel alle riktige.

Det beviser ikke at klienten i det hele tatt sender internettrettet trafikk inn i grensesnittet, at serveren er villig til å videresende den, eller at et svar kan finne veien tilbake. Det er ruting- og brannmurbeslutninger i kjernen, og de tas utenfor tunnelen.

Derfor er ping mot tunneladressen til serveren en så misvisende test. Den pakken er adressert til serveren selv, så den avsluttes lokalt. Den trenger aldri videresending, aldri oversettelse og aldri en returvei fra internettet.

AllowedIPs er en rutingbeslutning

På klienten gjør AllowedIPs to jobber. Det er kryptonøkkelrutetabellen som avgjør hvilke måladresser som sendes inn i denne peerens tunnel, og det er listen over kildeadresser som peeren vil godta fra deg. Hvis klientkonfigurasjonen bare lister opp 10.8.0.0/24, kommer offentlige mål aldri inn i grensesnittet, og din vanlige standardrute fører dem utenom tunnelen. Da virker tunnelen perfekt og gjør ingenting av det du ønsket.

Se på hva klienten faktisk installerte, i stedet for hva konfigurasjonsfilen sier:

wg show wg0 allowed-ips
ip route get 1.1.1.1

Den andre kommandoen er den avgjørende. Hvis svaret navngir det fysiske grensesnittet ditt og den vanlige gatewayen, er pakken ikke tunnellert, og ingen endring på serversiden vil rette det. Legg til 0.0.0.0/0 for IPv4 og ::/0 for IPv6 hver for seg; en regel som fanger alt for den ene familien, lar den andre bli på sin opprinnelige vei, og det er en vanlig årsak til en fungerende IPv4-tunnel og et fastlåst IPv6-oppslag.

Hvor pakken dør på gatewayen

Hvis ruten er riktig og pakken fortsatt ikke kommer noe sted, ankommer den serveren og stopper der. Fire kontroller dekker de fleste gatewayer.

Videresending. sysctl net.ipv4.ip_forward som returnerer 0 er det klassiske svaret, og mange distribusjoner har fortsatt 0 som standard. Det må være 1, og settes varig i en sysctl-fil i stedet for med en kommando som forsvinner ved omstart. Videresending av IPv6 er en egen bryter.

Filterpolicyen. En FORWARD-kjede med standard drop-policy vil forkaste tunnellert trafikk mens den tillater trafikk til verten selv, noe som passer nøyaktig på symptomet. Les det levende regelsettet, ikke en lagret fil: nft list ruleset eller iptables -S.

Oversettelse eller ruting. Klienter med private tunneladresser trenger enten kilde-NAT på serverens utgående grensesnitt eller et rutet prefiks som nettverket ovenfor vet hvordan det skal returnere. Valget mellom dem følger adresseplanen. Å legge MASQUERADE til et nettverk som allerede ruter prefikset ditt tilbake, er ufarlig men meningsløst, og å utelate det der det ikke finnes noen rute, lar svar være adressert til et ikke-rutbart privat område.

Returveien. I rutede design trenger ruteren ovenfor en rute som peker på serveren din. Leverandørens nettverk kan også blokkere det: flere skyer slår på en kilde- og målkontroll på instansen, som stille slipper pakker der kilden ikke er instansens egen adresse, til den kontrollen deaktiveres.

DNS feiler annerledes enn ruting

En pakke til en kjent adresse og et navneoppslag er to forskjellige feil, og feilmeldingene villeder i motsatte retninger. Hvis ping 1.1.1.1 virker og en nettleser ikke får lastet noe, er ruten i orden og navneoppslaget ikke. Hvis selve pinget feiler, er DNS irrelevant, og du er tilbake i forrige avsnitt.

wg-quick kan sette en resolver fra linjen DNS = i konfigurasjonen, og systemd-resolved har sin egen oppførsel per lenke. En VPN som overskriver resolveren med en adresse som bare er tilgjengelig inne i tunnelen, vil feile hvert oppslag i det øyeblikket tunnelen faller, noe som ser ut som at tunnelen ødelegger internettet.

En rekkefølge som gir bevis

Kjør kontrollen på klientsiden først, fordi det er én kommando og den utelukker halvparten av mulighetene. Bekreft deretter om serveren i det hele tatt er ment som en internettutgang; en gateway bygget for privat tilgang er ikke ødelagt når offentlige mål feiler.

På serveren, følg med på grensesnittet mens du sender et ping fra klienten: tcpdump -ni wg0 icmp skal vise forespørselen, og tcpdump -ni eth0 icmp skal vise at den går ut, oversatt eller ikke. Hvis den vises på den første og aldri på den andre, er stoppen lokal på serveren. Hvis den går ut og ingen svar kommer tilbake, er problemet lenger oppe, og det er en annen samtale.

Til slutt, sørg for at rettelsen overlever en omstart. Videresending hører hjemme i en sysctl-fil, brannmurregler hører hjemme i tjenesten som laster dem, og klientruter hører hjemme i konfigurasjonen som reiser grensesnittet, ikke i et skall du vil glemme. Koble til på nytt, gjenta de samme to testene, og bekreft at tellerne beveger seg.