nftables: вмъкнете правилото за разрешаване на VPN преди идентификатора за отхвърляне

Поставете правило за разрешаване на грешно място и то се държи като липсващо правило. В nftables изборът между insert и add решава от коя страна на посочено правило ще попадне новото изявление, а идентификаторът именува правилото в живия набор от правила, а не номера на реда му. Сгрешете ли мястото, пакетът първо стига до отхвърлянето.

Сравнението по-долу използва един фиксиран партньор и един обмен на външен слушател. То е умишлено тясно; замяната на цяла верига е друга промяна с друг профил на риск.

Две позиции, два различни резултата

insert поставя правило преди посоченото правило. add го поставя след него. Ако посоченото правило е крайното отхвърляне за потока, тези две команди дават противоположни резултати, дори когато текстът на правилото е идентичен.

Пропускането на местоположение има собствено поведение по подразбиране, което е още една причина да не копирате команда от форум, без да прочетете към какво е закотвена. Котвата е цялото решение. Запишете желаната страна, преди да въведете командата. insert и add се различават с една дума във файла.

Позицията е относителна към правило в конкретна верига. Преместването на същото изявление в друга верига или друг приоритет на hook променя кои пакети вижда, дори когато синтаксисът на правилото изглежда правилен.

Идентификаторът обозначава правило, а не номер на ред

Идентификатор като 42 е идентификатор в текущото състояние на набора от правила. Той не е четиридесет и второто правило и не е стабилен между хостове, преизграждания или мениджър, който презарежда конфигурацията си.

Намерете веригата и действителното крайно отхвърляне, преди да изберете котвата. След това потвърдете идентификатора на това правило в същия списък, който показва отхвърлянето, така че номерът и правилото да се четат заедно. Идентификатор, прочетен от стар списък, може вече да принадлежи на друго правило. Прочетете го отново в сесията, която ще приложи промяната.

iptables --version
nft -a list ruleset

Версията на iptables показва кой бекенд се използва. Набор от правила iptables-nft и независимо управлявана родна таблица могат да съществуват заедно, така че списък от един фронтенд не е автоматично пълната картина на филтрирането. Проверете и двете гледни точки, преди да изберете верига.

Намерете веригата и правилото, което наистина отхвърля

Прочетете hook за вход, приоритета на веригата и правилото, което отхвърля този поток на слушателя. Таблица inet може да носи и двете семейства адреси, но отделно правило все още може да съвпада само с IPv4.

Вземете един одобрен партньор, като използвате 198.51.100.25 от диапазона за документация като пример. Прегледан роден файл може да постави външно разрешаване преди идентификатор 42:

insert rule inet filter input handle 42 iifname "eth0" ip saddr 198.51.100.25 udp dport { 500, 4500 } counter accept

Сменете семейството, таблицата, веригата, идентификатора, входния интерфейс и партньора след проверка. Примерът използва формата за позициониране по идентификатор, документирана за nft 1.0.9, и тя принадлежи във входен файл; цитирането на скоби е отделен въпрос, когато командата се въвежда интерактивно.

Дръжте собственика на конфигурацията ясен. Мениджър, който преизгражда правилата си, може да презапише промяна по време на изпълнение, а скрипт за зареждане, който твърдо кодира остарял идентификатор, или ще се провали, или ще се закачи за грешното правило.

Разрешаването е ограничено, отхвърлянето е окончателно

Присъдата за разрешаване прекратява оценката по текущия път, но по-късна приложима базова верига все още може да отхвърли пакета. Присъдата за отхвърляне е окончателна. Затова растящият брояч на разрешаванията не е доказателство, че потокът е успял.

Проверете всички относими приоритети на hook, вместо една верига изолирано. Пакет може да премине входен филтър и пак да бъде отхвърлен от hook на друга таблица с различен приоритет. Избројте всяка базова верига, която вижда потока.

Това правило покрива само обмена на външния слушател. ESP с транспортно инкапсулиране, роден ESP, партньори IPv6 и дешифрираният трафик в тунела — всички те се нуждаят от собствени политики. Това не е пълна защитна стена за сайтов VPN.

Проверете файла, след което потвърдете живия резултат

Изпълнете проверка на синтаксиса и транзакцията върху прегледания файл, преди да го приложите. Режимът за проверка съобщава дали nft може да анализира и подготви промяната; той не я прилага и не доказва, че друг hook ще разреши пакета. Файлът остава предложение, докато собственикът не го приложи:

nft -c -f reviewed-vpn-rule.nft

Приложете чрез контролирания процес на собственика и запазете достъп за възстановяване. Ако правилото е грешно, отхвърлянето, което сте се опитвали да предхождате, може да пререже и пътя, който използвате, за да го поправите.

След промяната наблюдавайте нов опит на разрешен партньор и проверете, че източниците извън одобрения партньор все още се отказват. Преместете трайното правило в мениджъра, който притежава набора от правила, защото идентификаторите по време на изпълнение намират текущи обекти, а не ги идентифицират между зарежданията.