Заштитниот прекинувач продолжува да го блокира сообраќајот откако VPN-от ќе се исклучи

Тунелот го нема, иконата за мрежа изгледа нормално, а ништо не се вчитува. Го исклучивте VPN-от, го деинсталиравте или го рестартиравте уредот, а блокот што требаше да ве заштити при прекин сѐ уште стои. Прозорецот на клиентот не може да го објасни тоа, бидејќи не ве блокира клиентот: одлуката е запишана во јадрото во ваше име и ништо не е оставено за да се отстрани. На Windows таа состојба е во Windows Filtering Platform; на Linux тоа е сет правила во iptables или nftables, често со снимка што се враќа при подигање. Следново е редот што го користам: прочитајте ја состојбата, избришете го најтесниот објект што го објаснува дефектот, потоа најдете што постојано го враќа.

Заштитниот прекинувач е состојба на јадрото, а не поставка

Десктоп клиентите го спроведуваат блокирањето со додавање филтри што го одбиваат сообраќајот надвор од тунелот. На Windows тоа се WFP филтри на connect-redirect и transport слоевите, а некои се постојани: се запишуваат во складиштето на политики на Base Filtering Engine и се враќаат при подигање на машината, пред да работи било каков VPN софтвер. Клиентите се разликуваат по тоа кога чистат. Некои ги отстрануваат филтрите при исклучување, некои само при чисто излегување, а некои само ако претходно се исклучи прекинувачот. Деинсталирајте додека блокот е активен, или прекинете го процесот и филтрите остануваат.

Еквивалентот на Linux е drop или reject правило во излезната патека, понекогаш forwarding правило, понекогаш изменета политика на синџир. Тие правила живеат подолго од процесот што ги додал бидејќи се состојба на јадрото: прекинете го клиентот, предизвикајте пад или исклучете струја и јадрото продолжува да ги отфрла пакетите, а ништо не останува за да го врати тоа. Пакетот за постојаност додава втор слој на трајност со снимка на тековниот сет правила и негово враќање при подигање, така што следното стартување почнува со веќе инсталиран блок.

Прочитајте ја WFP состојбата пред да избришете нешто

Windows ги има потребните алатки. Отворете администраторска конзола и извадете ја состојбата на платформата; излезот се појавува како wfpstate.xml во работниот директориум.

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

Во XML-от побарајте го името на заминатиот продавач, Block дејството и слојот. Филтрите на connect-redirect и transport се тие што го кршат обичниот сообраќај; филтер на receive-accept слој обично не е вашата причина. Ако Base Filtering Engine воопшто не работи, побарајте на друго место, бидејќи ништо друго не може да ги спроведе тие филтри.

Проверете го и обичниот приказ на огнениот ѕид, бидејќи повеќето луѓе проверуваат само еден од двата:

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

Кога вградените профили се вклучени и ниедно правило не одговара на сообраќајот што не успева, блокот доаѓа од трет добавувач, а не од Windows Firewall. Таа разлика одредува која алатка ќе ја користите за поправка.

Читајте ги 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 првиот чекор е сѐ уште патеката на продавачот за отстранување: повторно пуштете го инсталерот и користете repair или uninstall, или пуштете ја алатката за чистење ако продавачот ја објавува. Заостанати услуги и закажани задачи се чести, а задача што го стартува клиентот при најава повторно ги инсталира неговите филтри при следното подигање. Деинсталација што не успева додека го чита клучот на регистрацијата на клиентот обично значи дека услуга или задача сѐ уште го држи, а не дека регистрацијата е оштетена.

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 Firewall и 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

Ако drop-от е во кориснички дефиниран синџир, прво избришете го скокот кон тој синџир и потоа отстранете го синџирот со -X. Поставување на политиката на синџирот на ACCEPT додека drop правилата сѐ уште постојат помага само на пакетите што воопшто стигнуваат до одлуката за политика. Чистењето на сите табели е последно средство: ги отстранува и правилата што сте ги додале од други причини, а со вклучен ufw ја остава услугата во уверување дека поседува синџири што веќе не постојат.

Најдете го сопственикот што го враќа

По непосредната поправка, побарајте што би ја вратило состојбата. На Linux проверете дали е овозможена единица за постојаност, дали клиентот има поставка за враќање на огнениот ѕид при најава и дали постои зачувана датотека со правила под /etc. На Windows проверете ги повторно записите за стартување, услугите и закажаните задачи, потоа рестартирајте и прочитајте ја состојбата со истите команди како претходно.

Ако блокот се врати, бришењето не беше решението; сопственикот беше. Запишете кој клиент или услуга го инсталира и оневозможете ја функцијата таму, наместо да се борите со неа на слојот на огнениот ѕид по секое исклучување.

Проверете со вистински сообраќај, не со еден ping

Тестирајте resolve на име, TCP врска и нова сесија на прелистувач, потоа рестартирајте и повторете ги истите три проверки. Ping што работи додека HTTPS не успева упатува на филтер на transport слојот, а не на мрежата, а блок што се појавува само по рестартирањето упатува на сопственик што сѐ уште не сте го нашле.

Зачувајте ги доказите: извезениот BFE клуч или излезот од iptables -S снимен пред промената. Пред да го наречете поправено, потврдете го слојот од кој го отстранивте објектот, сопственикот што би можел повторно да го инсталира, состојбата по едно чисто рестартирање и дека обичното прелистување работи без VPN процес. Страницата од прирачникот iptables(8) ја има точната синтакса за бришење и политика ако чистењето го пишувате како скрипта.