Neniu interreto post malinstalo de la VPN? Kontrolu tri posedantojn
Restinta adaptilo, filtrilo aŭ itinero povas postvivi la klienton. Kontrolu la tri posedantojn, forigu la plej mallarĝan objekton, poste retestu rektan aliron kaj tunelan aliron.
La kliento foriris kaj la maŝino ankoraŭ ne atingas ion ajn, kio logas ebenigi la fajroŝirmilon kaj komenci denove. Ne faru tion. Blokanta stato povas veni de tri malsamaj posedantoj sur la sama maŝino, kaj ĉiu havas sian propran forigvojon. Elverŝi ĉion samtempe forigas la objekton, kiun vi volis forigi, kune kun protekto, kiun vi ankoraŭ bezonas, kaj ĝi ankaŭ detruas la pruvon pri tio, kiu posedanto kaŭzis la problemon. Kvin kontroloj, laŭ ordo, malhelpas tion.
Kontrolo 1: kio ankoraŭ estas, kaj por kio ĝi utilas
Serĉu la tri artefaktojn aparte: virtualan adaptilon, kiu ankoraŭ ekzistas, fajroŝirmilan filtrilon aŭ regulon, kiu ankoraŭ blokas, kaj itineron aŭ politikan regulon, kiu ankoraŭ montras al tunelo, kiu ne plu ekzistas. Ilia ĉeesto mem pruvas nenion, ĉar intenca mortigŝaltilo aspektas de ekstere same kiel forlasita.
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
Notu la tempon, kiam la konektebleco ĉesis, kaj ĉu la normala kliento ankoraŭ povas lanĉi sian tunelon. Se la kliento povas restarigi la tunelon kaj trafiko revenas, la blokado faras sian taskon kaj la problemo estas la stato de la kliento, ne restinta regulo.
Kontrolo 2: kiu posedanto regas ĝin
Ĉiu artefakto havas posedanton. La virtuala adaptilo apartenas al la VPN-kliento aŭ al ĝia pelilo. La filtrilo povas aparteni al la kliento, al la propra fajroŝirmilo de la platformo aŭ al administrata sekureca produkto. La itineron eble instalis la kliento ĉe konektiĝo kaj lasis ĝin malantaŭe.
Sur administrata ekipaĵo, kontrolu la aparatan politikon antaŭ ol tuŝi ion ajn. Filtrilo devigita de politiko estos restarigita ĉe la sekva ensaluto, do loka forigo aĉetas horon kaj konforman raporton. Tiu konversacio apartenas al la administranto, ne al la fajroŝirmila interfaco.
Kontrolo 3: forigu la plej mallarĝan aferon, kiu klarigas ĝin
Komencu per la subtenata vojo de la vendanto: ripare instalo aŭ taŭga malinstalo ofte ĝuste purigas generitan staton, inkluzive de filtriloj, kiujn mana forigo maltrafus. Legu la restaŭrajn instrukciojn por la instalita versio, ĉar la sinsekvo gravas kaj malinstalo post fuŝa forigo kondutas alie.
Se mana inspektado vere necesas, notu la regulan nomon, la interfacon kaj la deklaran celon antaŭ ol ŝanĝi ion ajn, kaj forigu tiun objekton laŭnome. Forigi ĉiun retan adaptilon aŭ elverŝi la tutan regularon por celi unu klienton estas la maniero, kiel subtena kazo fariĝas rekonstruo.
Kontrolo 4: DNS kaj itineroj postvivas adaptilojn
Solva stato povas postvivi la tunelon. Solvilo, kiu ankoraŭ montras al adreso ene de tunelo, kiu ne plu ekzistas, produktas tempolimojn, kiuj aspektas precize kiel fajroŝirmila forĵeto, kaj la kutima konkludo estas la malĝusta.
resolvectl status
ip route get 1.1.1.1
nslookup example.com
Se la adreso solviĝas kaj kruda konekto per IP funkcias, DNS estas la restanta problemo, ne filtrado. Se ambaŭ malsukcesas, reiru al kontrolo unu kun la itinero kaj la filtrilo enmane.
Kontrolo 5: retestu ambaŭ vojojn kaj remetu la diagnostikon
Unue kontrolu ordinaran konekteblecon, poste ĉiun restantan VPN-profilo per ĝiaj propraj regiloj: konektiĝu, uzu ĝin, malkonektiĝu, kaj konfirmu, ke la gastiganto revenis al ordinara konektebleco. Tiu rondvojaĝo estas la testo, kiu pruvas, ke la forlasita blokado foriris kaj ne simple estis preteririta.
Fine, restarigu ajnan diagnostikan ŝanĝon, kiun vi faris survoje. Sukcesa purigado forigas unu forlasitan dependecon; ĝi ne forigas la ĝeneralan protekton de la gastiganto, kaj ĝi ne devus postlasi permanente malfortigitan fajroŝirmilon. Notu, kiu posedanto tenis la blokadon, ĉar la sekva malinstalo produktos la samajn tri kandidatojn.