VPN-Clienten erreechen de Server, awer net d'LAN: wéi eng Léisung?

De Client pingt d'Tunneladress vum OpenVPN-Server a kritt eng Äntwert, probéiert dann en Host am LAN vum Server a kritt näischt. Dës Spléckung verengt de Feeler staark: den Tunnel steet, d'Weiderleitung funktionéiert wahrscheinlech, an d'Äntwert verléisst d'Netz duerch eng Dier, déi net zréckféiert. Et gëtt dräi Léisungen, an déi richteg hängt dovun of, wat Dir kontrolléiert a wat Dir sidd bereet opzeginn. Beäntwert déi dräi Froen hei drënner an der Rei, an d'Wiel ass keng Saach vum Goût méi.

Als éischt feststellen, a wéi eng Richtung de Feeler läit

D'Ufro kënnt um Tunnelinterface un, mat enger Quelladress aus dem VPN-Pool. De Server leet se un den LAN-Host weider, an deen Host äntwert där Gateway, déi seng eegen Tabell nennt, normalerweis dem LAN-Router. Huet de Router keng Route fir de Pool, stierft d'Äntwert do oder wandert Richtung Internet.

Test béid Maschinnen, ier Dir eng vun deenen zwee ännert. Frot um Server d'Routingtabell, wéi si e Client erreeche géif; frot um LAN-Host, wéi hien déi selwecht Adress erreeche géif. Déi éischt Nokuckt weist meeschtens op den Tunnel an déi zweet op de LAN-Router, an deen Ënnerscheed ass de Feeler an enger Zeil. Zwou Nokuckten si méi bëlleg wéi en Firewall-Audit an si klären d'Richtung vum Problem.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Wann den LAN-Host schonn op de VPN-Server weist, ass Äre Problem eng Firewallregel oder eng MTU-Grenz an net en feelende Réckwee. Füügt keng Route bäi, fir e Filter ze flécken.

Fro een: kënnt Dir den Router vum wäite LAN änneren?

Wann den LAN-Router Ären ass, ass eng statesch Route fir de VPN-Pool mat der LAN-Adress vum VPN-Server als nächsten Hop déi propper Äntwert. Si hält d'Quelladresse vun de Cliente ganz, wat zielt, wann LAN-Hosten no Adress loggen, filteren oder d'Vitesse begrenzen. Si brauch och keng Iwwersetzung um Server, sou datt den Tunnel en pure Routingwee bleift. D'Verflichtung, déi si schaaf, ass Dokumentatioun, well Pool, Route a Serverkonfiguratioun mussen iwwereneestëmmen.

Si versot stëll den Dag, wou een de Pool ännert. Schreift de Wäert eng Kéier op a behandelt eng Ännerung op enger vun den dräi Plazen als Ännerung un allen dräi.

En NAS oder en Layer 3-Switch, deen den Déngscht hostet, brauch déiselwecht Route, ausser hie schéckt alles iwwer e Router, deen eng huet. Kontrolléiert d'Apparat, dat d'Subnetz terminéiert, net nëmmen dat op der Internetsäit. Kleng Netzwierker hu meeschtens dräi Apparaten mat enger Meenung zum Routing.

Fro zwee: däerf d'LAN d'Clientadressen net méi gesinn?

Wann den Router engem aneren gehéiert, brauch d'Iwwersetzung um VPN-Server keng Zesummenaarbecht. Den LAN-Host gesäit d'LAN-Adress vum Server, äntwert hir, an de Server iwwersetzt zréck. Dowéinst behuele sech Apparater a NAT-baséiert Remote-Access-Rollen esou.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

De Präis ass d'Zouschräiwung: Adressen pro Client verschwannen aus den LAN-Loggen. All Allowlist um LAN-Host muss dann de Server nennen amplaz vum Pool.

Wielt d'Iwwersetzung, wann Zesummenaarbecht net verfügbar ass, net wann se just onbequeem ass. Si verstoppt de Client virun all zukünfteg Enquête, och deenen, wou Dir musst wëssen, wéi ee Laptop eng Verbindung opgemaach huet. Si kann och Protokoller briechen, déi Adressen an d'Payloads abauen, well d'Iwwersetzung am Header sëtzt. Keng vun den zwou Optioune méi fortgeschratt; si beäntweren ënnerschiddlech Froen iwwer d'Eegentum.

Fro dräi: ass de Server selwer Client vun engem aneren Tunnel?

Stellt Iech déi aner Topologie vir: de VPN-Server wielt sech och bei engem kommerziellen Ubidder an, huet also zwee Tunnelen an zwou Sätz Adressen. Verkéier, deen hien u seng eege Clienten weiderleet, verléisst d'Netz iwwer den Ubidder, an deen routeet Äntwerten net zréck op Pooladressen. Dowéinst verschwanne Äntwerten, obwuel béid Tunnelen gesond sinn.

D'Léisung ass, och den ausgängegen Tunnel ze maskéieren, sou datt den Ubidder just d'Tunneladress vum Server gesäit. Déi entgéintgesate Richtung brauch seng eegen Regel, well de Server, deen eng Verbindung zu engem vu senge eege Clienten opbaut, en anere Floss ass. Ouni déi Regel äntwert de Client enger Adress, déi hien net route kann. Setzt déi enk Regel virun all breet Masquerade, sou datt déi spezifesch Iwwersetzung gewënnt.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Multihomed-Hosten fügen e verwandte Feeler bäi, dee vum Client aus identesch ausgesäit. D'Äntwert verléisst d'System iwwer dat Interface mat der méi niddereger Metrik, well d'Quelladress aus enger anerer Tabell gewielt gouf. Kontrolléiert de Réckwee mat enger Nokuckt amplaz unzehuelen, de Hiwee implizéiert en.

Verifizéiert dann béid Richtungen a béid Gréissten

Pingt no der Ännerung vum Client op en LAN-Host an dann vum LAN-Host op de Client. Déi zweet Richtung ass déi, déi d'Leit iwwersprangen, an et ass déi, déi eng onvollstänneg Iwwersetzungsregel opdeckt. Hält béid Resultater mat Zäitstempel fest, sou datt eng spéider Regressioun vergläichbar ass.

Beweegt dann richteg Daten, well e klenge Ping, dee geléngt, wärend en groussen Transfer stoe bleift, e MTU-Symptom ass. Dëse Feeler erschéngt direkt, nodeems Dir Iech selwer zum gefléckte Routing gratuléiert hutt.

Test um Schluss nach eng Kéier no engem Neistart. Runtime-Route- a Firewallbefehler iwwerliewen deen net, an eng Léisung, déi beim nächsten Neistart verschwënnt, gëtt nach eng Kéier vun engem mat manner Kontext diagnostizéiert. Maacht d'Ännerung dauerhaft sou wéi Äre System et schonn mécht, a start dann eng Kéier bewosst nei.