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