Kapët trafikun në hostin IPsec, pe paketat ESP duke dalë, nuk pe asgjë duke u kthyer dhe përfundove se ana e largët është prishur. Kapja nuk e mbështet atë përfundim. ESP mbron një drejtim të bisedës dhe nuk konfirmon asgjë në nivelin IP, prandaj mungesa e ESP-së kthyese mund të nënkuptojë po aq lehtë se aplikacioni nuk kishte çfarë të thoshte, sa edhe se tuneli ka vdekur. Lexo shkëmbimin e brendshëm dhe gjendjen e anës pritëse përpara se të fajësosh cilindo skaj.

Miti: çdo paketë e mbrojtur merr një përgjigje

ESP nuk është protokoll kërkese-përgjigjeje. Kripton dhe vërteton çfarëdo që zgjedh politika, dhe marrësi e vërteton, e dekripton dhe e dorëzon atë paketë të brendshme pa gjeneruar një paketë të vetën. Një kërkesë UDP që destinacioni e shpërfill, ose një jehonë ICMP që politika hyrëse e hedh poshtë, prodhon heshtje në të dy drejtimet si rezultat i saktë. Trajtimi i asaj heshtjeje si dështim transporti të nis të kërkosh një defekt rrjeti që nuk ka ekzistuar kurrë.

Ajo që kapja njëdrejtimëshe vërteton në të vërtetë është se stiva e dërguesit kriptoi diçka në atë pikë vëzhgimi. Asgjë për mbërritjen dhe asgjë për qëllimin për të përgjigjur. Pyetja e dobishme nuk është „pse nuk ka përgjigje“, por „çfarë duhej të prodhonte biseda e brendshme“.

Dy SA, dy SPI, një bisedë

Shoqatat e sigurisë IPsec janë njëdrejtimëshe, prandaj një shkëmbim normal i mbrojtur drejton një shoqatë hyrëse dhe një shoqatë dalëse me identifikues të veçantë dhe gjendje të pavarur. Kërkimi i trafikut kthyes sipas SPI-së së paketës dalëse është prandaj gabim kategorie, sepse çdo përgjigje udhëton nën SA-në dalëse të vetë partnerit me SPI-në e vet. Në vend të kësaj përputh çiftin sipas përzgjedhësve të trafikut dhe adresave të partnerit.

Rikthimi i çelësit e ndërlikon pamjen për disa sekonda, pasi gjendja e vjetër dhe ajo zëvendësuese mund të mbivendosen. Nëse simptomi filloi rreth një rikthimi çelësi, mblidh identifikuesit e shoqatave dhe vulat kohore së bashku dhe jo vetëm emrin e lidhjes.

Çfarë duhet të bëjë marrësi përpara se diçka të përgjigjet

StageWhat to look atWrong conclusion if skipped
Sender encryptsoutbound SA packet counter"the tunnel is up"
Peer receivesinbound SA counter and replay window"the peer is down"
Inner deliverytarget host or service logs"routing is broken"
Application repliesthe app's own trace"the reply was dropped"
Protected returnthe peer's outbound SA"ESP only works one way"

Çdo rresht dështon në mënyrë të pavarur dhe çdo dështim ka një pronar tjetër, prandaj një kapje e vetme nuk mund t'i dallojë. Numëruesi hyrës është prova e vetme e drejtpërdrejtë e mbërritjes, sepse një paketë që nuk kalon vërtetimin ose kontrollin e përsëritjes hidhet poshtë pa asnjë përgjigje. Një partner numëruesi hyrës i të cilit nuk është lëvizur nuk të jep fare informacion për politikën e tij.

Dorëzimi është hap i veçantë nga dekriptimi. Gjendja mund të jetë e vlefshme dhe paketa prapëseprapë të hidhet më vonë nga një politikë hyrëse ose nga një rrugë që nuk përfshin destinacionin e brendshëm, prandaj kontrollo nëse hosti i synuar pa tekst të thjeshtë, në vend që të supozosh se një numërues i pastër do të thotë se paketa shkoi atje ku doje.

ESP vendës nuk është UDP

ESP vendës është protokolli IP 50, që nuk është as TCP as UDP dhe nuk ka fare porta. Prandaj një rregull muri zjarri që lejon IKE në UDP 500 nuk thotë asgjë për rrugën e të dhënave, dhe një filtër i shkruar rreth portave mund të lejojë tunelin të negociojë dhe më pas të hedhë poshtë gjithçka që transportohet brenda tij. Testo rrugën e të dhënave veçmas, në modalitetin që vëzhgove në të vërtetë.

Pas NAT forma ndryshon: ngarkesa e mbrojtur udhëton brenda UDP, zakonisht në portën 4500, siç përcakton RFC 3948. Regjistro modalitetin aktiv përpara se të shkruash çdo rregull, sepse një pajisje në rrugë mund ta trajtojë ESP-në vendëse dhe ESP-në e inkapsuluar në UDP krejt ndryshe, dhe disa kuti të mesme lejojnë njërën duke hedhur poshtë tjetrën.

Lexo numëruesit që i përkasin këtij incidenti

Në një host strongSwan, swanctl --list-sas raporton numërues paketash dhe bajtësh për çdo shoqatë në të dy drejtimet, gjë që mjafton për të ndarë „nuk mbërriti kurrë“ nga „mbërriti dhe nuk u përgjigj“. Në Linux, /proc/net/xfrm_stat numëron dështime të grumbulluara si gjendje që mungon, politikë që mungon dhe gabime protokolli. Ato shuma grumbullohen që nga nisja dhe i përkasin një hapësire të vetme emrash rrjeti, prandaj një numër i madh nuk është atribuim.

Merr dy lexime rreth dritares së incidentit në hapësirën e saktë të emrave dhe krahaso diferencat, përndryshe do t'i ngjitësh gabimet e javës së kaluar në biletën e pasdites së sotme. Vendos hapësirën e emrave dhe të dyja vulat kohore në biletë, që lexuesi i radhës të mund ta riprodhojë krahasimin në vend që t'i besojë një shume.

Emërto fazën, jo të dyshuarin

Një përfundim i dobishëm thotë ku u ndal paketa: nuk u prit kurrë, u prit dhe u hodh poshtë, u dorëzua por pa përgjigje, ose u përgjigj dhe u humb në rrugën e kthimit. Secili prej këtyre tregon një pronar tjetër dhe një komandë tjetër të radhës. „Asnjë përgjigje nga serveri VPN“ i shemb katër defekte të ndryshme në një fjali që kapja nuk e justifikoi kurrë.

Mbaji kapjet të ngushta dhe mbaj gjendjen e papërpunuar të kernelit jashtë biletave, sepse mund të mbajë material çelësi që nuk duhet të dalë nga hosti. Diferencat e numëruesve dhe vulat kohore janë pjesët që ia vlen t'i kalosh personit të radhës.

Artikuj të ngjashëm