Ech hunn e Moien un engem Tunnel verbruecht, dee sech propper opgebaut huet an den Traffic an genau eng Richtung beweegt huet: d’Filial konnt de Fichierserver am Haaptsëtz erreechen, an all Verbindung, déi vum Haaptsëtz an d’Filial opgaang ass, ass um éischten SYN gestuerwen. D’SAe waren uewen, d’Tunnelzähler sinn geklommen, an den Handshake war ni de Problem. D’Antwert gouf dohin geroutet, wou den Tunnel se net deckt, an déi Wiel gehéiert op déi Géigewäerter Säit. E Site-to-Site-VPN transportéiert just d’Paketen, déi en Host dem Gateway iwwergëtt, an all Host trëfft déi Wiel separat, an all Richtung, aus senger eegener Routingtabell.

Béid Richtunge ginn getrennt geroutet

IP behält keng Erënnerung un d’Richtung vun enger Konversatioun. All Host, deen e Paket schéckt, mécht seng eege Sich no dem längste Präfix, wielt een nächsten Hopp a vergësst d’Entscheedung. D’Ufro an d’Antwert sinn zwou onofhängeg Paketen, déi zoufälleg zu der selwechter Verbindung gehéieren, an den Tunnel ass een Hopp, deen eng vun deenen zwou benotze kann oder net. Näischt am IKE-Austausch léiert dee wäite Server, wéi en Äert Subnetz erreecht; d’Verhandlung eenegt sech just drop, wéi eng Präfixer verschlësselt däerfen ginn.

Déi Eenegung ass dat zweet Paart. Bei strongSwan sinn d’Traffikselektoren leftsubnet an rightsubnet, an e Paket, deem seng Quell oder säin Zil ausserhalb vum verhandelte Puer fält, gëtt net verschlësselt, wat d’Routingtabell och seet. E Präfix, deen an den Tunnel geroutet gëtt, awer an den Selektoren feelt, ass e stille Feeler an enger Richtung: d’Route gesäit richteg aus, d’Paket geet trotzdem op enger oppener Streck eraus oder gëtt verworf, an nëmmen de charon-Log beschwéiert sech.

Deen wäiten Host weess näischt vun Ärem Tunnel

Bannen am wäite LAN ass d’Antwert e gewéinlecht Paket, dat un Äre Client adresséiert ass. Den Zilhost gesäit keen IPsec-Kapp a kann de VPN-Gateway net beworrecht, well et kee Grond dofir gëtt; en sicht Äre Präfix, fënnt näischt méi spezifescht wéi seng Standardroute a follegt där. Waen d’Standard op eng Kär-Firewall weist, huet d’Firewall entweder eng Route zréck an den Tunnel oder net. Wa se keng huet, kritt Dir en stille Verwerf, en ICMP unreachable oder eng Antwert, déi iwwer d’Internetsäit erausgeet an um Enn stierft.

En zweet Interface duerfir, fir dëst och dann ze briechen, wa schonn eng Route existéiert. En NAS mat engem Management-Link an engem aneren VLAN, e Server mat engem Reserv-Uplink, eng Policy-Reegel, déi eng Quellberäich an eng zweet Tabell schéckt: jiddereen vun dësen kann d’Antwert fänken. Ënner Linux weisen ip rule show an ip route show table all Reegelen an Tabelle vir, déi d’Standardopzielung verstoppt.

Liest d’Entscheedung op der Maschinn, déi d’Antwert schéckt

Frot de Kernel, ier Dir eppes ännert, a gitt him d’Quelladress, well Reegelen, déi vun der Quell ofhänken, d’Antwert änneren.

ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"

D’Ausgab nennt d’Interface, déi erausgeet, an den nächsten Hopp. Wann d’Interface net déi ass, déi op de VPN-Gateway weist, hutt Dir de Feeler fonnt, an déi reschtlech Aarbecht ass, ze wielen wou d’Route gehéiert. E Ping vum Gateway beweist hei wéineg: en äntwert mat enger Adress, déi deen wäiten Host placéiere kann, net mat der Adress vun Ärem Laptop.

