Блокиране на един диапазон за дестинация за всеки клиентски пул на VPN
Едно правило в nftables може да откаже префикс за дестинация за допуснат VPN пул, без да засяга собствения трафик на шлюза. Съобразете куката и позицията.
Едно правило може да държи допуснат VPN пул далеч от диапазон за дестинация, без да смущава нищо друго, което шлюзът прави. Самото правило е кратко; частите, които решават дали работи, са куката, в която живее, и позицията му във веригата. Сгрешете ли тези две, получавате защитна стена, която изглежда правилна и се държи непоследователно. Започнете от това какво прави пакетът, когато правилото го види.
Какво всъщност съпоставя правилото
Правилото съпоставя три неща наведнъж: входен интерфейс, префикс на източника и префикс на дестинацията. И трите трябва да са верни, преди да се приложи отхвърлянето, и точно това го прави тясно. Да го четете като един израз е по-лесно, отколкото като три отделни политики.
Съпоставянето на интерфейса отличава препратения клиентски трафик от собствените връзки на шлюза. Без него правило, което посочва само пула на източника, би засегнало и пакети, които шлюзът сам генерира от този адрес, ако някога го прави. Префиксът на източника ограничава политиката до допуснатите клиенти, а префиксът на дестинацията я ограничава до един диапазон. Четете правилото като сечение, а не като списък.
Запишете трите стойности, преди да редактирате нещо: името на тунелния интерфейс, пула, който сървърът раздава, и префикса, който възнамерявате да откажете. Печатна грешка в която и да е от тях дава правило, което се разбира чисто и не защитава нищо. Пазете тези три стойности в записа за промяната до правилото.
Куката решава към кого се прилага правилото
Веригата netfilter се прикачва към кука и куката решава кои пакети веригата изобщо вижда. Куката forward вижда трафик, маршрутизиран през шлюза, а това е трафикът от клиент към дестинация. Всичко останало във веригата е насочено към друга аудитория.
Куката input вижда трафик, адресиран до самия шлюз, така че правило, поставено там, управлява достъпа до собствените му услуги, а не транзита. Куката output вижда трафик, който шлюзът поражда, а това е обратното на това, което е нужно на политика за клиентски пул. Имената на веригите са произволни етикети, избрани от този, който е писал набора от правила, затова не извеждайте куката от името. Проверете къде е прикачена веригата, преди да предполагате какво може да съпостави.
| Hook | Traffic it sees | Right for this policy |
|---|---|---|
| input | Addressed to the gateway | No, that is the host's own services |
| forward | Routed through the gateway | Yes, for client-to-destination traffic |
| output | Generated by the gateway | No, that is the opposite direction |
Четенето на прикачването е проверка в един ред, която пречи на правило да попадне във верига, която никога не вижда пакета.
Поставете правилото преди широкото приемане
Правилата се оценяват по ред и първата присъда печели. Широко приемане по-рано във веригата прекратява оценката за пакетите, които съпоставя, така че отхвърляне, добавено след него, никога не се изпълнява за тях. Това правило за подредба е цялата причина правило, което изглежда правилно, да няма ефект.
Вмъкнете правилото преди приемането, вместо да го добавяте в края. Ако веригата вече съдържа общо приемане за тунелния интерфейс, новото правило трябва да го предхожда, иначе е само украшение. Проверете получения ред, а не файла, който редактирахте, защото набор от правила, сглобен от няколко файла, може да не съвпада с нито един от тях. След това потвърдете с тестов пакет от пула.
sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.confТретата команда разбира файла, без да го прилага, което хваща синтактични грешки, преди да станат прекъсване. Прилагайте с план за връщане назад, защото погрешно правило във веригата forward може да пререже тунела, през който работите.
Съществуващите потоци не се интересуват от новото ви правило
Запис в conntrack, създаден преди правилото да е съществувало, продължава да съпоставя по-ранното приемане. Затова ново отхвърляне понякога изглежда, че работи за нови връзки и не прави нищо за тази, която се тества.
Прочетете съпоставянето на състоянието в началото на веригата. Ако то приема established и related трафик преди вашето правило, всеки поток, който вече тече, продължава да тече, докато се затвори. Обикновено това е поведението, което искате за аварийно правило, и е объркващо, когато очаквате незабавно прекъсване. Решете какъв ефект искате, преди да разположите. Тест, който използва отново отворена връзка, ще ви разкаже погрешна история.
sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'Първата команда показва дали съществува поток, а втората — дали ранно правило за състояние продължава да го приема. И двете са само за четене и безопасни по време на инцидент.
Какво това правило не е
Правилото не е черен списък на домейни, политика за IPv6 или ограничение за отделен акаунт на приложение.
Всяко от тях се нуждае от собствен механизъм. Блокирането на домейн трябва да разрешава имена, каквото филтърът на пакети не прави. Трафикът IPv6 се нуждае от собствено съпоставяне, защото израз ip не казва нищо за пакети ip6. Ограничението на ниво приложение принадлежи на услугата или на удостоверено прокси, а не на съпоставяне на префикс. Точно разделянето на тези изисквания пречи едно тясно правило да бъде натоварено с четири задачи.
Договорът, който това правило дава, е точен: трафик от допуснат пул към един префикс на дестинация се отхвърля, а несвързаният трафик на шлюза запазва текущата си политика. Запишете това изречение до правилото и следващият човек ще знае за какво е било.