Izejošais ESP bez atbildes nenozīmē, ka VPN ir miris
ESP aizsargā vienu virzienu katrai asociācijai un neko neapstiprina. Saskaņojiet iekšējo sarunu un ienākošo SA, pirms saucat serveri par nereaģējošu.
Jūs ierakstījāt datu plūsmu IPsec resursdatorā, novērojāt izejošās ESP paketes, neredzējāt, ka kaut kas atgriežas, un secinājāt, ka tālā puse ir bojāta. Ieraksts šo secinājumu neatbalsta. ESP aizsargā vienu sarunas virzienu un IP slānī neko neapstiprina, tāpēc trūkstošais atgriezeniskais ESP var nozīmēt, ka lietojumprogrammai nebija ko teikt, tikpat labi kā to, ka tunelis ir miris. Izlasiet iekšējo apmaiņu un uztveršanas puses stāvokli, pirms vainojat kādu no pusēm.
Mīts: katra aizsargātā pakete saņem atbildi
ESP nav pieprasījuma un atbildes protokols. Tas šifrē un autentificē to, ko izvēlas politika, un uztvērējs pārbauda, atšifrē un piegādā šo iekšējo paketi, pats neģenerējot nevienu paketi. UDP vaicājums, ko galamērķis ignorē, vai ICMP atbalss, ko ienākošā politika atmet, abos virzienos rada klusumu kā pareizu iznākumu. Šāda klusuma uzskatīšana par transporta kļūmi aizved jūs meklēt tīkla bojājumu, kura nekad nav bijis.
Vienvirziena ieraksts patiesībā pierāda, ka sūtītāja steka šajā novērošanas punktā kaut ko šifrēja. Neko par ierašanos un neko par nodomu atbildēt. Noderīgais jautājums ir nevis „kāpēc nav atbildes“, bet „ko iekšējai sarunai vajadzēja radīt“.
Divas SA, divi SPI, viena saruna
IPsec drošības asociācijas ir vienvirziena, tāpēc parasta aizsargāta apmaiņa izmanto ienākošo asociāciju un izejošo asociāciju ar atsevišķiem identifikatoriem un neatkarīgu stāvokli. Atgriezeniskās plūsmas meklēšana pēc izejošās paketes SPI tāpēc ir kategorijas kļūda, jo jebkura atbilde ceļo ar partnera paša izejošo SA un tā SPI. Tā vietā saskaņojiet pāri pēc plūsmas selektoriem un partnera adresēm.
Atslēgas maiņa uz dažām sekundēm sarežģī ainu, jo vecais un aizvietojošais stāvoklis var pārklāties. Ja simptoms sākās ap atslēgas maiņu, vāciet asociāciju identifikatorus un laikspiedolus kopā, nevis tikai savienojuma nosaukumu.
Kas uztvērējam jāizdara, pirms kaut kas atbild
| 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" |
Katra rinda sabrūk neatkarīgi, un katrai kļūmei ir cits īpašnieks, tāpēc viens ieraksts nevar tās atšķirt. Ienākošais skaitītājs ir vienīgais tiešais ierašanās pierādījums, jo pakete, kas neiztur autentifikāciju vai atkārtošanas pārbaudi, tiek izmesta bez jebkādas atbildes. Tāpēc partneris, kura ienākošais skaitītājs nav kustējies, vispār nesniedz nekādu informāciju par savu politiku.
Piegāde ir atsevišķs solis no atšifrēšanas. Stāvoklis var būt derīgs, un pakete tomēr vēlāk tiek izmesta ar ienākošo politiku vai maršrutu, kas neietver iekšējo galamērķi, tāpēc pārbaudiet, vai mērķa resursdators redzēja atklātu tekstu, nevis pieņemiet, ka tīrs skaitītājs nozīmē, ka pakete nonāca tur, kur gribējāt.
Vietējais ESP nav UDP
Vietējais ESP ir IP protokols 50, kas nav ne TCP, ne UDP un kam vispār nav portu. Tāpēc ugunsmūra noteikums, kas atļauj IKE uz UDP 500, neko nepasaka par datu ceļu, un ap portiem veidots filtrs var ļaut tunelim vienoties un pēc tam nomest visu, kas tajā tiek nests. Pārbaudiet datu ceļu atsevišķi, tādā režīmā, kādu faktiski novērojāt.
Aiz NAT aina mainās: aizsargātā krava ceļo UDP iekšienē, parasti uz portu 4500, kā nosaka RFC 3948. Reģistrējiet aktīvo režīmu pirms jebkura noteikuma rakstīšanas, jo ierīce ceļā var pilnīgi atšķirīgi apstrādāt vietējo ESP un UDP iekapsulēto ESP, un dažas starpniekierīces atļauj vienu, bet atmet otru.
Lasiet skaitītājus, kas pieder šim incidentam
strongSwan resursdatorā swanctl --list-sas rāda katras asociācijas pakešu un baitu skaitītājus abos virzienos, ar ko pietiek, lai atšķirtu „nekad nav ieradies“ no „ieradās un netika atbildēts“. Linux sistēmā /proc/net/xfrm_stat skaita apkopotas kļūmes, piemēram, trūkstošu stāvokli, trūkstošu politiku un protokola kļūdas. Šīs kopsummas uzkrājas kopš palaišanas un pieder vienai tīkla vārdu telpai, tāpēc liels skaitlis nav attiecinājums.
Veiciet divus rādījumus ap incidenta logu pareizajā vārdu telpā un salīdziniet starpības, citādi jūs pagājušās nedēļas kļūdas pierakstīsiet šīs pēcpusdienas biļetei. Ierakstiet biļetē vārdu telpu un abus laikspiedolus, lai nākamais lasītājs varētu atkārtot salīdzinājumu, nevis uzticēties kopsummai.
Nosaucet posmu, nevis aizdomās turamo
Noderīgs secinājums pasaka, kur pakete apstājās: nekad nav saņemta, saņemta un izmesta, piegādāta, bet bez atbildes, vai atbildēta un pazaudēta atceļā. Katrs no šiem norāda uz citu īpašnieku un citu nākamo komandu. „Nav atbildes no VPN servera“ sablīvē četras atšķirīgas kļūmes vienā teikumā, ko ieraksts nekad nav attaisnojis.
Turiet ierakstus šaurus un neiekļaujiet biļetēs neapstrādātu kodola stāvokli, jo tas var saturēt atslēgu materiālu, kam nav jāatstāj resursdators. Skaitītāju starpības un laikspiedoli ir tās daļas, ko ir vērts nodot nākamajam cilvēkam.