WireGuard-handshake virker, men der er ingen internetadgang: følg pakken

Tunnelen er oppe, wg show rapporterer et nyligt handshake, du kan pinge serverens tunneladresse, og intet ud over den svarer. Instinktet er at generere nøglerne igen eller dele konfigurationen på ny. Det ændrer netop den del af vejen, som allerede er bevist at virke.

Et fuldført handshake siger, at de to parter er enige om nøgler, at UDP når endepunktet, og at den kryptografiske routing accepterer pakken. Det siger intet om, hvorvidt pakken derefter kan forlade serveren.

Så følg én pakke i stedet for at gætte. Der er fire steder, hvor den kan dø, og hvert sted efterlader et forskelligt spor.

Hvad handshaket faktisk beviser

WireGuard er en UDP-protokol, der etablerer en session med et Noise-handshake og derefter krypterer pakker til en peer. Når wg show viser et handshake, der er få sekunder gammelt, og en stigende overførsestæller, er endepunktet, nøglerne og peerens offentlige nøgle alle korrekte.

Det beviser ikke, at din klient overhovedet sender internettrafik ind i interfacet, at serveren vil videresende den, eller at et svar kan finde vejen tilbage. Det er routing- og firewallbeslutninger i kernen, og de træffes uden for tunnelen.

Derfor er ping til serverens tunneladresse så misvisende en test. Den pakke er adresseret til serveren selv, så den afsluttes lokalt. Den har aldrig brug for videresendelse, aldrig brug for oversættelse og aldrig brug for en returrute fra internettet.

AllowedIPs er en routingbeslutning

På klienten udfører AllowedIPs to opgaver. Det er den kryptonøgle-routingtabel, der afgør, hvilke destinationsadresser der sendes ind i denne peers tunnel, og det er listen over kildeadresser, som peeren vil acceptere fra dig. Hvis klientkonfigurationen kun angiver 10.8.0.0/24, kommer offentlige destinationer aldrig ind i interfacet, og din normale standardrute fører dem uden om tunnelen. Så virker tunnelen perfekt og gør intet af det, du ønskede.

Se på, hvad klienten faktisk installerede, i stedet for hvad konfigurationsfilen siger:

wg show wg0 allowed-ips
ip route get 1.1.1.1

Den anden kommando er den afgørende. Hvis svaret nævner dit fysiske interface og den normale gateway, tunneles pakken ikke, og ingen ændring på serversiden vil rette det. Tilføj 0.0.0.0/0 til IPv4 og ::/0 til IPv6 hver for sig; en regel, der fanger alt for den ene familie, lader den anden blive på sin oprindelige vej, og det er en hyppig årsag til en fungerende IPv4-tunnel og et fastlåst IPv6-opslag.

Hvor pakken dør på gatewayen

Hvis ruten er korrekt, og pakken stadig ikke når nogen steder, ankommer den til serveren og stopper der. Fire kontroller dækker de fleste gateways.

Videresendelse. sysctl net.ipv4.ip_forward der returnerer 0 er det klassiske svar, og mange distributioner har stadig 0 som standard. Den skal være 1 og sættes varigt i en sysctl-fil i stedet for med en kommando, der forsvinder ved genstart. Videresendelse af IPv6 er en separat kontakt.

Filterpolitikken. En FORWARD-kæde med standard drop-politik vil kassere tunnelert trafik, mens den tillader trafik til værten selv, hvilket passer præcis på symptomet. Læs det levende regelsæt, ikke en gemt fil: nft list ruleset eller iptables -S.

Oversættelse eller routing. Klienter med private tunneladresser har brug for enten kilde-NAT på serverens udgående interface eller et rutet prefix, som det opstrøms netværk ved, hvordan det skal returnere. Valget mellem dem følger adresseplanen. At tilføje MASQUERADE til et netværk, der allerede router dit prefix tilbage, er uskadeligt men meningsløst, og at udelade det, hvor der ikke findes en rute, efterlader svar adresseret til et ikke-rutbart privat område.

Returvejen. I rutede design har den opstrøms router brug for en rute, der peger på din server. Udbyderens netværk kan også blokere det: flere clouds aktiverer et kilde- og destinationscheck på instansen, som lydløst dropper pakker, hvis kilde ikke er instansens egen adresse, indtil dette check deaktiveres.

DNS fejler anderledes end routing

En pakke til en kendt adresse og et navneopslag er to forskellige fejl, og fejlmeddelelserne vildleder i modsatte retninger. Hvis ping 1.1.1.1 virker, og en browser ikke kan indlæse noget, er ruten fin, og navneopløsningen er ikke. Hvis selve pinget fejler, er DNS irrelevant, og du er tilbage ved det forrige afsnit.

wg-quick kan sætte en resolver ud fra linjen DNS = i konfigurationen, og systemd-resolved har sin egen adfærd per link. En VPN, der overskriver resolveren med en adresse, der kun kan nås inde i tunnelen, vil fejle hvert opslag i det øjeblik, tunnelen falder, hvilket ser ud som om tunnelen ødelægger internettet.

En rækkefølge, der giver beviser

Kør først kontrollen på klientsiden, fordi det er én kommando, og den udelukker halvdelen af mulighederne. Bekræft derefter, om serveren overhovedet er ment som en internetudgang; en gateway bygget til privat adgang er ikke i stykker, når offentlige destinationer fejler.

På serveren, hold øje med interfacet, mens du sender et ping fra klienten: tcpdump -ni wg0 icmp bør vise anmodningen, og tcpdump -ni eth0 icmp bør vise, at den forlader, oversat eller ej. Hvis den vises på den første og aldrig på den anden, er stoppet lokalt på serveren. Hvis den forlader, og der ikke kommer noget svar tilbage, er problemet længere oppe, og det er en anden samtale.

Sørg til sidst for, at rettelsen overlever en genstart. Videresendelse hører i en sysctl-fil, firewallregler hører i den tjeneste, der indlæser dem, og klientruter hører i den konfiguration, der rejser interfacet, i stedet for i en shell, du vil glemme. Genopret forbindelsen, gentag de samme to tests, og bekræft at tællerne flytter sig.