En IKEv2-Client op senger zougewisener virtueller IP erreechen

Eng Paart muss eng Verbindung zu engem Laptop opbauen, deen iwwer IKEv2 mat hir verbonnen ass, an dobäi déi zougewisen virtuell Adress vun deem Client benotzen. Den Tunnel steet, de Client erreecht alles hannert der Paart, an déi ëmgekéiert Richtung schléit nach ëmmer fehl. Dës Asymmetrie ass normal: déi ausgemaach Politik beschreift, wéi eng Adressen dierfe schwätzen, net wéi eng Säit dierf ufänken. Dräi Saachen musse sech een, ier eng Ufro, déi d’Paart ausléist, funktionéiert.

Den Tunnel fléckt d’Quelladress net

Eng CHILD SA deckt eng Couple Trafikselektoren, een pro Säit, an erlaabt Trafik a béide Richtunge vun där Couple. Si seet näischt doriwwer, wéi en Peer den IKE-Austausch als éischten opgemaach huet. Eng Paart, déi ufanks op den Tunnel gelauschtert huet, kann nach ëmmer dat éischt Applikatiounspaket schécken, soulaang déi gewielte Quell an d’Zil bannent den installéierte Selektoren leien. Wann d’Ufro aus dem falschen Interface erausgeet, ass se einfach net fir den Tunnel qualifizéiert.

Routing a Richtung Client ass noutwendeg an net duergen. D’Politik muss d’Quell erlaben, déi Dir tatsächlech benotzt hutt.

Liest déi installéiert Politik, net d’Konfiguratiounsdatei

Fänkt bei der aktiver Associatioun an hire Selektoren un, well déi dynamesch Zousetzung ännert, wat am Kernel installéiert ass.

ipsec statusall
ip xfrm policy

D’Statusausgab nennt d’Verbindung, déi zougewisen virtuell Adress an d’Selektoren, déi fir deen Peer aktuell gëllen. Den Politik-Dump weist déiselwecht Selektoren als Kernelzoustand, an genau dee konsultéiert d’Paketauswiel tatsächlech. Vergläicht den Selektor op der Paartsäit mat der Quell, déi Är Applikatioun wäert benotzen, well eng Differenz de Feeler direkt erkläert. Liest déi aktuell Adress vum Client an net eng aus enger fréierer Sitzung, well eng nei zougewisen VIP déi al Politik ongëlteg mécht.

De Client muss lauschteren, wou de Pak ukommt

Och eng perfekt Politik erreecht e zouenen Port, wann de Service nëmmen un Loopback gebonnen ass. De Lauschterer muss op der zougewisener Adress oder op enger lokaler Wildcard-Adress sinn.

ss -ltnp 'sport = :9090'
iptables -S INPUT

D’Socket-Lëscht weist, ob de Port un d’virtuell Adress gebonnen ass, an d’Firewall-Regele weisen, ob nei Verbindungen aus der geschützter Quell ugeholl ginn. Eng Regel, déi fir bestänneg Verbindunge geschriwwe gouf, léisst eng Verbindung net zou, déi d’Paart ausléist. Behält d’Authentifikatioun vum Service selwer, well d’Ukomme duerch den Tunnel just feststellt, aus wéi engem Netzwierk de Pak komm ass. E Client hannert sengem eegenen NAT brauch nach ëmmer keng agehend Portweiderleitung, well dës Ufroe bannen am bestännegen Tunnel reesen.

Test déi nei Richtung eenzel

Eng funktionéierend Ufro vu Client zu Server probéiert dëse Wee ni. Generéiert d’Ufro vun der Paart aus a observéiert béid Enner.

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

D’Routensich beäntwert, wéi eng Quell an Interface d’Paart benotze géif, an dat ass de Wäert, deen d’Politik muss erlaben. D’Opnam soll weisen, datt d’Ufro bannen an ESP erausgeet an net als einfachen TCP um ëffentlechen Interface. Um Client, hëlt den decryptéierten Trafik op, fir d’Ukomme an d’Äntwert vum Service ze bestätegen. Wann d’Ufro ouni ESP um Kabel verschwënnt, verdächtegt d’Quelladress virun der Firewall vum Client.

Widderhëlt den Test no engem Schlësselwiessel oder enger Neiverbindung, well d’VIP sech ka änneren. E Wee, deen nëmme bis zur nächster Sitzung funktionéiert, ass kee funktionéierende Wee.