VPN-Client op engem LAN-Server: firwat d'Äntwerten de falsche Wee huelen

D'Symptomer follegen engem eenzegen Muster: en Host funktionéiert, dann verbënnt en sech als Client mat enger VPN, an elo erreechen LAN-Cliente en, wärend seng Äntwerten verschwannen. Eng Opnam um Host weist, datt d'Äntwerten duerch den Tunnelapparat erausginn amplaz duerch d'LAN-Interface. Um Tunnel ass näischt futti, an de Fix ass eng Route, net eng nei Verbindung. Gitt déi véier Kontrollen hei drënner an der Rei duerch a stoppt bei der éischter, déi feelt.

Eng Äntwert ass en neie Pak, keng Ëmkeer

Et hëlleft d'Iddi opzeginn, datt eng Äntwert de Wee zréckkënnt, dee eng Ufro geholl huet. Routing gëtt pro Pak, pro Richtung, um sendenden Host decidéiert. Eng Ufro, déi vun 10.64.0.23 am Tunnel ukomm ass, schaaft kee Retourwee; wann den Host äntwert, gëtt déi Äntwert als neie Pak mat der Tabell verglach an geet duerch déi Route eraus, déi gewënnt.

Dofir mécht e Client mat vollem Tunnel op enger Maschinn, déi och eng LAN servéiert, sou eng verwirrend Feelfunktioun. De Client installéiert eng Standardroute, oder déi zwou hallef Standardrouten, déi verschidde Cliente léiwer hunn, an d'Äntwert un e LAN-Client passt elo zum Tunnel. Se geet bei de Provider, dee kee Grond huet, se virun ze schécken, an de LAN-Client gesäit en Zäitofbroch, obwuel den Host leeft an lokal äntwert. D'Opnam mécht et evident, an d'Routingtabell erkläert et.

Halt zwee Subnetzer am Kapp, wärend Dir de Rescht liest. Eent ass de VPN-Adresspool, vun deem déi wäit Cliente kommen, an dësem Beispill 10.64.0.0/24. Dat anert ass d'LAN, déi muss weiderfunktionéieren, 172.16.24.0/24 mat hirem Router op 172.16.24.1. De Feeler ass, datt den Trafik tëscht hinnen duerch d'Standardroute decidéiert gëtt.

Beweist et mat der Opnam an der Ufro

Ier Dir eppes ännert, bestätegt wéi en Apparat d'Äntwert benotze wäert. Eng Ufro ass méi séier wéi eng Opnam an äntwert genee op déi Fro, déi de Kernel beäntwerten wäert, wann de Pak gebaut gëtt.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Liest d'Äntwert an zwee Deeler. Wann se dev tun0 nennt, wäert den Host d'Äntwert encapsuléieren an dem Provider ginn, an de LAN-Client wäert se ni gesinn. Wann se dev eth0 nennt, awer de Client ëmmer nach en Zäitofbroch kritt, ass d'Route schonn richteg an de Pak gëtt méi spéit verworf, wat en anert Problem mat engem aneren Fix ass.

D'Opnam am selwechte Schrëtt entscheet den Zweifel, deen e ping net kann. En Echo-Äntwert, deen beim LAN-Client ukommt, beweist, datt en Wee funktionéiert, net wéi eng Interface en dropgedroen huet, dofir maacht d'Opnam um Host selwer a kuckt, wou d'Frames erausginn. En Drécker am selwen Subnetz äntwert weider, well seng direkt Route méi spezifesch ass wéi d'Standardroute vum Tunnel. En weidergeleet Port feelt genee wéi all anere Flux, well d'Tabell d'Interface wielt an net d'Verbindung.

Installéiert déi schmuelst Route, déi den Tunnel iwwertrëfft

D'Längt vum Präfix entscheet, net d'Metrik, dofir gewënnt eng Route fir de Clientpool iwwer den LAN-Router géint all Standardroute, déi de VPN-Client installéiert. Metrikchirurgie ass net néideg, an d'Standardroute kann genau do bleiwen, wou de Client se gesat huet.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Benotzt replace amplaz add, well e Client, deen sech nei verbënnt, seng eege Entrée installéiert huet an en zweete add mat engem Feeler iwwer eng existéierend Route feelt, dee wéi e Berechtegungsproblem liest. Op engem Windows-Host ass d'Äquivalent route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, wou -p d'Entrée iwwer Neistarts hält, well de Client d'Tabell ka nei bauen, wann den Tunnel erëm eropkënnt. Op engem aktuellen Windows-Host ass dat ënnerstëtzt Äquivalent New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, an deeler route-Befehl bleift als ale Form erhalen.

Een Detail entscheet, ob dat richteg oder just glaubwürdeg ass: deen nächsten Hop muss de Router sinn, deen tatsächlech de Wee zréck zu de Cliente besëtzt. D'Route op eng Adress ze riichten, déi een selwer duerch den Tunnel erreecht, schaaft eng Schläif, déi als ënnerbrachene Verloscht erschéngt an net als propper Feelfunktioun. Bestätegt, datt den nächsten Hop am LAN-Subnetz läit, ier Dir d'Linn bestätegt.

Halt d'Äntwert no enger neier Verbindung

Eng Route, déi vun Hand bäigefüügt gouf, iwwerlieft am beschten Fall bis zur nächster neier Verbindung. Wann de Clientpool dynamesch ass, pinnt en an der Serverkonfiguratioun, sou datt de Präfix, deen Dir gerout hutt, de Präfix bleift, deen d'Cliente kréien; soss weist d'Entrée op e leem Beräich an d'Symptom kënnt Wochen méi spéit ouni kloeren Urspronk zréck. D'Route an den eegene Up-Skript vum Client ze schreiwen ass déi aner zouverlässeg Optioun, well en ausgefouert gëtt, nodeems de Client d'Tabell nei geschriwwen huet.

Eng stateful Firewall kann eng richteg Route nach ëmmer schloen. Wann d'Opnam elo weist, datt d'Äntwert duerch eth0 erausgeet, an de Client nach ëmmer en Zäitofbroch kritt, préift, ob den Host de Pak virum Senden verwërft. Streng Ëmwee-Filterung an net.ipv4.conf.all.rp_filter op 1 gesat verwerfen Päck, deenen hir Quell net iwwer d'Interface zréckgerout géif, iwwer déi se ukomm sinn, an dat ass genee dee asymmetresche Fall, deen Dir grad geschaaft an dann reparéiert hutt, an de Conntrack-Zoustand erzielt déiselwecht Geschicht fir weidergeleet Porten.

Déi lescht Kontroll ass déi, déi d'Leit iwwersprangen: widderhëlt d'Ufro, nodeems den Tunnel erof an erëm erop war. Véier Wäerter sollen dat entspriechen, wat Dir opgeschriwwen hutt: d'Zil, deen nächsten Hop, den Apparat an d'ausgewielte Quell. Wann ee vun hinnen sech geréckelt huet, huet de Client d'Tabell nei geschriwwen an de Fix gehéiert an seng Hooks an net an eng Shell-Historie.