Блокирането на IPv6 за защита на WireGuard чупи хоста
Правило, което изхвърля целия входящ IPv6, премахва и откриването на съседи, и Packet Too Big. Разделете три отговорности и после проверете, че хостът работи.
Целта е разумна: само потребителите на тунела трябва да достигат услугите на тази машина. Реализацията, към която посягат хората, е входяща верига IPv6, която изхвърля всичко освен WireGuard, а с това изхвърля и трафика, който държи хоста свързан със собствената му връзка. Откриването на съседи и съобщенията за поддръжка на пътя не са достъп до услуга и премахването им дава машина, недостъпна по причини, несвързани с вашата политика. Тунелът се вдига, услугите са правилно ограничени и нищо друго по връзката не работи.
Три отговорности, един набор правила
Първата отговорност е работата на външната мрежа: хостът трябва да остане свързан с връзката си, да разрешава съседи и да научава границите на пътя на тази връзка. Втората е шифрованият слушател, който приема UDP на избраните от вас адрес и порт. Третата е наборът от дешифрирани услуги, до които искате да достигат потребителите на тунела.
Това са три различни политики и само втората и третата се отнасят до VPN. Набор правила, който ги третира като едно, наследява режим на отказ, при който затягането на границата на приложението тихо чупи свързаността на хоста.
Дръжте ги в отделни вериги или поне в отделни коментари, за да види следващият човек кой ред за какво съществува.
Какво прави ICMPv6 за хоста
IPv6 разчита на ICMPv6 за много повече от ехо. Заявката и обявата за съсед заместват ARP и са необходими за локалната доставка. Packet Too Big носи информация за MTU на пътя и пренебрегването ѝ дава преноси, които засичат при големи пакети. Обявите на рутера носят маршрута по подразбиране и информация за префикса, когато връзката използва автоматична конфигурация.
RFC 4890 разделя съобщенията, които филтърът на хоста е длъжен да пропуска, от онези, които са административен избор, и прави това в раздел за хост, различен от правилата за рутер, който препраща между мрежи. Четенето само на раздела за препращане дава входяща политика, твърде строга за хоста, който защитава.
Практическото правило е да разрешите основните съобщения за грешки и конфигурация на интерфейса, който се нуждае от тях, ограничени по тип и източник, където платформата позволява, и да вземете явно решение за останалите.
Заменянето на всичко това с общо разрешение за ICMPv6 решава проблема с достъпността и се отказва от филтрирането. Заменянето му с общо изхвърляне решава проблема с филтрирането и се отказва от хоста.
Пуснете тунела, после услугата
Приемете транспорта WireGuard на предвидения външен адрес и UDP порт, а върнатия трафик приемете чрез проследяване на връзки. След това разрешете на приложните услуги да минават през интерфейса на тунела от източниците, на които наистина давате право.
Разрешението за външния UDP порт не дава право на дешифрираните заявки вътре в него. Точно това разграничение е причината интерфейсът на тунела да присъства в правилата за услуги.
Четете набора правила такъв, какъвто е, а не какъвто го описва файлът:
sudo nft list ruleset
ip -6 addr show
ip -6 route show default
Слушател на физически адрес е отделно излагане от същата услуга на адреса на тунела. Ако машината също препраща трафик към друга машина, това е решение на веригата за препращане, а не тази входяща политика, и изисква собствено обосноваване.
Проверете връзката, не само тунела
Работещ тунел след промяната доказва по-малко, отколкото изглежда, защото съществуващ запис за съсед и установена връзка могат да скрият контролно съобщение, което политиката сега изхвърля.
Проверете свързаността директно, после проверете, че изключеният път все още се проваля:
ip -6 neigh show
ping -6 -c 3 2001:db8:1::1
sudo nft -c -f /etc/nftables.conf
Таблица на съседите, която остава пълна след презареждане, е сигналът, че откриването още работи. Таблица, която се изпразва и никога не се пълни, е сигналът, че сте я филтрирали. Третата команда проверява синтаксиса на набора правила, без да го прилага, което си струва, докато още имате сесия.
Възстановете хост, от който сте се заключили
Преди да променяте правила на защитната стена, които носят собствената ви административна сесия, дръжте втори канал: конзола, серийна връзка или планирано връщане назад, което премахва новите правила, ако не го отмените.
Ако промяната наистина ви заключи, възстановяването е през този канал, а не през мрежата, която току-що премахнахте. Възстановете предишния набор правила от запазено копие, потвърдете, че хостът отново е достъпен, и едва тогава приложете предвидената политика на по-малки части.
Крайната политика не е универсална. Адресирането, маршрутизирането и реализацията на защитната стена са входни данни за внедряването, но границата е една и съща навсякъде: отказвайте нежелан достъп на приложения, като запазвате контролния трафик, който носи разрешения тунел.