Нема 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.