Väljuv ESP ilma vastuseta ei tähenda, et VPN on surnud
ESP kaitseb ühte suunda ühenduse kohta ega kinnita midagi. Viige kokku sisemine vestlus ja sissetulev SA, enne kui nimetate serveri mittevastavaks.
Jäädvustasite liikluse IPsec-hostis, nägite ESP pakette lahkumas, ei näinud midagi tagasi tulemas ja järeldasite, et kaugem pool on katki. Jäädvustus ei toeta seda järeldust. ESP kaitseb vestluse ühte suunda ega kinnita IP-kihis midagi, seega puuduv tagasi-ESP võib sama kergesti tähendada, et rakendusel polnud midagi öelda, kui seda, et tunnel on surnud. Lugege sisemist vahetust ja vastuvõtva poole olekut, enne kui süüdistate kumbagi otsa.
Müüt: iga kaitstud pakett teenib vastuse
ESP ei ole päringu-vastuse protokoll. See krüpteerib ja autendib kõik, mille poliitika valib, ning vastuvõtja valideerib, dekrüpteerib ja toimetab selle sisemise paketi kohale, ilma et genereeriks oma paketti. UDP päring, mille sihtkoht jätab tähelepanuta, või ICMP kaja, mille sissetulev poliitika kõrvale heidab, tekitavad mõlemas suunas vaikuse õige tulemusena. Selle vaikuse transportveaks pidamine saadab teid otsima võrgutõrget, mida kunagi polnud.
Ühesuunaline jäädvustus tõestab tegelikult seda, et saatja pinu krüpteeris selles vaatluspunktis midagi. Mitte midagi saabumise kohta ja mitte midagi vastamise kavatsuse kohta. Kasulik küsimus ei ole "miks vastust pole", vaid "mida oleks sisemine vestlus pidanud tootma".
Kaks SA-d, kaks SPI-d, üks vestlus
IPsec turbekantsioonid on ühesuunalised, seega tavaline kaitstud vahetus hõlmab sissetulevat ja väljuvat assotsiatsiooni eraldi identifikaatoritega ja sõltumatu olekuga. Väljuva paketi SPI järgi tagasiliikluse otsimine on seetõttu kategooriaviga, sest iga vastus liigub partneri enda väljuva SA all omaenda SPI-ga. Sobitage paar hoopis liikluse selektorite ja partneri aadresside järgi.
Võtmete uuendamine muudab pildi mõneks sekundiks keeruliseks, kuna vana ja asendav olek võivad kattuda. Kui sümptom algas võtmete uuendamise ajal, koguge assotsiatsiooni identifikaatorid ja ajatemplid koos, mitte ainult ühenduse nimi.
Mida peab vastuvõtja tegema, enne kui miski vastab
| 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" |
Iga rida ebaõnnestub iseseisvalt ja igal ebaõnnestumisel on erinev omanik, mistõttu üks jäädvustus ei suuda neid eristada. Sissetulev loendur on ainus otsene tõend saabumisest, sest pakett, mis ebaõnnestub autentimises või korduse kontrollis, heidetakse kõrvale ilma igasuguse vastuseta. Partner, kelle sissetulev loendur ei ole liikunud, ei saada teile seega üldse mingit teavet oma poliitika kohta.
Kohaletoimetamine on dekrüpteerimisest eraldi samm. Olek võib olla kehtiv ja pakett siiski hiljem sissetuleva poliitika või marsruudi poolt kõrvale heidetud, mis ei hõlma sisemist sihtkohta, seega kontrollige, kas sihthost nägi selget teksti, selle asemel et eeldada, et puhas loendur tähendab, et pakett läks sinna, kuhu soovisite.
Päris ESP ei ole UDP
Päris ESP on IP-protokoll 50, mis ei ole ei TCP ega UDP ning millel pole üldse ühtegi porti. Seetõttu ei ütle tulemüürireegel, mis lubab IKE-d UDP 500 peal, andmetee kohta midagi, ja portide ümber kirjutatud filter võib lasta tunnelil läbi rääkida ja seejärel kõrvale heita kõik, mida sees kantakse. Testige andmeteed eraldi, režiimis, mida tegelikult vaatlesite.
NAT-i taga muutub kuju: kaitstud kasulik koormus liigub UDP sees, tavaliselt pordil 4500, nagu määratleb RFC 3948. Registreerige aktiivne režiim enne mis tahes reegli kirjutamist, sest tee peal olev seade võib päris ESP-d ja UDP-sse pakendatud ESP-d täiesti erinevalt käsitleda ning mõned vahendavad seadmed lubavad ühte ja heidavad teise kõrvale.
Lugege loendureid, mis kuuluvad selle juhtumi juurde
strongSwan hostis näitab swanctl --list-sas paketi- ja baidiloendureid assotsiatsiooni kohta mõlemas suunas, millest piisab, et eristada "kunagi ei saabunud" olekust "saabus ja ei vastatud". Linuxis loeb /proc/net/xfrm_stat koondtõrkeid, nagu puuduv olek, puuduv poliitika ja protokollivead. Need summad kogunevad algusest peale ja kuuluvad ühte võrgu nimeruumi, seega suur arv ei ole omistamine.
Tehke kaks mõõtmist juhtumi akna ümber õiges nimeruumis ja võrrelge erinevusi, muidu kinnitate eelmise nädala vead tänase pärastlõuna pileti külge. Pange nimeruum ja mõlemad ajatemplid pileti sisse, et järgmine lugeja saaks võrdlust korrata, selle asemel et usaldada summat.
Nimetage etapp, mitte kahtlusalune
Kasulik järeldus ütleb, kus pakett peatus: kunagi ei saadud, saadi ja heideti kõrvale, toimetati kohale, kuid ei vastatud, või vastati ja kaotati tagasiteel. Igaüks neist osutab erinevale omanikule ja erinevale järgmisele käsule. "VPN-serverilt vastust pole" surub neli erinevat riket ühte lausesse, mida jäädvustus kunagi ei õigustanud.
Hoidke jäädvustused kitsad ja hoidke toores kerneli olek piletitest väljas, sest see võib kanda võtmematerjali, millel pole hostist välja asja. Loendurite erinevused ja ajatemplid on osad, mida tasub järgmisele inimesele üle anda.