Защо tcpdump показва открит текст на IPsec само в една посока

Стартирате tcpdump на външния интерфейс на Linux IPsec шлюз и виждате две неща наведнъж: входящи ESP кадри и веднага след тях дешифрираните вътрешни пакети. В изходяща посока се вижда само ESP. Естественият извод е, че отговорите не се изпращат или че IPsec криптира едната посока и забравя другата. Нито едното не е вярно.

Това, което виждате, е точка на прихващане. Ядрото преобразува изходящите пакети, преди предавателният път на устройството да ги предаде на пакетния сокет, затова сокетът никога не вижда вътрешната форма при излизане. При входящите пакетът първо се прихваща като ESP и дешифрираното копие става видимо, когато отново влезе в стека. Същият трафик, два различни прозореца за наблюдение.

Точката на прихващане решава какво виждате

На нормален интерфейс AF_PACKET сокетът стои близо до слоя на устройството. Пакетите, напускащи хоста, първо преминават през обработката на изходния IPsec, която превръща вътрешен TCP сегмент в ESP или UDP-4500 датаграма, и едва след това достигат до този слой. Пристигащите пакети се копират в сокета, докато идват от кабела, все още криптирани, а дешифрираният резултат става видим по-късно, когато стекът го достави локално или го препрати.

Тази последователност обяснява асиметрията напълно. Тя не е доказателство за посока, политика или поведение на приложението и ако се третира като такова, хората започват да гонят отговор, който през цялото време е бил изпратен правилно. Това е една от малкото мрежови загадки, при които аномалията се създава от инструмента, а не от мрежата.

Съпоставете филтъра със слоя, който имате предвид

Израз като tcp port 443 избира вътрешна TCP връзка. В изходяща посока тази връзка вече е станала ESP, когато сокетът бъде питан, затова филтърът не съвпада с нищо. Ако искате да броите защитен трафик, филтрирайте по външната форма: протокол 50 за суров ESP или UDP порт 4500, когато се използва NAT traversal. И двата филтъра дават брой пакети, който може да се сравни между двата партньора, което обикновено е и причината да се брои. Нито един от тях не ви казва дали вътрешната заявка е получила отговор.

Не третирайте броя на UDP 4500 като брой ESP пакети. IKE също използва този порт за NAT-T съобщения за поддържане на връзката и за инкапсулирания обмен, така че числото включва трафик, който не е данните, които сте искали да измерите. Първоначалният IKE обмен на UDP 500 се нуждае от собствен филтър, ако това е въпросът. Число, което смесва контролен трафик с данни, също прави всяка оценка на честотната лента грешна с неизвестна граница. Отделните бройки отговарят на отделни въпроси.

Запишете филтъра до въпроса, на който отговаря. „Колко 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. Първо определете пътя, после изберете точката, която отговаря на въпроса, и очаквайте двете посоки да изглеждат различно само когато гледате грешната страна на преобразуването.