Чаму tcpdump паказвае адкрыты тэкст IPsec толькі ў адным кірунку

Вы запускаеце tcpdump на знешнім інтэрфейсе шлюза IPsec пад Linux і бачыце дзве рэчы адначасова: уваходныя кадры 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. Спачатку вызначце шлях, потым выберыце пункт, які адказвае на пытанне, і чакайце, што два кірункі будуць выглядаць па-рознаму толькі тады, калі вы глядзіце на няправільны бок пераўтварэння.