Klient on kadunud ja masin ei jõua endiselt kuhugi, mis ahvatleb tulemüüri tasa tegema ja otsast alustama. Ärge tehke seda. Blokeeriv olek võib tulla samal masinal kolmelt erinevalt omanikult ja igaühel on oma eemaldamistee. Kõige korraga läbipesemine eemaldab objekti, millest tahtsite vabaneda, koos kaitsega, mida te veel vajate, ja hävitab ka tõendi selle kohta, milline omanik probleemi põhjustas. Viis kontrolli järjekorras hoiavad seda ära.

Kontroll 1: mis on veel alles ja milleks see on

Otsige kolme artefakti eraldi: virtuaalne adapter, mis veel eksisteerib, tulemüüri filter või reegel, mis veel blokeerib, ning marsruut või poliitikareegel, mis veel osutab tunnelile, mida enam ei ole. Nende olemasolu iseenesest ei tõesta midagi, sest tahtlik hädaseiskaja näeb väljastpoolt välja täpselt samasugune nagu hüljatud.

Get-NetAdapter | Where-Object Status -eq 'Up'
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object Action -eq 'Block'
ip route show
ip -4 rule show

Kirjutage üles aeg, millal ühenduvus katkes, ja kas tavaline klient suudab veel oma tunnelit käivitada. Kui klient suudab tunneli taastada ja liiklus naaseb, teeb blokeering oma tööd ning probleem on kliendi olekus, mitte alles jäänud reeglis.

Kontroll 2: milline omanik seda juhib

Igal artefaktil on omanik. Virtuaalne adapter kuulub VPN-kliendile või selle draiverile. Filter võib kuuluda kliendile, platvormi enda tulemüürile või hallatavale turbetootele. Marsruudi võis klient ühendamise ajal paigaldada ja maha jätta.

Hallataval seadmel kontrollige enne millegi puutumist seadme poliitikat. Poliitikaga kehtestatud filter taastatakse järgmisel registreerimisel, nii et kohalik eemaldamine ostab tunni ja vastavusaruande. See vestlus kuulub administraatorile, mitte tulemüüri liidesele.

Kontroll 3: eemaldage kitsaim asi, mis seda selgitab

Alustage tarnija toetatud teekonnalt: paranduspaigaldus või korralik desinstallimine puhastab genereeritud oleku sageli õigesti, sealhulgas filtrid, mille käsitsi eemaldamine jätaks vahele. Lugege paigaldatud versiooni taastamisjuhiseid, sest järjekord on oluline ja ebaõnnestunud eemaldamise järel desinstallimine käitub teisiti.

Kui käsitsi kontrollimine on tõesti vajalik, kirjutage enne millegi muutmist üles reegli nimi, liides ja deklareeritud eesmärk ning eemaldage see objekt nime järgi. Iga võrguadapteri eemaldamine või kogu reeglistiku läbipesemine ühe kliendi tabamiseks on viis, kuidas tugijuhtumist saab ülesehitus.

Kontroll 4: DNS ja marsruudid elavad adaptereid üle

Nimelahenduse olek võib tunnelit üle elada. Resolveerija, mis osutab endiselt aadressile tunneli sees, mida enam ei ole, tekitab ajalõppe, mis näevad välja täpselt nagu tulemüüri drop, ja tavaline järeldus on vale.

resolvectl status
ip route get 1.1.1.1
nslookup example.com

Kui aadress laheneb ja toores ühendus IP kaudu töötab, on DNS ülejäänud probleem, mitte filtreerimine. Kui mõlemad ebaõnnestuvad, minge tagasi kontrolli juurde, marsruut ja filter käes.

Kontroll 5: testige mõlemat teed uuesti ja pange diagnostika tagasi

Kõigepealt kontrollige tavalist ühenduvust, seejärel iga allesjäänud VPN-profiili selle enda juhtelementide kaudu: ühendage, kasutage, katkestage ja kinnitage, et host on tagasi lihtsa ühenduvuse juures. See ringkäik on test, mis tõestab, et hüljatud blokeering on kadunud, mitte ainult mööda mindud.

Lõpuks taastage kõik diagnostilised muudatused, mille te teel tegite. Edukas puhastus eemaldab ühe hüljatud sõltuvuse; see ei eemalda hosti üldist kaitset ega tohiks maha jätta püsivalt lõdvendatud tulemüüri. Märkige üles, milline omanik blokeeringut hoidis, sest järgmine desinstallimine annab samad kolm kandidaati.

Seotud artiklid