Дистрибуционна защитна стена на Linux може да блокира VPN трафика ви

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

Намерете мениджъра и бекенда

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

Бекендът е толкова важен, колкото и фронтендът. Инсталация на firewalld може да управлява nftables или стария бекенд iptables в зависимост от версията и конфигурацията, и двете дават различен изход при проверка. Запишете дистрибуцията, версията и бекенда в тикета, преди да сравнявате системата си с което и да е ръководство.

Съпоставете посоката и интерфейса

Изходяща заявка от клиента, входящ слушател и препратен пакет преминават през различни куки, и правило за едното не покрива останалите. Зона, която разрешава локалната LAN, често не включва тунелния интерфейс или пула с адреси на VPN. Тунелният интерфейс обикновено попада в зоната по подразбиране, която често е по-строга от зоната на физическия адаптер. Това несъответствие обяснява защо сърфирането работи в LAN и спира в момента, в който тунелът се вдигне.

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

Дръжте собствениците на правила в съгласие

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

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

Проверете поправката, без да губите заключването

Проверете приложеното състояние с мениджъра, който го притежава, използвайки команди, съответстващи на записания бекенд. Списъкът по-долу предполага, че firewalld отговаря; заменете с еквивалента за nftables или ufw, вместо да пускате всички. Смесването на инструменти в една сесия е начинът машината да се сдобие с два конфликтни набора от правила.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=trusted --list-all
sudo nft list ruleset | head -40

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

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