VPN på ruteren virker, men LAN-klientene har ikke internett

Statusen sier at tunnelen er oppe, en nettleser på ruteren selv laster sider, og hver enhet bak den får fortsatt tidsavbrudd. Den kombinasjonen snevrer problemet inn til et lag de fleste VPN-veiledninger aldri nevner: ruteren er ikke den eneste verten hvis pakker må overleve tunnelen. Lokalt generert trafikk og videresendt trafikk tar forskjellige veier gjennom samme boks. Test fra en klient, og forskjellen slutter å være teoretisk.

Les feilen fra en LAN-vert

Start på enheten som feiler, fordi en diagnose på ruteren svarer på et annet spørsmål. Bekreft at klientens standard gateway er denne ruteren, noter kildeadressen og subnettet, og se deretter på hva som forlater ruterens tunnelgrensesnitt.

Hvis klientens adresse oversettes, ser fjernsiden tunneladressen, og alt ser friskt ut derfra mens klienten fortsatt feiler. Hvis den ikke oversettes, må fjernsiden kjenne en rute tilbake til klientens subnett, og mange gatewayer har ingen slik rute som standard. Uansett er ruterens egen suksess irrelevant, fordi pakkene ble generert lokalt og aldri gikk gjennom videresendingsveien.

Lokal trafikk og videresendt trafikk er forskjellige

Linux og de fleste ruterfastvarer behandler pakker som oppstår i boksen annerledes enn pakker som passerer gjennom den. Utgangskjeden ser den første typen, videresendingskjeden ser den andre, og en policy tilpasset ruterens egen trafikk kan la videresendingen være urørt.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

Sjekk om videresending er aktivert i det hele tatt, og les deretter videresendingskjeden i stedet for utgangskjeden. En regel som tillater den krypterte ytre forbindelsen er ikke en regel som tillater dekrypterte pakker å bli videresendt, og å forveksle de to gir nøyaktig dette symptomet. At tunnelen er oppe beviser bare det første.

Returveien må også finnes

Kildeoversetting avgjør om en returvei er nødvendig. Med masquerading på tunnelgrensesnittet kommer svar tilbake til tunneladressen, og ruteren oversetter dem tilbake. Uten den trenger fjern-gatewayen en eksplisitt rute til klientens subnett, og dens egen policy må tillate den retningen.

Noter hvilket av de to designene utplasseringen bruker før du endrer noe, fordi reparasjonene peker i motsatte retninger. Å legge til oversetting skjuler en manglende returrute og ødelegger applikasjoner som trenger den opprinnelige kildeadressen. Å legge til en returrute uten oversetting feiler stille når fjernbrannmuren forkaster den ukjente kilden. Velg én, dokumenter den, og få den andre siden til å stemme.

Klientens DNS hører til samme gjennomgang. Ruterens resolver kan svare mens en klient som peker på en annen server ikke får noe i det hele tatt.

Verifiser én tillatt og én avvist flyt

Etter korreksjonen tester du en ny tilkobling fra en klient i stedet for en eksisterende rutertilkobling. Bekreft deretter at et segment som ikke skal bruke tunnelen fortsatt ikke gjør det.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

Sjekk kildeadressen som observeres i den fjerne enden, fordi den forteller deg hvilket design som faktisk kjører. Verifiser både navneoppslag og adresse, fordi resolverens oppførsel er en separat vei gjennom samme boks.

Hold reglene begrenset til klientnettene som trenger tunnelen, og motsett deg å slå av videresendingsfilteret for å få én test til å passere. Den endringen reparerer testen og fjerner grensen tunnelen skulle gi. Skriv kildeadressen, oversettingsavgjørelsen og returruten i ett notat, med dato.