VPN på routern fungerar, men LAN-klienterna har inget internet

Routern når internet genom sin tunnel, medan enheterna bakom den inte gör det. Vidarebefordran, översättning och returvägar är separata behörigheter.

Statusen säger att tunneln är uppe, en webbläsare på själva routern laddar sidor, och varje enhet bakom den får fortfarande tidsgräns. Kombinationen begränsar problemet till ett lager som de flesta VPN-guider aldrig nämner: routern är inte den enda värden vars paket måste överleva tunneln. Lokalt genererad trafik och vidarebefordrad trafik tar olika vägar genom samma box. Testa från en klient och skillnaden är inte längre teoretisk.

Läs felet från en LAN-värd

Börja vid enheten som misslyckas, eftersom en diagnos på routern svarar på en annan fråga. Bekräfta att klientens standardgateway är den här routern, notera dess källadress och subnät, och titta sedan på vad som lämnar routerns tunnelgränssnitt.

Om klientens adress översätts ser fjärrsidan tunneladressen, och därifrån ser allt friskt ut medan klienten fortfarande misslyckas. Om den inte översätts måste fjärrsidan känna till en väg tillbaka till klientens subnät, och många gateways har ingen sådan väg som standard. Oavsett vilket är routerns egen framgång irrelevant, eftersom dess paket genererades lokalt och aldrig gick genom vidarebefordransvägen.

Lokal trafik och vidarebefordrad trafik är olika

Linux och de flesta routerfirmware behandlar paket som uppstår i boxen annorlunda än paket som passerar genom den. Utgående kedja ser den första sorten, forward-kedjan ser den andra, och en policy anpassad för routerns egen trafik kan lämna vidarebefordran orörd.

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'

Kontrollera om vidarebefordran är aktiverad över huvud taget, och läs sedan forward-kedjan i stället för utgående kedja. En regel som tillåter den krypterade yttre anslutningen är inte en regel som tillåter dekrypterade paket att vidarebefordras, och att blanda ihop de två ger exakt detta symptom. Att tunneln är uppe bevisar bara det första.

Returvägen måste också finnas

Källöversättningen avgör om en returväg behövs. Med masquerading på tunnelgränssnittet kommer svar tillbaka till tunneladressen och routern översätter dem tillbaka. Utan den behöver fjärrgatewayen en explicit väg till klientens subnät, och dess egen policy måste tillåta den riktningen.

Notera vilken av de två lösningarna driftsättningen använder innan du ändrar något, eftersom åtgärderna pekar i motsatta riktningar. Att lägga till översättning döljer en saknad returväg och bryter program som behöver den ursprungliga källadressen. Att lägga till en returväg utan översättning misslyckas tyst när fjärrbrandväggen kastar den okända källan. Välj en, dokumentera den och få den andra sidan att stämma.

Klienternas DNS hör till samma granskning. Routerns resolver kan svara medan en klient som pekar på en annan server inte får någonting alls.

Verifiera ett tillåtet och ett nekat flöde

Efter korrigeringen, testa en ny anslutning från en klient i stället för en befintlig routersession. Bekräfta sedan att ett segment som inte ska använda tunneln fortfarande inte gör det.

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

Kontrollera den observerade källadressen i fjärränden, eftersom den berättar vilken lösning som faktiskt körs. Verifiera både namnsökning och adress, eftersom resolverns beteende är en separat väg genom samma box.

Håll reglerna begränsade till klientnäten som behöver tunneln, och stå emot frestelsen att stänga av vidarebefordringsfiltret för att en test ska gå igenom. Den ändringen lagar testet och tar bort den gräns som tunneln skulle ge. Skriv källadressen, översättningsbeslutet och returvägen i en anteckning, med datum.

Relaterade artiklar