Tunelio nebėra, tinklo piktograma atrodo normaliai, o niekas neįkeliama. Atjungėte VPN, pašalinote jį arba perkrovėte sistemą, o blokas, kuris turėjo jus apsaugoti ryšiui nutrūkus, vis dar stovi. Kliento langas to negali paaiškinti, nes blokuoja ne klientas: sprendimas buvo įrašytas į branduolį jūsų vardu, ir nieko neliko, kad jį pašalintų. Windows sistemoje ta būsena yra Windows Filtering Platform; Linux sistemoje tai taisyklių rinkinys iptables arba nftables, dažnai su momentine kopija, kuri įkeliama paleidžiant. Štai kokia tvarka naudojuosi: perskaityti būseną, pašalinti siauriausią objektą, paaiškinantį gedimą, tada rasti tai, kas jį nuolat grąžina.

Apsauginis jungiklis yra branduolio būsena, o ne nustatymas

Darbalaukio klientai blokavimą įgyvendina pridėdami filtrus, kurie draudžia srautą už tunelio ribų. Windows sistemoje tai WFP filtrai connect-redirect ir transport sluoksniuose, o kai kurie iš jų yra nuolatiniai: jie įrašomi į Base Filtering Engine strategijos saugyklą ir atkuriami įjungiant mašiną, prieš paleidžiant bet kokią VPN programinę įrangą. Klientai skiriasi tuo, kada valosi. Vieni pašalina filtrus atjungiant, kiti tik tvarkingai išsijungus, dar kiti tik pirmiausia išjungus apsauginį jungiklį. Pašalinkite programą, kol blokas aktyvus, arba nutraukite procesą, ir filtrai liks.

Linux atitikmuo yra drop arba reject taisyklė išvesties kelyje, kartais persiuntimo taisyklė, kartais pakeista grandinės strategija. Tos taisyklės gyvena ilgiau už jas pridėjusį procesą, nes yra branduolio būsena: nutraukite klientą, priverskite jį nulūžti arba išjunkite maitinimą, o branduolys toliau meta paketus, ir nieko nelieka, kad tai atšauktų. Nuolatinumo paketas prideda antrą pastovumo sluoksnį: nufotografuoja esamą taisyklių rinkinį ir atkuria jį paleidžiant, todėl kitas paleidimas prasideda jau su įdiegtu bloku.

Perskaitykite WFP būseną prieš ką nors šalindami

Windows turi reikiamus įrankius. Paleiskite administratoriaus komandinę eilutę ir išsaugokite platformos būseną; išvestis atsiras kaip wfpstate.xml darbo kataloge.

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

XML faile ieškokite išėjusio tiekėjo pavadinimo, Block veiksmo ir sluoksnio. Filtrus, kurie sugriauna įprastą srautą, rasite connect-redirect ir transport sluoksniuose; receive-accept sluoksnio filtras paprastai nėra jūsų priežastis. Jei Base Filtering Engine visai neveikia, ieškokite kitur, nes niekas kitas negali įgyvendinti tų filtrų.

Patikrinkite ir įprastą ugniasienės vaizdą, nes dauguma žmonių apžiūri tik vieną iš dviejų:

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

Kai įmontuoti profiliai įjungti ir jokia taisyklė neatitinka nepavykstančio srauto, blokas ateina iš trečiosios šalies teikėjo, o ne iš Windows Firewall. Šis skirtumas lemia, kokį įrankį naudosite taisymui.

Skaitykite Linux taisykles ta sintakse, kuria šalinsite

iptables -S spausdina taisykles ta pačia forma, kokia jos buvo pridėtos, todėl išvestį galima tiesiogiai panaudoti šalinimui. iptables -L -v -n prideda paketų skaitiklius, o šie skaitikliai pasako, ar taisyklė tikrai atitinka nepavykusias užklausas, ar tik stovi grandinėje.

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

Skaitykite ne tik taisykles, bet ir grandinių strategijas: -P OUTPUT DROP blokuoja srautą net kai jokia taisyklė neatitinka. IPv6 tikrinkite atskirai, nes klientas, įdiegiantis abi šeimas, gali palikti IPv6 bloką, kai IPv4 taisyklių nebėra, o simptomas tada priklauso nuo to, kurią šeimą programa teikia pirmenybę. Ten, kur naudojamas nftables, paleiskite ir nft list ruleset; abu įrankiai sugyvena per suderinamumo sluoksnį, o vienas sąrašas nebūtinai parodo visas taisykles, galinčias numesti paketą.

