Авариен превключвател продължава да блокира трафика след изключване на VPN

Тунелът е изчезнал, иконата на мрежата изглежда нормална и нищо не се зарежда. Изключихте VPN, деинсталирахте го или рестартирахте, а блокировката, която трябваше да ви пази при прекъсване, още стои. Прозорецът на клиента не може да го обясни, защото клиентът не е това, което ви блокира: решението е записано в ядрото от ваше име и нищо не е останало, което да го премахне. В Windows това състояние се намира в платформата за филтриране на Windows; в Linux това е набор от правила в iptables или nftables, често със снимка, която се възпроизвежда при зареждане. Следва редът, който използвам: прочетете състоянието, изтрийте най-тесния обект, който обяснява проблема, после намерете каквото и да е, което продължава да го връща.

Аварийният превключвател е състояние на ядрото, а не настройка

Клиентите за настолен компютър осъществяват блокиране, като добавят филтри, които отказват трафик извън тунела. В Windows това са WFP филтри на слоевете за пренасочване на връзката и транспорт, а някои от тях са постоянни: записват се в хранилището на правилата на Base Filtering Engine и се възстановяват при зареждане на машината, преди да стартира какъвто и да е VPN софтуер. Клиентите се различават по това кога почистват. Някои премахват филтрите при изключване, други само при чисто затваряне, а трети само когато първо се изключи превключвателят. Деинсталирайте, докато блокировката е активна, или убийте процеса и филтрите остават.

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

Прочетете състоянието на WFP, преди да изтриете нещо

Windows носи нужните инструменти. Стартирайте повишен команден ред и изхвърлете състоянието на платформата; файлът се записва като wfpstate.xml в работната директория.

netsh wfp show state
netsh wfp show filters
Get-Service bfe

Търсете в XML името на напусналия доставчик, действие Block и слоя. Филтрите на пренасочването на връзката и транспорта са тези, които чупят обикновения трафик; филтър на слой за приемане на получаване обикновено не е вашата причина. Ако Base Filtering Engine изобщо не работи, търсете другаде, защото нищо друго не може да наложи тези филтри.

Проверете и обичайния изглед на защитната стена, защото повечето хора разглеждат само един от двата:

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

Когато вградените профили са включени и нито едно правило не съвпада с неуспешния трафик, блокировката идва от доставчик на трета страна, а не от защитната стена на Windows. Това разграничение решава кой инструмент ще използвате за поправката.

Четете правилата на Linux в синтаксиса, с който ще изтривате

iptables -S отпечатва правилата в същата форма, използвана за добавянето им, което прави изхода директно използваем за изтриване. iptables -L -v -n добавя броячи на пакети и тези броячи ви казват дали дадено правило наистина съвпада с неуспешните ви заявки, или просто стои във веригата.

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

Четете политиките на веригите, не само правилата: -P OUTPUT DROP блокира трафика дори когато нито едно правило не съвпада. Проверете IPv6 отделно, защото клиент, който инсталира и двете семейства, може да остави блокировката за IPv6 на място, след като правилата за IPv4 са изчезнали, и тогава симптомът зависи от това кое семейство предпочита приложението. Където се използва nftables, стартирайте и nft list ruleset; двата инструмента съжителстват чрез слой за съвместимост и един списък не показва непременно всяко правило, което може да изхвърли пакет.

Изтрийте най-тесния обект, който обяснява проблема

В Windows първата стъпка все още е собственият път за премахване на доставчика: стартирайте инсталатора отново и използвайте поправка или деинсталиране, или стартирайте инструмента за почистване, ако доставчикът публикува такъв. Остатъчните услуги и планирани задачи са обичайни, а задача, която стартира клиента при влизане, преинсталира филтрите му при следващото зареждане. Неуспешно деинсталиране при четене на регистърния ключ на клиента обикновено означава, че услуга или задача все още го държи, а не че регистърът е повреден.

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

Постоянните филтри са последна мярка. Те живеят под HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, една стойност на филтър с ключ GUID. Първо експортирайте ключа, запишете GUID-овете, които премахвате, изтрийте само стойностите, които принадлежат на напусналия клиент, после рестартирайте, за да може двигателят да изгради състоянието си наново. Не изтривайте целия ключ и не изключвайте Base Filtering Engine: защитната стена на Windows и Defender зависят от него и бихте разменили едно прекъсване за по-лошо.

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

В Linux вземете реда, отпечатан от iptables -S, и заменете -A с -D. Изтриването на едното правило, което сте идентифицирали, е по-добре от изчистване на верига, защото оставя собствената ви политика непокътната.

sudo iptables -D OUTPUT -p udp -j REJECT

Ако отхвърлянето живее във верига, дефинирана от потребителя, първо изтрийте прехода към тази верига и после премахнете веригата с -X. Задаването на политика ACCEPT, докато правилата за отхвърляне са още налице, помага само на пакети, които изобщо стигат до решението за политиката. Изчистването на всички таблици е последна мярка: то премахва и правила, добавени по други причини, а при включен ufw оставя услугата с убеждението, че притежава вериги, които вече не съществуват.

Намерете собственика, който го връща

След незабавната поправка потърсете каквото и да е, което би възстановило състоянието. В Linux проверете дали е включен модул за постоянство, дали клиентът има настройка за възстановяване на защитната стена при влизане и дали има запазен файл с правила под /etc. В Windows проверете отново записите за автоматично стартиране, услугите и планираните задачи, после рестартирайте и прочетете състоянието със същите команди.

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

Проверявайте с реален трафик, не с един ping

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

Пазете доказателствата: експортирания ключ BFE или изхода от iptables -S, заснет преди промяната. Преди да го наречете поправено, потвърдете слоя, от който сте премахнали обекта, собственика, който би могъл да го преинсталира, състоянието след едно чисто рестартиране и че обикновеното сърфиране работи без работещ VPN процес. Страницата на ръководството iptables(8) съдържа точния синтаксис за изтриване и политики, ако скриптувате почистването.