A VPN UP, de nincs adatforgalom: Juniper SRX hibakeresés NAT-T mögött

Egy site-to-site VPN-nél az UP állapot nem azonos a működő data plane-nel.

Egy valós, anonimizált incidensben az IKE Phase 1 és az IPsec Phase 2 is felépültnek látszott, miközben az üzleti forgalom nem jutott át az alagúton. A hibakeresést végül nem egy újabb „clear” oldotta meg, hanem az adatút szakaszonkénti bizonyítása.

Az ideiglenes topológia

A telephely normál szolgáltatói internetkapcsolata nem volt használható. A végleges helyreállításig egy Windows notebook mobilinternet-kapcsolata szolgált ideiglenes gatewayként:

Telephelyi LAN → Juniper SRX → Windows notebook Ethernet → Internet Connection Sharing → mobilinternet → Internet → központi Juniper SRX.

A telephelyi SRX emiatt nem közvetlenül publikus címen működött, hanem Windows ICS és mobilhálózati NAT mögött.

Az IPsec kapcsolat NAT Traversallal, UDP/4500 használatával épült fel.

Ez működőképes emergency megoldás lehet, de nem helyettesít egy tervezett másodlagos WAN-t vagy valódi HA-t.

Első tanulság: az IKE a tűzfal saját forgalma

Az első akadály egyszerű volt: azon az SRX interfészen, amelyen az ideiglenes VPN felépült, korábban nem volt szükség IKE host-inbound engedélyre.

A Junos security zone modellben az IKE külön engedélyezhető system service. Ha egy emergency topológia miatt a VPN egy korábban erre nem használt interfészre kerül át, ezt is ellenőrizni kell.

A route és az UDP/4500 kijutása önmagában tehát nem bizonyítja, hogy a tűzfal control plane-je fogadja is a szükséges IKE forgalmat.

Második tanulság: az SA-k után nézd a countereket

A következő állapot már megtévesztőbb volt:

• IKE SA: UP;
• IPsec SA: UP;
• adatforgalom: nincs.

Ilyenkor az egyik leghasznosabb jel az IPsec packet counter.

A telephelyi oldalon az encrypted packet számláló nőtt. Ez azt bizonyította, hogy a forgalom bekerült az alagútba.

A túloldalon viszont a decrypt oldal nem nőtt.

Ez már sokkal szűkebb hibateret adott, mint az általános „a VPN nem megy” állapot.

Harmadik tanulság: bizonyítsd végig a csomag útját

A köztes Windows gépen packet capture-rel látszott, hogy:

1. az SRX UDP/4500 csomagja megérkezik az Ethernet oldalra;
2. az ICS NAT-olja;
3. a csomag elhagyja a mobil uplinket.

A központi SRX WAN interfészén ugyanaz a forgalom megjelent.

Ezzel külön bizonyíthatóvá vált:

• a spoke SRX titkosít;
• a köztes NAT átengedi a forgalmat;
• az internetútvonal működik;
• a hub WAN interfésze megkapja a csomagot.

Ha mégsem nő a decrypt counter, a hiba már nem „valahol az interneten” keresendő.

NAT-T esetén nem csak a publikus IP számít

A mobilhálózati NAT egyik későbbi állapotában a külső publikus IP nem változott, a NAT-T UDP source port viszont igen.

Ez fontos különbség.

A hub oldali SA még egy korábbi remote portot tartott, miközben a WAN capture már ugyanarról a publikus IP-ről, de más UDP source portról érkező csomagokat mutatott.

A Juniper jelenlegi dokumentációja is külön kezeli a NAT-T remote port változásának esetét, mert az session mismatchhez vezethet. Ez platform- és release-függő viselkedés, ezért a konkrét mitigáció előtt mindig az adott Junos verzió dokumentációját kell ellenőrizni.

A gyakorlati ellenőrzési pont:

a hub SA-ban tárolt NAT-T remote tuple-t hasonlítsd össze azzal, ami a WAN capture-ben ténylegesen érkezik.

Amikor a részleges clear nem elég

A vizsgált incidensben több célzott SA- és flow-clear után is visszaállt a hibás működés.

A megbízható recovery végül ez lett:

• a telephelyi IKE gateway és VPN deaktiválása;
• megvárni, amíg az érintett IKE/IPsec/NAT-T flow state ténylegesen kifut;
• csak ezután tiszta újraaktiválás.

Ez nem bizonyít konkrét Junos defectet.

Azt bizonyítja, hogy az adott, többszörösen NAT-olt környezetben az összetett state részleges törlések után nem állt vissza jól, teljes kifutás után viszont igen.

Hibakeresési sorrend

Hasonló esetben érdemes ezt a logikát követni:

1. van-e valódi internetkijárat az SRX-ről;
2. felépül-e IKE;
3. felépül-e IPsec;
4. nő-e az encrypt counter;
5. nő-e a decrypt counter;
6. kijut-e a NAT-T csomag a köztes gatewayből;
7. megérkezik-e a hub WAN-ra;
8. egyeznek-e az aktuális SPI-k;
9. egyezik-e a NAT-T remote port;
10. nincs-e régi vagy féloldalas flow/SA állapot.

Ez lassabbnak tűnhet, mint ismételten újraindítani a VPN-t, de sokkal gyorsabban szűkíti a tényleges hibapontot.

Még egy fontos guardrail: legyen visszaút

Ha a VPN-en keresztül menedzseled a távoli tűzfalat, egy teljes deactivate a saját SSH-sessionöd végét is jelentheti.

Mielőtt ilyen lépést végzel, legyen legalább egy másik használható management út:

• helyi konzol;
• out-of-band elérés;
• helyi admin vagy notebook;
• másik, független WAN;
• dokumentált helyszíni recovery lehetőség.

A recovery terv része nemcsak a szolgáltatás visszaállítása, hanem a saját adminisztrációs visszaút biztosítása is.

Források

• Juniper Networks: Route-Based VPNs with NAT-T
• Juniper Networks: system-services — Security Zones Host Inbound Traffic
• Juniper Networks: Internet Key Exchange overview
• Microsoft Learn: Internet Connection Sharing