Эмне үчүн tcpdump IPsec ачык текстин бир гана багытта көрсөтөт

Сиз Linux IPsec шлюзунун тышкы интерфейсинде tcpdump иштетесиз жана бир убакта эки нерсени көрөсүз: кирүүчү ESP кадрларын жана алардан кийин дароо эле чечилген ички пакеттерди. Чыгуу багытында гана ESP көрүнөт. Табигый жыйынтык — жооптор жөнөтүлбөйт же IPsec бир багытты шифрлеп, экинчисин унутат. Экөө тең туура эмес.

Сиз көрүп жаткан нерсе — кармоо чекити. Ядро чыгуучу пакеттерди түзмөктүн өткөрүү жолу аларды пакет сокетине бергенге чейин өзгөртөт, ошондуктан сокет чыгып бара жаткан ички форманы эч качан көрбөйт. Киришүүдө пакет адегенде ESP катары кармалат, ал эми декапсуляцияланган көчүрмө стекке кайра киргенде көрүнөт. Бирдей трафик, эки башка байкоо терезеси.

Кармоо чекити эмнени көрөрүңүздү аныктайт

Кадимки интерфейсте AF_PACKET сокети түзмөк катмарына жакын жайгашат. Хосттон чыккан пакеттер адегенде IPsec чыгуу иштетүүсүнөн өтөт, ал ички TCP сегментин ESP же UDP-4500 датаграммасына айландырат, анан гана ошол катмарга жетет. Келген пакеттер зымдан чыкканда, дагы эле шифрленген абалда сокетке көчүрүлөт, ал эми чечилген натыйжа стек аны жергиликтүү жеткиргенде же андан ары жөнөткөндө кийинчерээк көрүнөт.

Бул тартип асимметрияны толук түшүндүрөт. Бул багыт, саясат же колдонмо жүрүм-туруму жөнүндө далил эмес, жана аны ошентип кабыл алуу адамдарды башынан аягына чейин туура жөнөтүлгөн жооптун артынан куддуратат. Бул аномалияны тармак эмес, курал жараткан саналуу тармак табышмактарынын бири.

Чыпканы ойлогон катмарга ылайыкташтырыңыз

tcp port 443 сыяктуу туюнтма ички TCP байланышын тандайт. Чыгуу багытында сокеттен суралган учурда бул байланыш буга чейин эле ESP болуп калган, ошондуктан чыпка эч нерсеге дал келбейт. Эгер сиз корголгон трафикти санагыңыз келсе, анын ордуна тышкы форма боюнча чыпкалаңыз: чийки ESP үчүн 50 протоколу же NAT өтүүсү колдонулса, UDP 4500 порту. Эки чыпка тең эки тараптын ортосунда салыштырууга боло турган пакет санын берет, адатта саноонун себеби да ошол. Экөө тең ички суроого жооп берилдиби, айтпайт.

UDP 4500 санын ESP пакеттеринин саны катары кабыл албаңыз. IKE бул портту NAT-T өмүрдүүлүк билдирүүлөрү жана капсулаланган алмашуу үчүн да колдонот, ошондуктан сан өлчөгүңүз келген маалымат болуп эсептелбеген трафикти да камтыйт. UDP 500 аркылуу баштапкы IKE алмашуусу, эгер маселе ушул болсо, өзүнүн чыпкасын талап кылат. Башкаруу трафигин маалымат менен аралаштырган сан каалаган өткөрүү жөндөмүнүн баасын да белгисиз өлчөмгө туура эмес кылат. Өзүнчө саноолор өзүнчө суроолорго жооп берет.

Чыпканы ал жооп берген суроонун жанына жазып коюңуз. «Кутудан канча ESP чыкты» жана «веб-суроо кутудан чыктыбы» — бул ар башка чыпкалар менен жасалган ар башка өлчөөлөр, жана бир кармоо экөөнү тең чече албайт. Ошол жазуу болбосо, эки адам эч качан бир нерсени санабаган сандарды салыштырат.

