A válasz nélküli kimenő ESP nem jelenti azt, hogy a VPN halott
Az ESP asszociációnként egy irányt véd, és semmit nem nyugtáz. Rendezd össze a belső beszélgetést és a bejövő SA-t, mielőtt nem reagálónak nevezed a szervert.
Forgalmat rögzítettél az IPsec-hoston, láttad az ESP-csomagokat távozni, semmit nem láttál visszatérni, és arra jutottál, hogy a távoli oldal elromlott. A rögzítés nem támasztja alá ezt a következtetést. Az ESP a beszélgetés egy irányát védi, és az IP-szinten semmit nem nyugtáz, ezért a hiányzó vissza-ESP ugyanolyan könnyen jelentheti azt, hogy az alkalmazásnak nem volt mondanivalója, mint azt, hogy az alagút halott. Olvasd el a belső cserét és a fogadó oldal állapotát, mielőtt bármelyik végpontot hibáztatnád.
A mítosz: minden védett csomag választ érdemel
Az ESP nem kérés-válasz protokoll. Titkosítja és hitelesíti azt, amit a házirend kiválaszt, a fogadó pedig érvényesíti, visszafejti és kézbesíti ezt a belső csomagot anélkül, hogy saját csomagot generálna. Egy UDP-kérés, amelyet a cél figyelmen kívül hagy, vagy egy ICMP-visszhang, amelyet a bejövő házirend eldob, mindkét irányban csendet eredményez helyes kimenetként. Ha ezt a csendet átviteli hibának tekinted, olyan hálózati hibát kezdesz keresni, amely soha nem létezett.
Amit az egyirányú rögzítés valójában bizonyít, az az, hogy a küldő vereme titkosított valamit azon a megfigyelési ponton. Semmit az érkezésről, és semmit a válaszadás szándékáról. A hasznos kérdés nem az, hogy "miért nincs válasz", hanem hogy "mit kellett volna a belső beszélgetésnek előállítania".
Két SA, két SPI, egy beszélgetés
Az IPsec biztonsági asszociációk egyirányúak, ezért egy normál védett csere bejövő és kimenő asszociációt tartalmaz külön azonosítókkal és független állapottal. A visszaforgalom keresése a kimenő csomag SPI-je alapján ezért kategóriahiba, mert minden válasz a partner saját kimenő SA-ja alatt, a saját SPI-jével utazik. Inkább forgalomszelektorok és a partner címei alapján párosítsd a párt.
A kulcscsere néhány másodpercre bonyolítja a képet, mert a régi és a helyettesítő állapot átfedhet. Ha a tünet egy kulcscsere környékén kezdődött, gyűjtsd össze az asszociáció-azonosítókat és az időbélyegeket együtt, ne csak a kapcsolat nevét.
Mit kell a fogadónak tennie, mielőtt bármi válaszol
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
Minden sor önállóan hibázik, és minden hibának más a gazdája, ezért egyetlen rögzítés nem tudja megkülönböztetni őket. A bejövő számláló az érkezés egyetlen közvetlen bizonyítéka, mert az a csomag, amely hitelesítésén vagy ismétlés-ellenőrzésén elbukik, minden válasz nélkül eldobódik. Egy partner, amelynek bejövő számlálója nem mozdult, ezért semmilyen információt nem küld neked a házirendjéről.
A kézbesítés külön lépés a visszafejtéstől. Az állapot érvényes lehet, és a csomagot mégis később eldobhatja egy bejövő házirend vagy egy útvonal, amely nem tartalmazza a belső célt, ezért ellenőrizd, hogy a célhost látott-e egyszerű szöveget, ahelyett hogy feltételeznéd, a tiszta számláló azt jelenti, hogy a csomag oda ment, ahová akartad.
A natív ESP nem UDP
A natív ESP az IP 50 protokoll, amely sem TCP, sem UDP, és egyáltalán nincs portja. Ezért az UDP 500-on IKE-t engedélyező tűzfal-szabály semmit nem mond az adatútról, és a portok köré írt szűrő engedheti az alagutat tárgyalni, majd eldobhat mindent, amit benne szállítanak. Teszteld az adatutat külön, abban a módban, amelyet valóban megfigyeltél.
NAT mögött a forma megváltozik: a védett hasznos teher UDP-n belül utazik, általában a 4500-as porton, ahogyan az RFC 3948 meghatározza. Rögzítsd az aktív módot, mielőtt bármilyen szabályt írnál, mert az útvonalon lévő eszköz a natív ESP-t és az UDP-be csomagolt ESP-t teljesen eltérően kezelheti, és egyes köztes dobozok az egyiket engedik, a másikat eldobják.
Ehhez az esethez tartozó számlálókat olvass
Egy strongSwan-hoston az swanctl --list-sas asszociációnként mindkét irányban jelent csomag- és bájtszámlálókat, ami elég ahhoz, hogy elválaszd a "soha nem érkezett meg" esetet az "megérkezett, de nem kapott választ" esettől. Linuxon a /proc/net/xfrm_stat összesített hibákat számol, például hiányzó állapotot, hiányzó házirendet és protokollhibákat. Ezek az összegek a rendszerindítástól gyűlnek, és egyetlen hálózati névtérhez tartoznak, ezért a nagy szám még nem hozzárendelés.
Vegyél két leolvasást az eseményablak körül a megfelelő névtérben, és hasonlítsd össze a különbségeket, különben a múlt heti hibákat ragasztod a mai délután jegyére. Írd be a névteret és mindkét időbélyeget a jegybe, hogy a következő olvasó reprodukálhassa az összehasonlítást, ne pedig egy összegben bízzon.
A szakaszt nevezd meg, ne a gyanúsítottat
Egy hasznos következtetés megmondja, hol állt meg a csomag: soha nem érkezett meg, megérkezett és eldobódott, kézbesítődött de válasz nélkül maradt, vagy megválaszolódott és a visszaúton elveszett. Ezek mindegyike más gazdára és más következő parancsra mutat. A "nincs válasz a VPN-szervertől" négy különböző hibát présel egyetlen mondatba, amelyet a rögzítés soha nem indokolt.
Tartsd szűken a rögzítéseket, és tartsd a nyers kernelállapotot a jegyeken kívül, mert kulcsanyagot hordozhat, amelynek semmi keresnivalója a hoston kívül. A számlálókülönbségek és az időbélyegek azok a részek, amelyeket érdemes átadni a következő embernek.