Аварийният прекъсвач блокира само IPv4: защо IPv6 все още излиза

Набор от правила на защитна стена за IPv4 не казва нищо за IPv6. На устройство с двоен стек тунелът може да падне, докато приложение запазва работещ път около него.

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

Устройствата с двоен стек имат два независими изхода. Блокирането на единия от тях е половин блок.

Два набора правила, две настройки по подразбиране

В Linux iptables и ip6tables са отделни таблици с отделни политики. Задаването на веригите INPUT и OUTPUT на таблицата IPv4 на DROP не променя нищо в таблицата IPv6, където по подразбиране обикновено е ACCEPT. Същото разделение съществува в nftables, където можете да прегледате едно семейство и да откриете, че само едно от тях носи вашите правила. Тази асиметрия е нормална и в нея е целият проблем.

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

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

Какво ви казва конфигурацията на интерфейса

Страницата с документация на wg-quick включва правила за IPv6 в примерната си конфигурация и причината е точно тази празнина. Примерът не е украшение. Той съществува, защото само правилата за IPv4 биха оставили второто семейство отворено.

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

# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20

# nftables: inspect each family separately
sudo nft list ruleset inet | head -40

# does this host even have a usable IPv6 path?
ip -6 route show default

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

Защо едно търсене не е цялата история

Едно име може да върне и запис A, и запис AAAA, а приложенията не избират всички по един и същ начин. Браузърът може да предпочете IPv6, когато мрежата го предлага, и да се върне при неуспех, докато фонова синхронизация или програма за обновяване използва свой собствен резолвер и свои собствени предпочитания. Затова един успешен тест през IPv4 доказва един път, а не политиката.

Мрежовите преходи също променят отговора. Присъединяването към друга Wi-Fi мрежа, събуждането от заспиване или преминаването към мобилна мрежа може да даде на устройството нов префикс IPv6 и политиката, която изглеждаше достатъчна в офис LAN, може да не го покрива.

Тествайте състоянието, в което тунелът е спрян

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

# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/

И двете семейства трябва да се провалят затворено. Ако заявката IPv4 изтече по време, а заявката IPv6 върне код на състояние, политиката е непълна и никакво повторно тестване на тунела няма да промени това.

Запазете документираните изключения и в този тест. Откриването на локалната мрежа, подновяването на DHCP или пътят за първоначално свързване към крайната точка на VPN може да трябва да останат достъпни и тези изключения трябва да бъдат посочени в политиката, вместо да се откриват по време на прекъсване. Тест за изтичане, който се проваля, защото тунелът не може да се върне, не е откритие за сигурността, а откритие за свързаността.

Подобни статии