Den VPN um Router funktionéiert, awer d'LAN-Cliënte kommen net an d'Internet

Den Status seet, den Tunnel ass uewen, e Browser um Router selwer luedt Säiten, an all Apparat hannendrun leeft nach ëmmer an den Timeout. Dës Kombinatioun enkelt de Problem op eng Schicht, déi déi meescht VPN-Guiden ni ernimmen: den Router ass net deen eenzegen Host, deem seng Pakete mussen duerch den Tunnel kommen. Lokal generéierten Traffic an ëmgeleet Traffic huelen ënnerschiddlech Weeër duerch déiselwecht Këscht. Test vun engem Client a den Ënnerscheed ass net méi theoretesch.

Liest den Ausfall vun engem LAN-Host

Fänkt beim Apparat un, deen ausfällt, well eng Diagnos um Router op eng aner Fro äntwert. Bestätegt, datt de Standard-Gateway vum Client dësen Router ass, notéiert seng Quelladress an hiert Subnetz, a kuckt dann, wat aus dem Tunnel-Interface vum Router erauskënnt.

Wann d'Adress vum Client iwwersat gëtt, gesäit déi wäit Säit d'Tunneladress, an et gesäit vun do gesond aus, wärend de Client nach ëmmer ausfällt. Wann se net iwwersat gëtt, muss déi wäit Säit eng Route zréck an d'Client-Subnetz kennen, a vill Gatewaye hunn esou eng Route net als Standard. Souwisou ass den Erfolleg vum Router selwer irrelevant, well seng Pakete lokal generéiert goufen an ni de Weiderleedungswee duerchlaf hunn.

Lokalen an ëmgeleet Traffic sinn ënnerschiddlech

Linux a meescht Router-Firmware behandelen Pakete vun der Këscht selwer anescht wéi Pakete, déi duerch se erausginn. D'Output-Kette gesäit déi éischt Zort, d'Forward-Kette gesäit déi zweet, an eng Politik, déi op den Traffic vum Router selwer ofgestëmmt ass, kann d'Weiderleedung onberéiert loossen.

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'

Kuckt, ob d'Weiderleedung iwwerhaapt aktivéiert ass, a liest dann d'Forward-Kette amplaz vun der Output-Kette. Eng Regel, déi déi verschlësselt baussenzeg Verbindung erlaabt, ass keng Regel, déi entschlësselt Pakete weiderzeleeden erlaabt, a wann een déi zwee verwiesselt, entsteet genau dës Symptom. Datt den Tunnel uewen ass, beweist nëmmen dat éischt.

Den Zréckwee muss och existéieren

D'Iwwersetzung vun der Quell entscheet, ob en Zréckwee gebraucht gëtt. Mat Masquerading um Tunnel-Interface komme d'Äntwerten zréck op d'Tunneladress an de Router iwwersetzt se nees. Ouni et brauch de wäite Gateway eng explizit Route an d'Client-Subnetz, an seng eege Politik muss déi Richtung erlaben.

Notéiert, wéi eng vun den zwou Designen d'Installatioun benotzt, ier Dir eppes ännert, well d'Reparaturen an entgéintgesate Richtunge weisen. Iwwersetzung dobäizemaachen verstoppt eng feelend Zréckroute a brécht Applikatiounen, déi déi original Quelladress brauchen. Eng Zréckroute ouni Iwwersetzung dobäizemaachen schléit stëll fehl, wann de wäite Firewall déi onbekannt Quell verwerft. Wielt eng, dokumentéiert se a maacht déi aner Säit passend.

Den DNS vum Client gehéiert zu der selwechter Iwwerpréiwung. Den Resolver vum Router kann äntweren, während e Client, deen op en anere Server weist, guer näischt kritt.

Verifizéiert ee erlaabten an ee refuséierte Floss

No der Korrektur test eng nei Verbindung vun engem Client amplaz vun enger bestehender Router-Sessioun. Bestätegt dann, datt e Segment, dat den Tunnel net soll benotzen, en nach ëmmer net benotzt.

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

Kuckt d'Quelladress, déi um wäiten Enn observéiert gëtt, well se soot, wéi en Design tatsächlech leeft. Verifizéiert souwuel d'Namenopruff wéi och d'Adress, well d'Verhalen vum Resolver en eegene Wee duerch déiselwecht Këscht ass.

Hält d'Reegelen op d'Client-Netzwierker beschränkt, déi den Tunnel brauchen, a widersetzt Iech dem Ausschalte vum Weiderleedungsfilter, fir een Test ze bestoen. Dee Changement reparéiert den Test an hëlt d'Grenz ewech, déi den Tunnel sollte bidden. Schreift d'Quelladress, d'Entscheedung iwwer d'Iwwersetzung an de Zréckwee an eng Notiz, mat engem Datum.