VPN på rutaren verkar, men LAN-klientane har ikkje internett

Statusen seier at tunnelen er oppe, ein nettlesar på rutaren sjølv lastar sider, og kvar eining bak han får framleis tidsavbrot. Den kombinasjonen snevrar problemet inn til eit lag dei fleste VPN-rettleiarar aldri nemner: rutaren er ikkje den einaste verten der pakkane må overleve tunnelen. Lokalt generert trafikk og vidaresend trafikk tek ulike vegar gjennom same boksen. Test frå ein klient, og skilnaden sluttar å vere teoretisk.

Les feilen frå ein LAN-vert

Start på eininga som feilar, fordi ein diagnose på rutaren svarar på eit anna spørsmål. Stadfest at standard gatewayen til klienten er denne rutaren, noter kjeldeadressa og subnettet, og sjå deretter på kva som forlèt tunnelet sitt grensesnitt på rutaren.

Viss adressa til klienten vert omsett, ser fjernsida tunneladressa, og alt ser friskt ut derfrå medan klienten framleis feilar. Viss ho ikkje vert omsett, må fjernsida kjenne ei rute tilbake til subnettet til klienten, og mange gatewayar har inga slik rute som standard. Uansett er suksessen til rutaren sjølv irrelevant, fordi pakkane vart genererte lokalt og aldri gjekk gjennom vidaresendingsvegen.

Lokal trafikk og vidaresend trafikk er ulike

Linux og dei fleste ruterfastvarar handsamar pakkar som oppstår i boksen annleis enn pakkar som passerer gjennom han. Utgangskjeda ser den første typen, vidaresendingskjeda ser den andre, og ein politikk tilpassa trafikken til rutaren sjølv kan la vidaresendinga vere 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 vidaresending er slått på i det heile, og les deretter vidaresendingskjeda i staden for utgangskjeda. Ei regel som tillèt den krypterte ytre sambindinga er ikkje ei regel som tillèt dekrypterte pakkar å bli vidaresende, og å blande dei to gjev nøyaktig dette symptomet. At tunnelen er oppe beviser berre det første.

Returvegen må òg finnast

Kjeldeomsetjing avgjer om ein returveg er nødvendig. Med masquerading på tunnelet sitt grensesnitt kjem svar tilbake til tunneladressa, og rutaren omset dei tilbake. Utan han treng fjern-gatewayen ei eksplisitt rute til subnettet til klienten, og politikken hans må tillate den retninga.

Noter kva av dei to designa utplasseringa nyttar før du endrar noko, fordi reparasjonane peikar i motsette retningar. Å leggje til omsetjing løyner ei manglande returrute og øydelegg program som treng den opphavlege kjeldeadressa. Å leggje til ei returrute utan omsetjing feilar stille når fjernbrannmuren kastar den ukjende kjelda. Vel éin, dokumenter han, og få den andre sida til å stemme.

DNS-en til klienten høyrer til same gjennomgang. Resolveren til rutaren kan svare medan ein klient som peikar på ein annan server ikkje får noko i det heile.

Stadfest éin tillaten og éin avvist flyt

Etter korreksjonen testar du ei ny tilkopling frå ein klient i staden for ei eksisterande rutertilkopling. Stadfest deretter at eit segment som ikkje skal bruke tunnelen framleis ikkje gjer det.

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

Sjekk kjeldeadressa som vert observert i den fjerne enden, fordi ho fortel kva design som faktisk køyrer. Stadfest både namneoppslag og adresse, fordi åtferda til resolveren er ein separat veg gjennom same boksen.

Hald reglane avgrensa til klientnetta som treng tunnelen, og motstå freistinga å slå av vidaresendingsfilteret for å få éin test til å passere. Den endringa reparerer testen og fjernar grensa tunnelen skulle gje. Skriv kjeldeadressa, omsetjingsavgjerda og returruta i eitt notat, med dato.