Utgeande ESP sûnder antwurd betsjut net dat de VPN dea is
ESP beskermet ien rjochting per assosjaasje en befestiget neat. Lienje de binnenste petear en de yngeande SA foardat jo de tsjinner ûnresponsive neame.
Jo hawwe ferkear op de IPsec-host opnommen, ESP-pakketten fuortgean sjoen, neat weromkommen sjoen en konkludearre dat de fierste kant stikken is. De opname stipet dy konklúzje net. ESP beskermet ien rjochting fan in petear en befestiget neat op de IP-laach, dus ûntbrekkende werom-ESP kin like maklik betsjutte dat de applikaasje neat te sizzen hie as dat de tunnel dea is. Lês de binnenste útwikseling en de tastân fan de ûntfangende kant foardat jo ien fan beide kanten de skuld jouwe.
De myte: elk beskerme pakket fertsjinnet in antwurd
ESP is gjin fraach-antwurdprotokol. It fersiferet en autentisearret wat it belied ek kiest, en de ûntfanger falidearret, ûntsiferelet en leveret dat binnenste pakket sûnder sels in pakket te meitsjen. In UDP-fraach dy't de bestimming negearret, of in ICMP-eko dy't it yngeande belied fuortsmyt, produsearret stilte yn beide rjochtingen as de juste útkomst. Dy stilte as in ferfiersflater behannelje stjoert jo op syk nei in netwurkflater dy't der nea wie.
Wat in ienrjochtingsopname eins bewiist, is dat de stapel fan de ôfstjoerder op dat observaasjepunt eat fersiferele hat. Neat oer oankomst, en neat oer de bedoeling om te antwurdzjen. De brûkbere fraach is net "wêrom is der gjin antwurd", mar "wat hie it binnenste petear produsearje moatten".
Twa SA's, twa SPI's, ien petear
IPsec-feiligensassosjaasjes binne ienrjochte, dus in normale beskerme útwikseling hat in yngeande en in útgeande assosjaasje mei aparte identifisearders en ûnôfhinklike tastân. It sykjen fan it weromferkear op de SPI fan it útgeande pakket is dêrom in kategoryflater, want elk antwurd reizget ûnder de eigen útgeande SA fan de partner mei syn eigen SPI. Keppelje it pear ynstee troch ferkearsselektors en adressen fan de partner.
Kaaifernijing makket it byld in pear sekonden tagelyk yngewikkelder, om't âlde en ferfangende tastân oerlaapje kinne. As it symptoom begûn om in kaaifernijing hinne, sammelje dan assosjaasje-identifisearders en tiidstimpels tegearre ynstee fan allinnich de namme fan de ferbining.
Wat de ûntfanger dwaan moat foardat eat antwurdet
| 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" |
Elke rige falt ûnôfhinklik en elke flater hat in oare eigner, dêrom kin ien opname se net ûnderskiede. De yngeande teller is it iennichste direkte bewiis fan oankomst, om't in pakket dat syn autentikaasje of replay-kontrôle net hellet sûnder hokker antwurd dan ek fuortsmiten wurdt. In partner waans yngeande teller net beweegd is, stjoert jo dus hielendal gjin ynformaasje oer syn belied.
Levering is in aparte stap fan ûntsifering. De tastân kin jildich wêze en it pakket dochs letter fuortsmiten wurde troch in yngeand belied of in rûte dy't de binnenste bestimming net omfettet, dus kontrolearje oft de doelmachine platte tekst sjoen hat ynstee fan oan te nimmen dat in skjinne teller betsjut dat it pakket gie dêr't jo it hawwe woene.
Lânseigen ESP is gjin UDP
Lânseigen ESP is IP-protokol 50, dat net TCP noch UDP is en hielendal gjin poarten hat. In firewallregel dy't IKE op UDP 500 tastean, seit dus neat oer it datapaad, en in filter skreaun om poarten hinne kin in tunnel ûnderhannelje litte en dan alles fuortsmite wat der yn ferfierd wurdt. Test it datapaad op himsels, yn de modus dy't jo echt observearre hawwe.
Efter in NAT feroaret de foarm: de beskerme lading reizget binnen UDP, meastentiids op poarte 4500, sa't RFC 3948 dat fêststelt. Registrearje de aktive modus foardat jo in regel skriuwe, om't in apparaat op it paad lânseigen ESP en UDP-ynkapsele ESP folslein oars behannelje kin, en guon middenkasten tastean it iene wylst se it oare fuortsmiten.
Lês tellers dy't by dit ynsidint hearre
Op in strongSwan-host rapportearret swanctl --list-sas pakket- en byteteallers per assosjaasje yn beide rjochtingen, wat genôch is om "nea oankommen" fan "oankommen en net beantwurde" te skieden. Op Linux telt /proc/net/xfrm_stat gearfoege flaters lykas ûntbrekkende tastân, ûntbrekkend belied en protokolfouten. Dy totalen accumulearje fanôf it opstarten en hearre by ien netwurknammeromte, dus in grut getal is gjin taskriuwing.
Nim twa lêzingen om it ynsidintfinster yn de juste nammeromte en fergelykje de ferskillen, oars plakke jo de flaters fan ferline wike op it kaartsje fan jûn. Set de nammeromte en beide tiidstimpels yn it kaartsje, sadat de folgjende lêzer de fergeliking reprodusearje kin ynstee fan op in totaal te fertrouwen.
Neam de faze, net de fertochte
In brûkbere konklúzje seit wêr't it pakket stoppe: nea ûntfongen, ûntfongen en fuortsmiten, levere mar ûnbeantwurde, of beantwurde en ferlern op de weromreis. Elk fan dy punten wiist op in oare eigner en in oare folgjende opdracht. "Gjin antwurd fan de VPN-tsjinner" bringt fjouwer ûnderskate flaters yn ien sin byinoar dy't de opname nea rjochtfeardige hat.
Hâld opnames smel, en hâld rauwe kerneltastân bûten kaartsjes, om't it kaaimateriaal drage kin dat neat bûten de host te sykjen hat. De tellerferskillen en de tiidstimpels binne de dielen dy't it wurdich binne om oan de folgjende persoan te jaan.