Kial tcpdump montras IPsec-klartekston nur en unu direkto

Vi rulas tcpdump sur la ekstera interfaco de Linux IPsec-pordego kaj vidas du aferojn samtempe: envenantajn ESP-kadrojn kaj, tuj post ili, la malŝifritajn internajn pakojn. Elire apenas nur ESP. La natura konkludo estas, ke respondoj ne estas sendataj aŭ ke IPsec ŝifras unu direkton kaj forgesas la alian. Nek unu nek la alia veras.

Tio, kion vi rigardas, estas kaptopunkto. La kerno transformas elirantajn pakojn antaŭ ol la dissenda vojo de la aparato transdonas ilin al la paketa ŝtopilo, do la ŝtopilo neniam vidas la internan formon eliri. Envenante, la pako unue estas kaptata kiel ESP kaj la malenkapsuligita kopio videblas, kiam ĝi denove eniras la stakon. La sama trafiko, du malsamaj observfenestroj.

La kaptopunkto decidas, kion vi vidas

Sur normala interfaco, AF_PACKET-ŝtopilo sidas proksime al la aparata tavolo. Pakoj forlasantaj la gastiganton unue trapasas la IPsec-elirpretadon, kiu transformas internan TCP-segmenton en ESP- aŭ UDP-4500-datogramon, kaj nur poste atingas tiun tavolon. Alvenantaj pakoj estas kopiataj al la ŝtopilo dum ili venas de la drato, ankoraŭ ŝifritaj, kaj la malŝifrita rezulto videblas poste, kiam la stako liveras ĝin loke aŭ plusendas ĝin.

Tiu ordo plene klarigas la malsimetrion. Ĝi ne estas pruvo pri direkto, politiko aŭ aplika konduto, kaj trakti ĝin tiel sendas homojn post respondo, kiu estis ĝuste sendita la tutan tempon. Ĝi estas unu el la malmultaj retaj enigmoj, kie la instrumento, ne la reto, kreas la anomalion.

Agu la filtrilon al la tavolo, kiun vi celas

Esprimo kiel tcp port 443 elektas internan TCP-konekton. Elire, tiu konekto jam fariĝis ESP antaŭ ol la ŝtopilo estas demandata, do la filtrilo kongruas kun nenio. Se vi volas kalkuli protektitan trafikon, filtru laŭ la ekstera formo anstataŭe: protokolo 50 por kruda ESP, aŭ UDP-haveno 4500 kiam NAT-trapaso estas en ludo. Ambaŭ filtriloj donas pakokalkulon, kiun oni povas kompari inter la du partneroj, kio kutime estas la kialo kalkuli entute. Neniu el ili diras al vi, ĉu la interna peto ricevis respondon.

Ne traktu kalkulon de UDP 4500 kiel kalkulon de ESP-pakoj. IKE ankaŭ uzas tiun havenon por NAT-T-vivtenaj mesaĝoj kaj por la enkapsuligita interŝanĝo, do la nombro inkluzivas trafikon, kiu ne estas la datumoj, kiujn vi volis mezuri. La komenca IKE-interŝanĝo sur UDP 500 bezonas propran filtrilon, se tio estas la demando. Nombro, kiu miksas regadan trafikon kun datumoj, ankaŭ igas ĉiun bendlarĝan takson malĝusta je nekonata marĝeno. Apartaj kalkuloj respondas apartajn demandojn.

Skribu la filtrilon apud la demando, kiun ĝi respondas. «Kiom da ESP forlasis la skatolon» kaj «ĉu la retpetaĵo forlasis la skatolon» estas malsamaj mezuroj kun malsamaj filtriloj, kaj unu kapto ne povas solvi ambaŭ. Sen tiu noto, du homoj komparos nombrojn, kiuj neniam kalkulis la saman aferon.

Observu antaŭ la transformo, ne poste

Se vi bezonas vidi eliran klartekston, movu la observpunkton pli frue, antaŭ la IPsec-elirpretado. NFLOG donas al vi Netfilter-hokon, kie regulo povas kopii elektitajn pakojn al ŝtopilo en uzantspaco, kiun tcpdump povas legi. La trafikdumpinga gvidilo de strongSwan dokumentas ĉi tiun aliron ĝuste pro ĉi tiu kialo.

La politika kongruo limigas la regulon al trafiko, kiu baldaŭ eniros tunelon. -m policy --pol ipsec --dir out estas tio, kio igas la regulon specifa anstataŭ registri ĉiun pakon, kiun la skatolo sendas. Poste legu la protokolan grupon kun limigita kapto: malgranda nombro da momentkopioj kaj grando-limo malhelpas, ke la diagnozo fariĝu trafikarkivo. Limigita kapto ankaŭ pli facile transdoneblas al recenzanto sen treni nerilatan utilan ŝarĝon. Decidu la nombron antaŭ ol komenci, ne post kiam vi vidos, kiom alvenis.

iptables -I OUTPUT 1 -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
tcpdump -ni nflog:5 -s 128 -c 20 'host 10.83.0.44 and tcp port 8443'

Elektu la hokon laŭ la fluo. OUTPUT kovras trafikon, kiun la pordego mem generas; trapaso de LAN-kliento iras anstataŭe tra la ĉeno FORWARD, kaj regulo sur OUTPUT neniam vidos ĝin. La adreso kaj haveno supre estas lokokupiloj por aprobita testa celo.

Kion pruvas la observo

NFLOG estas protokolada celo, ne akcepta decido. Pako aperanta tie montras, ke ĝi atingis la hokon kaj kongruis kun la regulo. Ĝi ne montras, ke posta filtrilo permesis ĝin, ke la aparato transsendis ĝin aŭ ke la partnero ricevis ion.

Malplena protokolo estas same duba. Kontrolu la pakan kalkulilon de la regulo, konfirmu la direkton, konfirmu, ke la fluo efektive kongruis kun IPsec-politiko, kaj konfirmu la celon. Nur kongrua kalkulilo ĉe ambaŭ partneroj transformas observon en konkludon. Poste komparu la kalkulilojn de la sekureca asocio ĉe ambaŭ partneroj por la sama kontrolata provo, ĉar la SA-kalkuliloj estas la aŭtoritata registro pri tio, kio estis protektita kaj sendita.

Ankoraŭ unu kaptilo: «klarteksto» ĉi-kuntekste signifas ekster la IPsec-ŝifrotavolo. Interna HTTPS-sesio ankoraŭ havas sian propran TLS. Kapti la malenkapsuligitan pakon ne malŝifras la TLS de la aplikaĵo, kaj legi tie HTTP signifas, ke la aplikaĵo neniam uzis HTTPS.

Purigu kaj komparu ambaŭ finojn

Forigu la ĝustan regulon, kiun vi enmetis, laŭ ĝia posedanto, tuj kiam la observo finiĝos. Lasi protokolan regulon en loko kostas CPU ĉe ĉiu kongrua pako kaj kviete kreas datenretenan problemon. Forigu ĝin per ripeto de la regulo kun -D anstataŭ malplenigi ĉenon, kiun vi ne posedas.

iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5

Se la disfaldiĝo uzas uzantspacan IPsec, XFRM-interfacon aŭ aparatan malŝargon, la observpunktoj moviĝas kaj ĉi tiu recepto eble tute ne aplikeblas. Ĉe libipsec, la dokumentita loko por observi internan trafikon estas la TUN-aparato. Unue identigu la vojon, poste elektu la punkton, kiu respondas la demandon, kaj atendu, ke la du direktoj aspektos malsamaj nur kiam vi rigardas la malĝustan flankon de la transformo.