A VPN felépült, még sincs adatforgalom: Juniper SRX hibakeresés NAT-T mögött

Egy site-to-site VPN-nél a felépült állapot nem azonos a működő adatúttal.

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 célzott állapottörlés 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 átjáróké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 vészmegoldá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 bejövő IKE-forgalom engedélyezésére.

A Junos biztonsági zóna modelljében az IKE külön engedélyezhető rendszerszolgáltatás. Ha egy vészhelyzeti 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 vezérlési síkja fogadja is a szükséges IKE forgalmat.

Második tanulság: az SA-k után nézd a számlálókat

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 csomagszámláló.

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

A túloldalon viszont a visszafejtett csomagok számlálója nem nőtt.

Ezzel már jóval szűkebb körre lehetett leszűkíteni a hibát, mint az általános „a VPN nem megy” állapotból.

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

A köztes Windows gépen csomagrögzítéssel látszott, hogy:

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

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

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

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

Ha mégsem nő a visszafejtési számláló, 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 forrásport viszont igen.

Ez fontos különbség.

A hub oldali SA még egy korábbi távoli portot tartott, miközben a WAN oldali csomagrögzítés már ugyanarról a publikus IP-ről, de más UDP forrásporttal érkező csomagokat mutatott.

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

A gyakorlatban ezt érdemes ellenőrizni:

a hub SA-ban tárolt NAT-T távoli IP/port párost hasonlítsd össze azzal, ami a WAN oldali csomagrögzítésben ténylegesen érkezik.

Amikor a részleges állapottörlés nem elég

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

A megbízható helyreállítás végül ez lett:

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

Ez nem bizonyít konkrét Junos-hibát.

Azt bizonyítja, hogy az adott, többszörösen NAT-olt környezetben az összetett állapot 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 a titkosítási számláló;
5. nő-e a visszafejtési számláló;
6. kijut-e a NAT-T csomag a köztes átjáróból;
7. megérkezik-e a központi SRX WAN interfészére;
8. egyeznek-e az aktuális SPI-k;
9. egyezik-e a NAT-T távoli port;
10. nincs-e régi vagy féloldalas forgalmi/SA állapot.

Ez elsőre lassabbnak tűnhet, mint újra és újra elindítani a VPN-t, de sokkal gyorsabban megmutatja, hol van ténylegesen a hiba.

Még egy fontos biztonsági alapelv: legyen visszaút

Ha a VPN-en keresztül menedzseled a távoli tűzfalat, a kapcsolat teljes deaktiválása a saját SSH-kapcsolat végét is jelentheti.

Mielőtt ilyen lépés történik, legyen legalább egy másik használható menedzsmentút:

• helyi konzol;
• sávon kívüli (out-of-band) elérés;
• helyi admin vagy notebook;
• másik, független WAN;
• dokumentált helyszíni helyreállítási lehetőség.

A helyreállítási 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