Egy IKEv2 kliens elérése a kiosztott virtuális IP-jén

Az átjárónak kapcsolatot kell indítania egy olyan laptophoz, amely IKEv2-n keresztül kapcsolódik hozzá, és ehhez az adott kliens kiosztott virtuális címét kell használnia. Az alagút él, a kliens eléri az átjáró mögötti mindent, a fordított irány mégsem működik. Ez az aszimmetria normális: a kialkudott szabályzat azt írja le, mely címek beszélhetnek, nem azt, melyik fél kezdeményezhet. Három dolognak kell összehangolódnia ahhoz, hogy az átjáró által indított kérés működjön.

Az alagút nem javítja ki a forráscímet

Egy CHILD SA egy pár forgalomszelektort fed le, oldalanként egyet, és engedélyezi a forgalmat a pár mindkét irányában. Semmit nem mond arról, melyik fél nyitotta meg először az IKE-cserét. Az az átjáró, amely eredetileg az alagútra figyelt, továbbra is elküldheti az első alkalmazáscsomagot, feltéve hogy a választott forrás és cél a telepített szelektorokon belül esik. Amikor a kérés a rossz interfészen lép ki, egyszerűen nem alkalmas az alagútra.

A kliens felé történő útválasztás szükséges és nem elégséges. A szabályzatnak engedélyeznie kell a ténylegesen használt forrást.

A telepített szabályzatot olvassa, ne a konfigurációs fájlt

Kezdje az aktív társítással és annak szelektoraival, mert a dinamikus hozzárendelés megváltoztatja, mi van telepítve a kernelben.

ipsec statusall
ip xfrm policy

Az állapotkimenet megnevezi a kapcsolatot, a kiosztott virtuális címet és azokat a szelektorokat, amelyek jelenleg érvényesek erre a félre. A szabályzat kiírása ugyanezeket a szelektorokat mutatja kernelállapotként, és valójában ezt kérdezi a csomagválasztás. Hasonlítsa össze az átjáró oldali szelektort azzal a forrással, amelyet az alkalmazása használni fog, mert az eltérés azonnal megmagyarázza a hibát. A kliens jelenlegi címét olvassa, ne egy korábbi munkamenetből származót, mert az újra kiosztott VIP érvényteleníti a régi szabályzatot.

A kliensnek ott kell figyelnie, ahova a csomag érkezik

Még egy tökéletes szabályzat is zárt porthoz jut, ha a szolgáltatás csak a loopbackhez kötődik. A figyelőnek a kiosztott címen vagy egy helyi helyettesítő címen kell lennie.

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

A socketek listája megmutatja, hogy a port a virtuális címhez van-e kötve, a tűzfal szabályai pedig azt, hogy fogad-e új kapcsolatokat a védett forrásból. A létrejött kapcsolatokra írt szabály nem enged át egy olyan kapcsolatot, amelyet az átjáró indít. Tartsa meg a szolgáltatás saját hitelesítését, mert az alagúton át érkezés csak azt állapítja meg, melyik hálózatból jött a csomag. A saját NAT-ja mögötti kliensnek továbbra sem kell bejövő porttovábbítás, mert ezek a kérések a meglévő alagúton belül utaznak.

Az új irányt önmagában tesztelje

Egy működő kliens-kiszolgáló kérés soha nem gyakorolja ezt az útvonalat. Az átjáróról indítsa a kérést, és figyelje mindkét végét.

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

Az útvonalkeresés megválaszolja, melyik forrást és interfészt használná az átjáró, és ezt az értéket kell a szabályzatnak engedélyeznie. A rögzítésnek azt kell mutatnia, hogy a kérés ESP-n belül lép ki, nem pedig sima TCP-ként a nyilvános interfészen. A kliensen rögzítse a visszafejtett forgalmat az érkezés és a szolgáltatás válaszának megerősítéséhez. Ha a kérés ESP nélkül eltűnik a hálózatról, gyanakodjon a forráscímre a kliens tűzfala előtt.

Ismételje meg a tesztet kulcscsere vagy újracsatlakozás után, mert a VIP megváltozhat. Az az útvonal, amely csak a következő munkamenetig működik, nem működő útvonal.