Tunneli on poissa, verkkokuvake näyttää normaalilta eikä mikään lataudu. Katkaisit VPN-yhteyden, asensit sen pois tai käynnistit uudelleen, ja katkoksen aikana sinua suojannut esto seisoo yhä. Asiakasikkuna ei voi selittää sitä, koska asiakas ei ole se, mikä sinut estää: päätös kirjoitettiin ytimeen sinun nimissäsi, eikä mitään jätetty jäljelle sen poistamiseksi. Windowsissa tila on Windows Filtering Platformissa; Linuxissa se on sääntöjoukko iptablesissa tai nftablesissa, usein tilannevedoksella, joka toistetaan käynnistyksessä. Seuraava on järjestys, jota käytän: lue tila, poista kapein objekti, joka selittää vian, ja etsi sitten kaikki, mikä laittaa sen jatkuvasti takaisin.

Turvakytkin on ytimen tila, ei asetus

Työpöytäasiakkaat toteuttavat estämisen lisäämällä suodattimia, jotka hylkäävät liikenteen tunnelin ulkopuolella. Windowsissa ne ovat WFP-suodattimia yhteyden uudelleenohjauksen ja kuljetuksen kerroksissa, ja jotkut niistä ovat pysyviä: ne tallennetaan Base Filtering Enginen käytäntösäilöön ja palautetaan koneen käynnistyessä, ennen kuin mikään VPN-ohjelmisto käynnistyy. Asiakkaat eroavat siinä, milloin ne siivoavat. Jotkut poistavat suodattimet katkaisun yhteydessä, toiset vain puhtaassa lopetuksessa ja toiset vain, kun turvakytkin kytketään ensin pois. Asenna pois, kun esto on aktiivinen, tai tapa prosessi, ja suodattimet jäävät.

Linuxin vastine on pudotus- tai hylkäyssääntö lähtöpolulla, joskus edelleenohjaussääntö, joskus muutettu ketjun käytäntö. Ne säännöt elävät pidempään kuin prosessi, joka ne lisäsi, koska ne ovat ytimen tilaa: tapa asiakas, kaada se tai katkaise virta, ja ydin pudottaa edelleen paketteja ilman, että mitään jää jäljelle sen peruuttamiseksi. Pysyvyyspaketti lisää toisen pysyvyyden kerroksen ottamalla tilannevedoksen nykyisestä sääntöjoukosta ja palauttamalla sen käynnistyksessä, joten seuraava käynnistys alkaa jo asennetulla estolla.

Lue WFP-tila ennen kuin poistat mitään

Windows tuo tarvittavat työkalut. Suorita korotettu komentokehote ja vedosta alustan tila; vedos tallentuu työhakemistoon tiedostona wfpstate.xml.

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

Etsi XML:stä lähteneen toimittajan nimi, Block-toiminto ja kerros. Yhteyden uudelleenohjauksen ja kuljetuksen suodattimet ovat niitä, jotka rikkovat tavallisen liikenteen; vastaanottohyväksynnän kerroksen suodatin ei yleensä ole syysi. Jos Base Filtering Engine ei käynnisty lainkaan, katso muualta, koska mikään muu ei voi toteuttaa noita suodattimia.

Tarkista myös palomuurin tavallinen näkymä, koska useimmat tutkivat vain toisen kahdesta:

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

Kun sisäänrakennetut profiilit ovat päällä eikä mikään sääntö vastaa epäonnistuvaa liikennettä, esto tulee kolmannen osapuolen toimittajalta eikä Windowsin palomuurilta. Tämä ero ratkaisee, mitä työkalua käytät korjauksessa.

Lue Linuxin säännöt siinä syntaksissa, jolla poistat

iptables -S tulostaa säännöt samassa muodossa, jota niiden lisäämiseen käytetään, mikä tekee tulosteesta suoraan uudelleenkäytettävän poistoon. iptables -L -v -n lisää pakettilaskurit, ja ne laskurit kertovat, vastaako sääntö todella epäonnistuneita pyyntöjäsi vai istuuko se vain ketjussa.

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

Lue ketjujen käytännöt, älä vain sääntöjä: -P OUTPUT DROP estää liikennettä, vaikka mikään sääntö ei vastaisi. Tutki IPv6 erikseen, koska sekä molemmat perheet asentava asiakas voi jättää IPv6-eston paikoilleen, kun IPv4-säännöt ovat poissa, ja oire riippuu silloin siitä, kumpaa perhettä sovellus suosii. Missä nftablesia käytetään, suorita myös nft list ruleset; kaksi työkalua elävät rinnakkain yhteensopivuuskerroksen kautta, eikä yksi listaus välttämättä näytä jokaista sääntöä, joka voi pudottaa paketin.

