Неге 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 құрылғысы. Алдымен жолды анықтаңыз, содан кейін сұраққа жауап беретін нүктені таңдаңыз, және екі бағыт тек түрлендірудің дұрыс емес жағына қарағанда ғана өзгеше көрінеді деп күтіңіз.