Eliranta ESP sen respondo ne signifas, ke la VPN estas morta
ESP protektas unu direkton po asociiĝo kaj konfirmas nenion. Vicigu la internan interparolon kaj la envenan SA antaŭ ol nomi la servilon neresponda.
Vi kaptis trafikon sur la IPsec-gastiganto, vidis ESP-paketojn foriri, vidis nenion reveni kaj konkludis, ke la malproksima flanko estas difektita. La kaptaĵo ne subtenas tiun konkludon. ESP protektas unu direkton de interparolo kaj konfirmas nenion ĉe la IP-tavolo, do mankanta revena ESP povas same facile signifi, ke la aplikaĵo havis nenion por diri, kiel ke la tunelo estas morta. Legu la internan interŝanĝon kaj la staton de la riceva flanko antaŭ ol kulpigi ajnan flankon.
La mito: ĉiu protektita paketo meritas respondon
ESP ne estas protokolo de peto kaj respondo. Ĝi ĉifras kaj aŭtentigas tion, kion la politiko elektas, kaj la ricevanto validigas, malĉifras kaj transdonas tiun internan paketon sen generi propran paketon. UDP-demando, kiun la celo ignoras, aŭ ICMP-ekoo, kiun la envena politiko forĵetas, produktas silenton en ambaŭ direktoj kiel la ĝustan rezulton. Trakti tiun silenton kiel transportan difekton sendas vin ĉasi retan difekton, kiu neniam ekzistis.
Kion unudirekta kaptaĵo fakte pruvas, estas ke la stako de la sendanto ĉifris ion ĉe tiu observpunkto. Nenion pri alveno kaj nenion pri la intenco respondi. La utila demando ne estas "kial mankas respondo", sed "kion la interna interparolo devus esti produktinta".
Du SA, du SPI, unu interparolo
IPsec-sekurecaj asociiĝoj estas unudirektaj, do normala protektita interŝanĝo havas envenan kaj eliran asociiĝon kun apartaj identigiloj kaj sendependa stato. Serĉi la revenan trafikon laŭ la SPI de la elira paketo estas do kategoria eraro, ĉar ajna respondo vojaĝas sub la propra elira SA de la kunulo kun sia propra SPI. Parigu la paron laŭ trafikselektiloj kaj adresoj de la kunulo.
Ŝlosila regenerado komplikas la bildon dum kelkaj sekundoj samtempe, ĉar malnova kaj anstataŭa stato povas interkovriĝi. Se la simptomo komenciĝis ĉirkaŭ ŝlosila regenerado, kolektu asociiĝajn identigilojn kaj tempomarkojn kune anstataŭ nur la nomon de la konekto.
Kion la ricevanto devas fari antaŭ ol io respondos
| 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" |
Ĉiu vico malsukcesas sendepende kaj ĉiu malsukceso havas alian posedanton, kial unu kaptaĵo ne povas ilin distingi. La envena nombrilo estas la sola rekta pruvo de alveno, ĉar paketo, kiu malsukcesas sian aŭtentigon aŭ la kontrolon pri ripeto, estas forĵetata sen ajna respondo. Kunulo, kies envena nombrilo ne moviĝis, do sendas al vi neniun informon pri sia politiko.
Transdono estas aparta paŝo de malĉifrado. La stato povas esti valida kaj la paketo tamen poste forĵetita de envena politiko aŭ de itinero, kiu ne inkluzivas la internan celon, do kontrolu, ĉu la cela gastiganto vidis puran tekston, anstataŭ supozi, ke pura nombrilo signifas, ke la paketo iris tien, kien vi volis.
Indiĝena ESP ne estas UDP
Indiĝena ESP estas IP-protokolo 50, kiu estas nek TCP nek UDP kaj havas tute neniujn pordojn. Fajroŝirma regulo, kiu permesas IKE sur UDP 500, do diras nenion pri la datenvojo, kaj filtrilo skribita ĉirkaŭ pordoj povas lasi tunelon intertrakti kaj poste forĵeti ĉion portatan ene. Testu la datenvojon aparte, en la reĝimo, kiun vi efektive observis.
Malantaŭ NAT la formo ŝanĝiĝas: la protektita utilaĵo vojaĝas ene de UDP, kutime sur pordo 4500, kiel difinas RFC 3948. Registru la aktivan reĝimon antaŭ ol skribi ajnan regulon, ĉar aparato sur la vojo povas trakti indiĝenan ESP kaj UDP-enkapsuligitan ESP tute malsame, kaj iuj mezaj skatoloj permesas unu dum ili forĵetas la alian.
Legu nombrilojn, kiuj apartenas al ĉi tiu okazaĵo
Sur strongSwan-gastiganto swanctl --list-sas raportas pakaĵajn kaj bajtajn nombrilojn po asociiĝo en ambaŭ direktoj, kio sufiĉas por apartigi "neniam alvenis" de "alvenis kaj ne estis respondita". Sur Linux /proc/net/xfrm_stat kalkulas agregitajn malsukcesojn kiel mankanta stato, mankanta politiko kaj protokolaj eraroj. Tiuj sumoj akumuliĝas de la lanĉo kaj apartenas al unu reta nomspaco, do granda nombro ne estas atribuo.
Prenu du legaĵojn ĉirkaŭ la fenestro de la okazaĵo en la ĝusta nomspaco kaj komparu la diferencojn, alie vi alfiksos la erarojn de la pasinta semajno al la hodiaŭa bileto. Metu la nomspacon kaj ambaŭ tempomarkojn en la bileton, por ke la sekva leganto povu reprodukti la komparon anstataŭ fidi sumon.
Nomu la ŝtupon, ne la suspektaton
Utila konkludo diras, kie la paketo haltis: neniam ricevita, ricevita kaj forĵetita, transdonita sed ne respondita, aŭ respondita kaj perdita sur la revena vojo. Ĉiu el tiuj montras al alia posedanto kaj alia sekva komando. "Neniu respondo de la VPN-servilo" kunpremas kvar apartajn difektojn en unu frazon, kiun la kaptaĵo neniam pravigis.
Tenu kaptaĵojn mallarĝaj kaj tenu krudan kernan staton ekster biletoj, ĉar ĝi povas porti ŝlosilan materialon, kiu nenion havas por fari ekster la gastiganto. La nombrilaj diferencoj kaj la tempomarkoj estas la partoj indaj transdoniĝi al la sekva persono.