Op Windows sinn d’Äquivalenter Find-NetRoute -RemoteIPAddress 10.10.5.10 fir d’Entscheedung an Get-NetRoute fir d’Tabell. Eng Route, déi mat New-NetRoute dobäigesat gëtt an eng méi héich Metrik wéi d’Standard huet, verléiert stiil, also liest d’Metrikskollonn, net den Andrag. Da bestätegt mat Paketen: tcpdump -ni any "host 10.10.5.10 and tcp port 445" um wäiten LAN-Interface weist d’Ufro, an dee selwechte Filter op der Tunnelsäit weist, ob eng Antwert zréckkënnt. Eng Ufro déi ee gesäit ouni Antwert heescht, d’Antwert gouf soss wouhi geroutet oder verworf; eng Antwert um falschen Interface gëtt Iech de Schëllege virun, ier Dir eng Route beréiert.

Wann de Gateway vum Server net de VPN-Endpunkt ass

Vill Plazen setzen eng Firewall tëschent d’Serveren an de Konzentrator. Déi Firewall leet d’Antwert weider, also brauch se eng Route fir Äre Clientpräfix op de VPN-Gateway, an eng Weiderleeungs-Policy an zwou Richtungen. Staatenhalteg Apparater maachen et méi schlëmm: d’Ufro huet d’Firewall vun engem LAN-Host aus iwwerschratt, deen se erlaabt huet, d’Antwert kënnt elo aus enger anerer Richtung, an den Andrag vun der Verbindungsverfolgung passt net méi, dofir gëtt d’Paket als ongülteg verworfen amplaz als verbueden. Dofir gesäit ee de Policy-Log eidel, während den Traffic verschwënnt.

De Gateway huet säin eege zweete Filter. Dem Linux seng Reverse-Path-Filterung verworf Paketen, där hir Quell iwwer d’Interface, iwwer déi se ukomm sinn, net erreechbar ass, an dat ass genee d’Form vun engem legitime asymmetresche Réckwee. dem strongSwan seng Weiderleeungsguide froen aus genau deem Grond net.ipv4.ip_forward an e geluechte net.ipv4.conf.all.rp_filter. En strikte Wäert vun 1 op engem vun deenen zwee Gateways brécht stiil eng richteg Route, an nstat -az weist d’Verwerfer, wann Dir wësst wou Dir kucke musst.

SymptomWhere the reply is most likely lost
Gateway ping works, LAN host silentSource address the far host cannot place in its table
SYN arrives, no SYN-ACK, tunnel counters flatNo route to the client prefix on the far host or its gateway
Reply counted on the internet-facing interfaceDefault route or policy rule on the far host
Firewall reports invalid stateAsymmetric path through a stateful device
Worked until a link failed overNew path is asymmetric, or rp_filter now rejects it

Routt oder iwwersetzt, a verifizéiert duerno an zwou Richtungen

Déi zwou Reparaturen sinn net gläichwäerteg. Eng Route derbäisetzen hält d’Clientadress onverännert, dofir funktionéieren d’Reegelen, déi op d’Quell opbauen, d’Auditlogs an d’Applikatiounen, déi den Uruffer festhalen, weider; de Präis ass, datt all Hopp, deen d’Entscheedung trëfft, d’Route brauch, also méi Plazen op deenen ee falsch leie kann. Maskerade um wäitem Gateway schrumpft den Réckwee op een Hopp, well d’Antwert elo un de Gateway selwer adresséiert ass, a verstoppt, wéi ee Client wat gemaach huet.

iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADE

Wielt en bewosst: soubal d’Clienten als Adress vum Gateway erschéngen, kënnen ACLen, déi op d’Quell opbauen, se net méi ënnerscheeden, an conntrack muss d’Mapping halen, datt d’Antwert zréck an den Tunnel geschriwwe gëtt. Waen d’Selektoren de Clientpräfix nach ëmmer ausschléissen, ännert NAT näischt, well d’Ufro ni an den Tunnel komm ass.

Ier Dir et als reparéiert bezeechent, bestätegt véier Saachen an der Rei: d’Route um Host, deen d’Antwert schéckt, d’Route op all Hopp, deen se weiderleet, d’Selektoren, déi déi zwou Präfixen decken, an eng Opnam, déi weist, datt d’Antwert mam erwaarten Ursprong an den Tunnel geet. Widderhielt duerno den Test vun der anerer Plaz. Eng Richtung, déi duerchgeet, ass en hallefoppent Design, an déi zweet Richtung versot meeschtens aus engem aneren Grond wéi deem, deen Dir just reparéiert hutt.

Ähnlech Artikelen