Pēc VPN atvienošanas drošības slēdzis joprojām bloķē datu plūsmu

Tuneļa vairs nav, tīkla ikona izskatās normāli, un nekas neielādējas. Jūs atvienojāt VPN, atinstalējāt to vai pārstartējāt datoru, un bloks, kam bija jāaizsargā jūs savienojuma pārtraukuma laikā, joprojām stāv. Klienta logs to nevar izskaidrot, jo bloķē nevis klients: lēmums tika ierakstīts kodolā jūsu vārdā, un nekas netika atstāts, lai to noņemtu. Windows šis stāvoklis atrodas Windows Filtering Platform; Linux tas ir noteikumu kopums iptables vai nftables, bieži ar momentuzņēmumu, kas tiek atkārtoti ielādēts startēšanas laikā. Turpmāk ir secība, ko izmantoju: nolasīt stāvokli, izdzēst šaurāko objektu, kas izskaidro kļūmi, pēc tam atrast to, kas to nemitīgi atgriež.

Drošības slēdzis ir kodola stāvoklis, nevis iestatījums

Galddatora klienti bloķēšanu īsteno, pievienojot filtrus, kas aizliedz datu plūsmu ārpus tuneļa. Windows tie ir WFP filtri connect-redirect un transport slāņos, un daži no tiem ir pastāvīgi: tie tiek ierakstīti Base Filtering Engine politikas krātuvē un atjaunoti, kad iekārta startē, pirms jebkura VPN programmatūra sāk darboties. Klienti atšķiras ar to, kad tie sakārto. Daži noņem filtrus atvienošanas laikā, daži tikai tīras izslēgšanas laikā, bet daži tikai tad, ja vispirms tiek izslēgts drošības slēdzis. Atinstalējiet, kamēr bloks ir aktīvs, vai pārtrauciet procesu, un filtri paliks.

Linux ekvivalents ir drop vai reject noteikums izejas ceļā, dažkārt pārsūtīšanas noteikums, dažkārt mainīta ķēdes politika. Šie noteikumi dzīvo ilgāk par procesu, kas tos pievienoja, jo tie ir kodola stāvoklis: pārtrauciet klientu, izraisiet tā avāriju vai atslēdziet strāvu, un kodols turpina nomest paketes, un nekas nepaliek, lai to atceltu. Pastāvības pakotne pievieno otru pastāvības slāni, saglabājot pašreizējās noteikumu kopas momentuzņēmumu un atjaunojot to startēšanas laikā, tāpēc nākamā startēšana sākas ar jau instalētu bloku.

Pirms kaut ko dzēst, izlasiet WFP stāvokli

Windows ir komplektā nepieciešamie rīki. Palaidiet administratora uzvedni un izgūstiet platformas stāvokli; izvade parādīsies kā wfpstate.xml darba direktorijā.

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

XML failā meklējiet aizgājušā piegādātāja nosaukumu, Block darbību un slāni. Filtri connect-redirect un transport slāņos ir tie, kas sabojā parasto datu plūsmu; filtrs receive-accept slānī parasti nav jūsu cēlonis. Ja Base Filtering Engine vispār nedarbojas, meklējiet citur, jo nekas cits nevar īstenot šos filtrus.

Pārbaudiet arī parasto ugunsmūra skatu, jo lielākā daļa cilvēku apskata tikai vienu no diviem:

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

Kad iebūvētie profili ir ieslēgti un neviens noteikums neatbilst neveiksmīgajai datu plūsmai, bloks nāk no trešās puses piegādātāja, nevis no Windows Firewall. Šī atšķirība nosaka, kuru rīku izmantosiet labošanai.

Lasiet Linux noteikumus tādā sintaksē, kādā dzēsīsiet

iptables -S izdrukā noteikumus tādā pašā formā, kādā tie tika pievienoti, tāpēc izvadi var tieši izmantot dzēšanai. iptables -L -v -n pievieno pakešu skaitītājus, un šie skaitītāji parāda, vai noteikums patiešām atbilst neveiksmīgajiem pieprasījumiem, vai vienkārši stāv ķēdē.

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

Lasiet ne tikai noteikumus, bet arī ķēžu politikas: -P OUTPUT DROP bloķē datu plūsmu arī tad, kad neviens noteikums neatbilst. Pārbaudiet IPv6 atsevišķi, jo klients, kas instalē abas saimes, var atstāt IPv6 bloku pēc tam, kad IPv4 noteikumi ir pazuduši, un simptoms tad ir atkarīgs no tā, kurai saimei lietojumprogramma dod priekšroku. Vietās, kur tiek izmantots nftables, palaidiet arī nft list ruleset; abi rīki pastāv līdzās saderības slāņa dēļ, un viens saraksts ne vienmēr parāda visus noteikumus, kas var nomest paketi.

