Няма tun0? Супастаўляйце расшыфраваны IPsec у nftables праз meta ipsec

Вы чакаеце інтэрфейс тунеля, шукаеце яго і не знаходзіце ў міжсеткавым экране нічога, з чым можна супаставіць. Гэта нармальна для шлюза на аснове палітык: зашыфраваны абмен прыходзіць на фізічны інтэрфейс, і расшыфраваны ўнутраны пакет, які потым перасылаецца далей, таксама назіраецца як прыходзячы на той самы інтэрфейс. tun0 няма, бо нішто яго не стварыла.

Унутраны запыт усё яшчэ асобны пакет са сваёй крыніцай, прызначэннем і службай, і ядро ведае, з якой асацыяцыі бяспекі ён выйшаў. Менавіта гэтае веданне правіла міжсеткавага экрана можа супаставіць.

Два пакеты, адзін інтэрфейс

Уявіце ўваходны кірунак. Прыходзіць пакет, інкапсуляваны ў ESP або UDP, ядро знаходзіць адпаведную палітыку, расшыфроўвае яго і перадае адкрыты пакет на шлях перасылкі. Правіла, якое глядзіць толькі на імя інтэрфейса, не можа адрозніць гэты пакет ад любога іншага трафіку, што прыходзіць на той самы провад.

Адрознівае яго кантэкст уваходнага шляху бяспекі, прывязаны да пакета. nftables паказвае яго як meta ipsec exists, што праўдзіва, калі пакет прыйшоў праз шлях бяспекі IPsec. Спалучыце яго з пулам кліентаў, прызначэннем і службай, і правіла стане дастаткова дакладным, каб быць бяспечным.

Прапускаць кантэкст — звычайная памылка, і гэта памылка бяспекі, а не касметычная. Правіла, якое прымае ўсё з пула кліентаў, з такой жа ахвотай прыме падроблены пакет з лакальнай сеткі, бо адрас крыніцы сам па сабе не з'яўляецца доказам чаго-небудзь. Кантэкст шляху бяспекі — самы танны спосаб зрабіць крыніцу значным. Пішыце правіла з ім ад пачатку, а не дадавайце пасля аўдыту.

Напішыце правіла перасылкі

Выкажам здагадку, што ёсць аўтэнтыфікаваная служба аддаленага доступу IPv4 з кліентамі ў 10.90.0.0/24 і адно адабранае прызначэнне на 203.0.113.40. Фрагмент правіла для гэтага патоку выглядае так.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

Адрасы і інтэрфейс — гэта прыклады, якія трэба замяніць. Змясціце правераны эквівалент у палітыку перасылкі перад правілам, якое інакш адхіліла б паток, і не ачышчайце існуючы набор правіл, каб яго ўсталяваць; шлюз — не эксперымент у чыстым пакоі.

Тэрмін oifname варта пакінуць. Ён дакументуе рашэнне аб выхадзе і не дазваляе правілу супаставіцца ў кірунку, які вы не мелі на ўвазе, а гэта важна на шлюзе з некалькімі шляхамі ў інтэрнэт. На тэставым камп'ютары з адным выхадным каналам тэрмін выглядае лішнім, і менавіта таму яго выкідаюць перад тым, як камп'ютар атрымае другі канал.

Дазволы для знешняга абмену асобныя. Уваходны шлях шлюза патрабуе партоў IKE і ESP або інкапсуляцыі UDP, якія ён фактычна выкарыстоўвае, і гэтыя дазволы нічога не дазваляюць адносна расшыфраванага пакета ўнутры. Змешванне двух — гэта шлях, якім працоўны тунель атрымлівае міжсеткавы экран, што перасылае ўсё.

Уваходны кантэкст — не выхадны кантэкст

Тая ж сям'я выразаў ахоплівае іншы кірунак праз rt ipsec, які апісвае выхадную асацыяцыю бяспекі, якую будзе выкарыстоўваць пакет. Ён адказвае на іншае пытанне: не адкуль прыйшоў гэты пакет, а ці будзе ён абаронены на наступным участку.

Гэтае адрозненне важнае на шлюзе, які адначасова завяршае адзін тунель і перасылае ў іншы. Пакет можа прыйсці расшыфраваным і ўсё ж павінен сысці зашыфраваным, а прыём, напісаны толькі для ўваходнага кантэксту, нічога не кажа пра выхадную патрабу. Калі палітыка патрабуе такой абароны, набор правіл павінен выразіць гэта, а не меркаваць, што маршрутызацыя ўладкуе гэта.

Трымайце два пытанні ў асобных правілах, каб чытач бачыў, якое з іх выконваецца. Адно разумнае правіла, якое правярае абодва, складаней разглядаць і нашмат складаней адладжваць, калі адна яго палова перастае супастаўляцца. Два правілы з лічыльнікамі таксама падказваюць, якая патраба не выконваецца, чаго аб'яднанае правіла ніколі не зробіць.

NAT — гэта не рашэнне міжсеткавага экрана

Трафік у інтэрнэт з прыватнага пула кліентаў звычайна патрабуе трансляцыі крыніцы, каб адказ знайшоў зваротны шлях. Але трафік, абраны для іншай выхадной палітыкі IPsec, павінен захаваць патрэбнае вызваленне, і маскаванне кожнай прыватнай крыніцы без роздуму пра наступнае рашэнне аб абароне гэта ламае.

Прыём унутры ланцуга NAT таксама не агульны дазвол. NAT і фільтраванне маюць розныя задачы, і ланцуг NAT не правярае кожны наступны пакет усталяванага патоку, і менавіта таму разлік на яго для бяспекі стварае правілы, якія выглядаюць працоўнымі на тэсце і адмаўляюць пад нагрузкай.

Адваротнае таксама праўдзіва і застае людзей знянацку: прыём дзесьці ў адным базавым ланцугу фільтра нічога не важыць супраць пазнейшага адхілення ў іншым прымяняльным ланцугу. Вынік вызначаюць парадак і ахоп ланцуга, а не наяўнасць прыёму ў файле.

Праверце дакладную ўнутраную службу

Праверце канкрэтнае прызначэнне і порт, якія вы дазволілі, з рэальнага кліента і пераканайцеся, што адказ вяртаецца. Затым праверце тое, што вы не дазволілі, і ўпэўніцеся, што яно не праходзіць, бо занадта шырокае правіла праходзіць першы тэст гэтак жа добра, як правільнае. Запыт, які ўвогуле не пакідае кліента, таксама не з'яўляецца вынікам міжсеткавага экрана, таму чытайце лічыльнікі, каб убачыць, ці пакет наогул ацэньваўся. Два тэсты і адно чытанне лічыльніка паведамяць вам больш, чым пасляабедзенная гадзіна чытання набору правіл.

Даведнік nftables дакументуе meta ipsec, rt ipsec і выразы, спецыфічныя для кірунку, і менавіта там варта звяраць сінтаксіс з усталяванай версіяй. І трымайце ахоп ясным: гэта прыклад IPv4, ён нічога не кажа пра IPv6 і не ператварае адвольную перасылку публічных партоў у частку службы VPN.