Router-VPN virker, men LAN-klienter har ingen internet

Status siger, at tunnelen er oppe, en browser på selve routeren indlæser sider, og hver enhed bag den får stadig timeout. Kombinationen indsnævrer problemet til et lag, som de fleste VPN-guides aldrig nævner: routeren er ikke den eneste vært, hvis pakker skal overleve tunnelen. Lokalt genereret trafik og videresendt trafik tager forskellige veje gennem samme boks. Test fra en klient, og forskellen holder op med at være teoretisk.

Læs fejlen fra en LAN-vært

Start ved den enhed, der fejler, fordi en diagnostik på routeren besvarer et andet spørgsmål. Bekræft, at klientens standardgateway er denne router, noter dens kildeadresse og undernet, og se derefter, hvad der forlader routerens tunnelinterface.

Hvis klientens adresse oversættes, ser den fjerne side tunneladressen, og alt ser sundt ud derfra, mens klienten stadig fejler. Hvis den ikke oversættes, skal den fjerne side kende en rute tilbage til klientens undernet, og mange gateways har ingen sådan rute som standard. I begge tilfælde er routerens egen succes irrelevant, fordi dens pakker blev genereret lokalt og aldrig gik gennem videresendelsesvejen.

Lokal trafik og videresendt trafik er forskellige

Linux og de fleste router-firmware behandler pakker, der stammer fra boksen selv, anderledes end pakker, der passerer gennem den. Output-kæden ser den første slags, forward-kæden ser den anden, og en politik, der er tilpasset routerens egen trafik, kan lade videresendelsen 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'

Kontroller, om videresendelse overhovedet er aktiveret, og læs derefter forward-kæden i stedet for output-kæden. En regel, der tillader den krypterede ydre forbindelse, er ikke en regel, der tillader videresendelse af dekrypterede pakker, og forveksling af de to giver præcis dette symptom. At tunnelen er oppe beviser kun det første.

Returvejen skal også findes

Kildeoversættelse afgør, om en returvej er nødvendig. Med masquerading på tunnelinterfacet kommer svar tilbage til tunneladressen, og routeren ophæver oversættelsen. Uden det har den fjerne gateway brug for en eksplicit rute til klientens undernet, og dens egen politik skal tillade den retning.

Noter, hvilket af de to designs udrulningen bruger, før du ændrer noget, fordi rettelserne peger i modsatte retninger. At tilføje oversættelse skjuler en manglende returrute og ødelægger programmer, der har brug for den oprindelige kildeadresse. At tilføje en returrute uden oversættelse fejler lydløst, når den fjerne firewall dropper den ukendte kilde. Vælg én, dokumentér den, og få den anden side til at matche.

Klient-DNS hører til samme gennemgang. Routerens resolver kan svare, mens en klient, der peger på en anden server, slet ikke får noget.

Bekræft én tilladt og én afvist strøm

Test efter rettelsen en ny forbindelse fra en klient i stedet for en eksisterende routersession. Bekræft derefter, at et segment, der ikke bør bruge tunnelen, stadig ikke gør det.

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

Kontroller den observerede kildeadresse i den fjerne ende, fordi den fortæller, hvilket design der faktisk kører. Bekræft også et navneopslag og ikke kun en adresse, fordi resolverens adfærd er en separat vej gennem samme boks.

Hold reglerne afgrænset til de klientnetværk, der har brug for tunnelen, og modstå fristelsen til at slå videresendelsesfilteret fra for at få én test til at bestå. Ændringen reparerer testen og fjerner den grænse, tunnelen skulle give. Skriv kildeadressen, oversættelsesbeslutningen og returruten i ét notat, med en dato.