Odchádzajúci ESP bez odpovede neznamená, že VPN je mŕtva
ESP chráni jeden smer na asociáciu a nič nepotvrdzuje. Zlaďte vnútornú konverzáciu a prichádzajúcu SA, skôr než server nazvete neodpovedajúcim.
Zachytili ste prevádzku na hostiteľovi IPsec, videli ste odchádzajúce pakety ESP, nevideli ste nič vracajúce sa a usúdili ste, že vzdialená strana je pokazená. Zachytenie tento záver nepodporuje. ESP chráni jeden smer konverzácie a na úrovni IP nič nepotvrdzuje, takže chýbajúci spätný ESP môže rovnako ľahko znamenať, že aplikácia nemala čo povedať, ako to, že tunel je mŕtvy. Prečítajte si vnútornú výmenu a stav prijímacej strany, skôr než obviníte ktorýkoľvek koniec.
Mýtus: každý chránený paket si vyslúži odpoveď
ESP nie je protokol otázka-odpoveď. Šifruje a autentizuje to, čo vyberie politika, a prijímateľ overí, dešifruje a doručí ten vnútorný paket bez toho, aby sám vytvoril paket. UDP dopyt, ktorý cieľ ignoruje, alebo ICMP ozvena, ktorú prichádzajúca politika zahodí, vytvára v oboch smeroch ticho ako správny výsledok. Považovanie tohto ticha za transportnú poruchu vás pošle hľadať sieťovú chybu, ktorá nikdy neexistovala.
Jednosmerné zachytenie v skutočnosti dokazuje, že zásobník odosielateľa v tom pozorovacom bode niečo zašifroval. Nič o príchode a nič o úmysle odpovedať. Užitočná otázka nie je „prečo neprichádza odpoveď“, ale „čo mala vnútorná konverzácia vytvoriť“.
Dve SA, dva SPI, jedna konverzácia
Bezpečnostné asociácie IPsec sú jednosmerné, takže bežná chránená výmena prevádzkuje prichádzajúcu asociáciu a odchádzajúcu asociáciu s oddelenými identifikátormi a nezávislým stavom. Hľadanie spätnej prevádzky podľa SPI odchádzajúceho paketu je preto kategorická chyba, pretože každá odpoveď cestuje pod vlastnou odchádzajúcou SA partnera s vlastným SPI. Namiesto toho spárujte dvojicu podľa selektorov prevádzky a adries partnera.
Obnova kľúča na niekoľko sekúnd komplikuje obraz, keďže starý a nahradzujúci stav sa môžu prekrývať. Ak príznak začal okolo obnovy kľúča, zbierajte identifikátory asociácií a časové značky spolu, a nie iba názov spojenia.
Čo musí prijímateľ urobiť, kým niečo odpovie
| 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" |
Každý riadok zlyháva nezávisle a každá porucha má iného vlastníka, preto ich jedno zachytenie nedokáže rozlíšiť. Prichádzajúce počítadlo je jediným priamym dôkazom príchodu, pretože paket, ktorý neprejde autentizáciou alebo kontrolou opakovania, sa zahodí bez akejkoľvek odpovede. Partner, ktorého prichádzajúce počítadlo sa nepohlo, vám preto vôbec neposkytuje žiadnu informáciu o svojej politike.
Doručenie je samostatný krok od dešifrovania. Stav môže byť platný a paket napriek tomu neskôr zahodí prichádzajúca politika alebo trasa, ktorá nezahŕňa vnútorný cieľ, preto overte, či cieľový hostiteľ videl čistý text, namiesto toho, aby ste predpokladali, že čisté počítadlo znamená, že paket išiel tam, kam ste chceli.
Natívny ESP nie je UDP
Natívny ESP je protokol IP 50, ktorý nie je ani TCP, ani UDP a nemá vôbec žiadne porty. Pravidlo firewallu, ktoré povoľuje IKE na UDP 500, preto nehovorí nič o dátovej ceste a filter napísaný okolo portov môže nechať tunel vyjednať a potom zahodiť všetko, čo sa v ňom prenáša. Testujte dátovú cestu samostatne, v režime, ktorý ste skutočne pozorovali.
Za NAT sa tvar mení: chránený obsah cestuje vnútri UDP, zvyčajne na porte 4500, ako definuje RFC 3948. Zaregistrujte aktívny režim pred napísaním akéhokoľvek pravidla, pretože zariadenie na ceste môže natívny ESP a ESP zapuzdrené v UDP spracúvať úplne odlišne a niektoré medziľahlé zariadenia prepúšťajú jedno, zatiaľ čo druhé zahadzujú.
Čítajte počítadlá, ktoré patria tejto udalosti
Na hostiteľovi strongSwan swanctl --list-sas hlási počítadlá paketov a bajtov pre každú asociáciu v oboch smeroch, čo stačí na oddelenie „nikdy neprišlo“ od „prišlo a nebolo odpovedané“. V Linuxe /proc/net/xfrm_stat počíta agregované zlyhania, ako chýbajúci stav, chýbajúca politika a chyby protokolu. Tieto súčty sa hromadia od štartu a patria jednému sieťovému mennému priestoru, takže veľké číslo nie je priradenie.
Urobte dve merania okolo okna incidentu v správnom mennom priestore a porovnajte rozdiely, inak pripíšete chyby z minulého týždňa dnešnému lístku. Uveďte menný priestor a obe časové značky v lístku, aby ďalší čitateľ mohol porovnanie zopakovať, namiesto toho, aby dôveroval súčtu.
Pomenujte fázu, nie podozrivého
Užitočný záver hovorí, kde sa paket zastavil: nikdy neprijatý, prijatý a zahodený, doručený, ale bez odpovede, alebo zodpovedaný a stratený na ceste späť. Každý z nich ukazuje na iného vlastníka a iný nasledujúci príkaz. „Žiadna odpoveď od servera VPN“ zhrnie štyri odlišné poruchy do jednej vety, ktorú zachytenie nikdy neoprávňovalo.
Držte zachytenia úzke a surový stav jadra nedávajte do lístkov, pretože môže niesť kľúčový materiál, ktorý by nemal opustiť hostiteľa. Rozdiely počítadiel a časové značky sú časti, ktoré sa oplatí odovzdať ďalšej osobe.