Өзгөртүүгө чейин байкаңыз, кийин эмес

Эгер чыгуучу ачык текстти көрүү керек болсо, байкоо чекитин эртерек, IPsec чыгуу иштетүүсүнөн мурун жылдырыңыз. NFLOG сизге Netfilter илгичин берет, анда эреже тандалган пакеттерди колдонуучу мейкиндигиндеги сокетке көчүрө алат, аны tcpdump окуй алат. strongSwanдын трафикти төгүү жетекчилиги бул ыкманы дал ушул себептен документтештирет.

Саясат дал келүүсү эрежени туннелге кирүүгө тийиш болгон трафик менен чектейт. -m policy --pol ipsec --dir out эрежени куту жөнөткөн ар бир пакетти журналга жазуунун ордуна так кылат. Андан кийин журнал тобун чектелген кармоо менен окуңуз: кичине сүрөттөрдүн саны жана өлчөм чеги диагностиканын трафик архивине айланышына жол бербейт. Чектелген кармоону текшерүүчүгө берүү да оңой, тиешеси жок жүктү сүйрөөнүн кереги жок. Санды баштоодон мурун чечиңиз, канча келгенин көргөндөн кийин эмес.

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'

Илгичти агымга ылайык тандаңыз. OUTPUT шлюз өзү жараткан трафикти камтыйт; LAN кардарынан өтүү анын ордуна FORWARD тизмеги аркылуу өтөт, ал эми OUTPUTтеги эреже аны эч качан көрбөйт. Жогорудагы дарек жана порт бекитилген сыноо максаты үчүн орун толтургучтар.

Байкоо эмнени далилдейт

NFLOG — журналдоо объектиси, кабыл алуу чечими эмес. Ал жерде пайда болгон пакет анын илгичке жеткенин жана эрежеге дал келгенин көрсөтөт. Ал кийинки чыпка ага уруксат бергенин, түзмөк аны жөнөткөнүн же тарап бир нерсе алганын көрсөтпөйт.

Бош журнал да ушундай эки маанилүү. Эреженин пакет эсептегичин текшериңиз, багытты ырастаңыз, агым чын эле IPsec саясатына дал келгенин ырастаңыз жана багыттоону ырастаңыз. Эки тарапта тең дал келген эсептегич гана байкоону жыйынтыкка айландырат. Андан кийин ошол эле контролдонгон аракет үчүн эки тараптагы коопсуздук бирикмесинин эсептегичтерин салыштырыңыз, анткени SA эсептегичтери эмне корголуп, жөнөтүлгөнү тууралуу ыйгарымдуу жазуу.

Дагы бир тузак: бул контекстте «ачык текст» IPsec шифрлөө катмарынан тышкары дегенди билдирет. Ички HTTPS сессиясынын дагы эле өз TLSи бар. Декапсуляцияланган пакетти кармоо колдонмонун TLSин чечпейт, ал эми ал жерде окула турган HTTP көрүнсө, бул колдонмо башынан эле HTTPS колдонбогонун билдирет.

Тазалап, эки учун салыштырыңыз

Байкоо бүтөөрү менен киргизген так ошол эрежени, анын ээси боюнча алып салыңыз. Журналдоо эрежесин калтыруу ар бир дал келген пакетте CPU коротуп, маалыматты сактоо маселесин тынчтык менен жаратат. Өзүңүзгө таандык эмес тизмени тазалоонун ордуна эрежени -D менен кайталап жок кылыңыз.

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

Эгер жайгаштыруу колдонуучу мейкиндигиндеги IPsec, XFRM интерфейсин же аппараттык жүктөөнү азайтууну колдонсо, байкоо чекиттери жылат жана бул рецепт такыр колдонулбашы мүмкүн. libipsec менен ички трафикти байкоонун документтелген жери — TUN түзмөгү. Адегенде жолду аныктаңыз, андан кийин суроого жооп берген чекитти тандаңыз, жана эки багыт өзгөртүүнүн туура эмес тарабына караганда гана башкача көрүнөт деп күтүңүз.