Izdzēsiet šaurāko objektu, kas izskaidro kļūmi

Windows pirmais solis joprojām ir piegādātāja paša noņemšanas ceļš: palaidiet instalētāju vēlreiz un izmantojiet repair vai uninstall, vai palaidiet tīrīšanas rīku, ja piegādātājs to publicē. Atlikušie pakalpojumi un plānotie uzdevumi ir izplatīti, un uzdevums, kas palaiž klientu pieteikšanās laikā, nākamajā startēšanā pārinstalē tā filtrus. Atinstalēšana, kas neizdodas, lasot klienta reģistra atslēgu, parasti nozīmē, ka pakalpojums vai uzdevums to joprojām tur, nevis to, ka reģistrs ir bojāts.

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

Pastāvīgie filtri ir pēdējais līdzeklis. Tie atrodas zem HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, viena vērtība katram filtram ar GUID atslēgu. Vispirms eksportējiet atslēgu, pierakstiet noņemamos GUID, dzēsiet tikai tās vērtības, kas pieder aizgājušajam klientam, pēc tam pārstartējiet, lai dzinējs atjaunotu stāvokli. Nedzēsiet visu atslēgu un neizslēdziet Base Filtering Engine: Windows Firewall un Defender ir no tā atkarīgi, un jūs apmainītu vienu traucējumu pret sliktāku.

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

Linux paņemiet rindu, ko izdrukāja iptables -S, un aizstājiet -A ar -D. Izdzēst vienu noteikumu, ko identificējāt, ir labāk nekā iztīrīt ķēdi, jo jūsu paša politika paliek neskarta.

sudo iptables -D OUTPUT -p udp -j REJECT

Ja drop atrodas lietotāja definētā ķēdē, vispirms izdzēsiet lēcienu uz šo ķēdi un pēc tam noņemiet ķēdi ar -X. Ķēdes politikas iestatīšana uz ACCEPT, kamēr drop noteikumi vēl ir, palīdz tikai tām paketēm, kas vispār sasniedz politikas lēmumu. Visu tabulu iztīrīšana ir pēdējais līdzeklis: tā noņem arī noteikumus, ko pievienojāt citu iemeslu dēļ, un ar iespējotu ufw pakalpojums sāk uzskatīt, ka tam pieder ķēdes, kuru vairs nav.

Atrodiet īpašnieku, kas to atgriež

Pēc tiešās labošanas meklējiet to, kas atjaunotu stāvokli. Linux pārbaudiet, vai ir iespējota pastāvības vienība, vai klientam ir ugunsmūra atjaunošanas pieteikšanās iestatījums un vai zem /etc ir saglabāts noteikumu fails. Windows vēlreiz pārbaudiet starta ierakstus, pakalpojumus un plānotos uzdevumus, pēc tam pārstartējiet un nolasiet stāvokli ar tiem pašiem noteikumiem kā iepriekš.

Ja bloks atgriežas, dzēšana nebija risinājums; risinājums bija īpašnieks. Pierakstiet, kurš klients vai pakalpojums to instalē, un atspējojiet funkciju tur, nevis cīnieties ar to ugunsmūra slānī pēc katras atvienošanas.

Pārbaudiet ar reālu datu plūsmu, nevis vienu ping

Pārbaudiet nosaukuma atrisināšanu, TCP savienojumu un jaunu pārlūka sesiju, pēc tam pārstartējiet un atkārtojiet tos pašus trīs testus. Ping, kas darbojas, kamēr HTTPS neizdodas, norāda uz transport slāņa filtru, nevis uz tīklu, un bloks, kas atgriežas tikai pēc pārstartēšanas, norāda uz īpašnieku, kuru vēl neesat atradis.

Saglabājiet pierādījumus: eksportēto BFE atslēgu vai iptables -S izvadi, kas tverta pirms izmaiņām. Pirms saucat to par labotu, apstipriniet slāni, no kura noņēmāt objektu, īpašnieku, kas to varētu pārinstalēt, stāvokli pēc vienas tīras pārstartēšanas un to, ka parastā pārlūkošana darbojas bez VPN procesa. iptables(8) rokasgrāmatas lapā ir precīza dzēšanas un politikas sintakse, ja tīrīšanu rakstāt kā skriptu.