Poista kapein objekti, joka selittää vian

Windowsissa ensimmäinen askel on yhä toimittajan oma poistopolku: aja asennusohjelma uudelleen ja käytä korjausta tai poistoa, tai aja puhdistustyökalu, jos toimittaja julkaisee sellaisen. Jäljelle jääneet palvelut ja ajoitetut tehtävät ovat tavallisia, ja tehtävä, joka käynnistää asiakkaan kirjautuessa, asentaa sen suodattimet uudelleen seuraavassa käynnistyksessä. Poisto, joka epäonnistuu asiakkaan rekisteriavainta lukiessa, tarkoittaa yleensä, että palvelu tai tehtävä pitää sitä yhä, ei sitä, että rekisteri olisi vioittunut.

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

Pysyvät suodattimet ovat viimeinen keino. Ne sijaitsevat HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter-avaimen alla, yksi arvo kutakin suodatinta kohden GUID-avaimella. Vie avain ensin, kirjaa poistettavat GUIDit, poista vain lähteneelle asiakkaalle kuuluvat arvot ja käynnistä sitten uudelleen, jotta moottori rakentaa tilansa uudelleen. Älä poista koko avainta äläkä poista Base Filtering Engineä käytöstä: Windowsin palomuuri ja Defender riippuvat siitä, ja vaihtaisit yhden katkoksen pahempaan.

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

Linuxissa ota rivi, jonka iptables -S tulostaa, ja korvaa -A arvolla -D. Tunnistamasi yhden säännön poistaminen on parempi kuin ketjun tyhjentäminen, koska se jättää oman käytäntösi koskemattomaksi.

sudo iptables -D OUTPUT -p udp -j REJECT

Jos pudotus on käyttäjän määrittämässä ketjussa, poista ensin hyppy siihen ketjuun ja poista ketju sitten -X-komennolla. Ketjun käytännön asettaminen ACCEPTiksi, kun pudotussäännöt ovat yhä paikallaan, auttaa vain paketteja, jotka ylipäätään saavuttavat käytäntöpäätöksen. Kaikkien taulujen tyhjentäminen on viimeinen keino: se poistaa myös sääntöjä, jotka lisäsit muista syistä, ja ufw:n ollessa päällä se jättää palvelun uskomaan omistavansa ketjuja, joita ei enää ole.

Etsi omistaja, joka laittaa sen takaisin

Välittömän korjauksen jälkeen etsi kaikkea, mikä palauttaisi tilan. Linuxissa tarkista, onko pysyvyysyksikkö käytössä, onko asiakkaalla asetus palomuurin palauttamisesta kirjautuessa ja onko /etc-hakemiston alla tallennettua sääntötiedostoa. Windowsissa tarkista uudelleen käynnistyskohdat, palvelut ja ajoitetut tehtävät, käynnistä sitten uudelleen ja lue tila samoilla komennoilla kuin ennen.

Jos esto palaa, poistaminen ei ollut ratkaisu; omistaja oli. Kirjaa, mikä asiakas tai palvelu sen asentaa, ja poista ominaisuus käytöstä siellä sen sijaan, että taistelisit sitä vastaan palomuurikerroksessa jokaisen katkaisun jälkeen.

Varmista oikealla liikenteellä, älä yhdellä pingillä

Testaa nimihaku, TCP-yhteys ja tuore selainistunto, käynnistä sitten uudelleen ja toista samat kolme tarkistusta. Ping, joka toimii HTTPS:n epäonnistuessa, viittaa kuljetuskerroksen suodattimeen eikä verkkoon, ja esto, joka palaa vasta uudelleenkäynnistyksen jälkeen, viittaa omistajaan, jota et ole vielä löytänyt.

Säilytä todisteet: viety BFE-avain tai ennen muutosta tallennettu iptables -S-tuloste. Ennen kuin kutsut sitä korjatuksi, varmista kerros, josta poistit objektin, omistaja, joka voisi asentaa sen uudelleen, tila yhden puhtaan uudelleenkäynnistyksen jälkeen ja että tavallinen selailu toimii ilman käynnissä olevaa VPN-prosessia. Käsikirjan sivu iptables(8) sisältää tarkan poisto- ja käytäntösyntaksin, jos skriptaat puhdistuksen.

Aiheeseen liittyvät artikkelit