VPN op de router werkt, maar LAN-clients hebben geen internet

De status zegt dat de tunnel actief is, een browser op de router zelf laadt pagina's, en elk apparaat erachter loopt nog steeds vast op een time-out. Die combinatie beperkt het probleem tot een laag die de meeste VPN-gidsen nooit noemen: de router is niet de enige host waarvan de pakketten de tunnel moeten overleven. Lokaal gegenereerd verkeer en doorgestuurd verkeer nemen verschillende paden door dezelfde doos. Test vanaf een client en het verschil is niet langer theoretisch.

Lees de storing vanaf een LAN-host

Begin bij het apparaat dat faalt, want een diagnose op de router beantwoordt een andere vraag. Controleer dat de standaardgateway van de client deze router is, noteer het bronadres en het subnet, en kijk dan wat de tunnelinterface van de router verlaat.

Wordt het adres van de client vertaald, dan ziet de externe kant het tunneladres, en van daaruit ziet alles er gezond uit terwijl de client nog steeds faalt. Wordt het niet vertaald, dan moet de externe kant een route terug naar het subnet van de client kennen, en veel gateways hebben zo'n route standaard niet. Hoe dan ook is het succes van de router zelf irrelevant, want zijn pakketten zijn lokaal gegenereerd en hebben nooit het doorstuurpad gevolgd.

Lokaal verkeer en doorgestuurd verkeer verschillen

Linux en de meeste routerfirmware behandelen pakketten die in de doos zelf ontstaan anders dan pakketten die erdoorheen gaan. De output-keten ziet het eerste soort, de forward-keten ziet het tweede, en een beleid dat is toegesneden op het verkeer van de router zelf kan het doorsturen onaangeroerd laten.

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'

Controleer of doorsturen überhaupt is ingeschakeld, en lees dan de forward-keten in plaats van de output-keten. Een regel die de versleutelde buitenverbinding toestaat is geen regel die toestaat dat ontsleutelde pakketten worden doorgestuurd, en die twee verwarren levert precies dit symptoom op. Dat de tunnel actief is, bewijst alleen het eerste.

De retourroute moet ook bestaan

Brontvertaling bepaalt of een retourroute nodig is. Met masquerading op de tunnelinterface komen antwoorden terug op het tunneladres en vertaalt de router ze terug. Zonder dat heeft de externe gateway een expliciete route naar het subnet van de client nodig, en moet zijn eigen beleid die richting toestaan.

Noteer welk van de twee ontwerpen de inzet gebruikt voordat je iets wijzigt, want de reparaties wijzen in tegengestelde richtingen. Vertaling toevoegen verbergt een ontbrekende retourroute en breekt toepassingen die het oorspronkelijke bronadres nodig hebben. Een retourroute toevoegen zonder vertaling faalt stil wanneer de externe firewall de onbekende bron laat vallen. Kies er één, documenteer het en laat de andere kant overeenkomen.

Client-DNS hoort bij dezelfde beoordeling. De resolver van de router kan antwoorden terwijl een client die naar een andere server wijst helemaal niets krijgt.

Verifieer één toegestane en één geweigerde stroom

Test na de correctie een nieuwe verbinding vanaf een client in plaats van een bestaande routersessie. Bevestig daarna dat een segment dat de tunnel niet zou moeten gebruiken dat nog steeds niet doet.

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

Controleer het waargenomen bronadres aan de externe kant, want dat vertelt je welk ontwerp werkelijk draait. Verifieer zowel naamopzoeking als adres, want het gedrag van de resolver is een apart pad door dezelfde doos.

Houd regels beperkt tot de clientnetwerken die de tunnel nodig hebben, en weersta de verleiding om het doorstuurfilter uit te schakelen om één test te laten slagen. Die wijziging repareert de test en verwijdert de grens die de tunnel zou moeten bieden. Schrijf het bronadres, de vertaalbeslissing en de retourroute in één notitie, met een datum.