Кил свич наставља да блокира саобраћај након прекида 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-ом

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

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