Pašalinkite siauriausią objektą, paaiškinantį gedimą

Windows sistemoje pirmas žingsnis vis dar tiekėjo pašalinimo kelias: paleiskite diegimo programą iš naujo ir naudokite repair arba uninstall, arba paleiskite valymo įrankį, jei tiekėjas jį skelbia. Liktinės paslaugos ir suplanuotos užduotys yra dažnos, o užduotis, kuri paleidžia klientą prisijungus, kitą kartą įkėlus įdiegia jo filtrus iš naujo. Šalinimas, kuris nepavyksta skaitant kliento registro raktą, paprastai reiškia, kad paslauga ar užduotis jį dar laiko, o ne kad registras sugadintas.

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

Nuolatiniai filtrai yra paskutinė priemonė. Jie yra po HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, po vieną reikšmę kiekvienam filtrui, raktu GUID. Pirmiausia eksportuokite raktą, užsirašykite šalinamus GUID, šalinkite tik išėjusiam klientui priklausančias reikšmes, tada perkraukite, kad variklis atkurtų būseną. Nešalinkite viso rakto ir neišjunkite Base Filtering Engine: Windows Firewall ir Defender nuo jo priklauso, ir vieną gedimą iškeistumėte į blogesnį.

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

Linux sistemoje paimkite eilutę, kurią išspausdino iptables -S, ir pakeiskite -A į -D. Pašalinti vieną taisyklę, kurią nustatėte, geriau nei išvalyti grandinę, nes jūsų pačių strategija lieka nepažeista.

sudo iptables -D OUTPUT -p udp -j REJECT

Jei drop yra vartotojo apibrėžtoje grandinėje, pirmiausia pašalinkite šuolį į tą grandinę, o po to pašalinkite grandinę su -X. Nustatyti grandinės strategiją į ACCEPT, kol drop taisyklės dar yra, padeda tik paketams, kurie apskritai pasiekia strategijos sprendimą. Išvalyti visas lenteles yra paskutinė priemonė: tai pašalina ir taisykles, kurias pridėjote dėl kitų priežasčių, o įjungus ufw paslauga ima manyti valdanti grandines, kurių nebėra.

Raskite savininką, kuris tai grąžina

Po tiesioginio taisymo ieškokite to, kas atkurtų būseną. Linux sistemoje patikrinkite, ar įjungtas nuolatinumo įrenginys, ar klientas turi ugniasienės atkūrimo prisijungus nustatymą ir ar /etc kataloge yra išsaugotas taisyklių failas. Windows sistemoje dar kartą patikrinkite paleidimo įrašus, paslaugas ir suplanuotas užduotis, tada perkraukite ir perskaitykite būseną tomis pačiomis komandomis kaip anksčiau.

Jei blokas grįžta, šalinimas nebuvo sprendimas; sprendimas buvo savininkas. Užsirašykite, kuris klientas ar paslauga jį įdiegia, ir išjunkite funkciją ten, o ne kovokite su ja ugniasienės lygmenyje po kiekvieno atjungimo.

Tikrinkite tikru srautu, o ne vienu ping

Išbandykite vardo paiešką, TCP ryšį ir naują naršyklės sesiją, tada perkraukite ir pakartokite tuos pačius tris patikrinimus. Ping, kuris veikia, kai HTTPS nepavyksta, rodo į transport sluoksnio filtrą, o ne į tinklą, o blokas, kuris grįžta tik po perkrovimo, rodo į savininką, kurio dar neradote.

Išsaugokite įrodymus: eksportuotą BFE raktą arba iptables -S išvestį, užfiksuotą prieš pakeitimą. Prieš vadindami tai sutvarkytu, patvirtinkite, iš kurio sluoksnio pašalinote objektą, savininką, galintį jį įdiegti iš naujo, būseną po vieno švaraus perkrovimo ir kad įprastas naršymas veikia be VPN proceso. iptables(8) vadovo puslapyje yra tiksli šalinimo ir strategijos sintaksė, jei valymą rašote kaip scenarijų.

Susiję straipsniai