Kestääkö VPN:n hätäkatkaisin uudelleenkäynnistyksen? Näin tarkistat sen

Uudelleenkäynnistys on yleisin tapa, jolla ihmiset testaavat hätäkatkaisinta, ja se on testi, joka valehtelee useimmin. Asiakasohjelman valintaruutu on asetus; ratkaisevaa on, pakottaako jokin eston sen hetken välillä, jolloin verkkopinon nousee, ja sen hetken välillä, jolloin tunneli on todella muodostettu. Windowsissa tämä jokin on yleensä suodatin Windows Filtering Platformissa, Linuxissa yksikön lataama sääntöjoukko, macOS:ssä pf-ankkuri, Androidissa järjestelmän omat aina-päällä- ja lukitusliput. Nämä järjestelyt käyttäytyvät hyvin eri tavoin uudelleenkäynnistyksen aikana, ja vain järjestelmätason järjestelyt ovat paikallaan ennen kuin kukaan voi kirjautua sisään.

Uudelleenkäynnistys esittää kolme erillistä kysymystä

Jaa kysymys. Ensinnäkin, onko käytäntö levyllä muodossa, jota jokin lukee käynnistyksen yhteydessä? Toiseksi, käynnistyykö tämä lukija ennen kuin mikään liikenne voi lähteä? Kolmanneksi, kattaako käytäntö liikenteen, josta välität, eli jokaisen prosessin, molemmat osoiteperheet ja DNS:n. Kyllä ensimmäiseen ja ei toiseen tuottaa täsmälleen sen vian, jonka ihmiset raportoivat hätäkatkaisimena, joka ei kestä uudelleenkäynnistystä: liikenne karkaa käynnistyksen alussa muutamaksi sekunniksi, eikä kukaan huomaa sitä ennen kuin joku menee katsomaan.

Pidä kerrokset erillään. Tallennettu palomuurisääntöjoukko, käynnistyksen yhteydessä käynnistyvä palvelu ja asiakasohjelman asetus ovat kolme eri objektia, joilla on kolme eri elinikää. Asetus kestää uudelleenkäynnistykset, koska se on arvo asetustiedostossa. Säännöt ovat ainoa asia, joka estää paketteja, ja ne katoavat sen ytimen mukana, joka niitä piti.

Etsi objekti, joka palauttaa eston

Linuxissa netfilter-säännöt elävät ytimessä. Mikään ei kirjoita niitä takaisin käynnistyksen yhteydessä, ellet ole järjestänyt sitä: iptables-save plus netfilter-persistent, nftables.service lataa /etc/nftables.conf, tai systemd-yksikkö, joka ajaa oman skriptisi. Tarkista, mikä on käytössä, sen sijaan mitä muistat määrittäneesi.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

Tyhjä sääntöjoukko muutama sekunti käynnistyksen jälkeen on vastaus otsikon kysymykseen. Windowsissa kysy asiakaspalvelulta, miten se käynnistyy, ja vedä sitten järjestelmätason suodattimen tila ulos, kun tunneli on alhaalla.

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

Toinen komento kirjoittaa wfpstate.xml nykyiseen hakemistoon. Etsi estotoiminnolla varustettuja suodattimia, jotka ovat jo olemassa ennen kuin asiakasohjelma yhdistää. Base Filtering Engine käynnistyy aikaisin ja palauttaa pysyvällä lipulla lisätyt suodattimet, minkä vuoksi jotkin hätäkatkaisimet estävät liikennettä ennen kuin mitään asiakasikkunaa on olemassa ja toiset eivät. macOS:ssä sudo pfctl -s info kertoo, onko pf käytössä, sudo pfctl -s rules näyttää, mitä on ladattu, ja VPN-asiakasohjelmat liittävät sääntönsä yleensä ankkuriin eivätkä pääsääntöjoukkoon. Sääntö, joka nimeää utun3 voi seuraavan käynnistyksen jälkeen osoittaa toiseen liitäntään, koska se numero annetaan ajon aikana.

Tarkkaile verkon nousun ja tunnelin nousun välistä aukkoa

Vaarallinen väli ei ole koko uudelleenkäynnistys, vaan aukko. Liitäntä saa vuokran ja oletusreitin yhdessä hetkessä, VPN-palvelu käynnistyy toisessa, ja tunneli todentaa vielä myöhemmin, joskus vasta sen jälkeen, kun käyttäjä on kirjautunut sisään ja tunnistetietoagentti on ajanut. Jos esto sovelletaan viimeisenä, kaikki aukossa oleva lähtee salaamattomana.

systemd-isännissä lue järjestys sen sijaan että arvaisit sen. Suorita systemctl cat VPN- ja palomuuriyksiköille ja etsi After= tai Before= suhteessa network-pre.target ja network-online.target. Palomuuriyksikkö, joka on järjestetty network-online.target jälkeen, häviää liitännälle; se, jota network-pre.target vaatii ja joka on järjestetty ennen sitä, voittaa. Windowsissa vastaavat kysymykset ovat palvelun käynnistystyyppi ja sen riippuvuudet, koska Manualiksi asetettu palvelu ei voi estää käynnistyksen aikaista prosessia. Jos vaatimuksesi sisältää liikennettä ennen kirjautumista, vain laitostason järjestely täyttää sen: Always On VPN -laitetunneli todentaa konenevarmenteella ja yhdistää ennen kuin käyttäjä kirjautuu sisään, ja Microsoft dokumentoi laitetunnelin kokoonpanon erillään käyttäjätunnelista. Android valitsee toisen tien, pakottaa aina-päällä-VPN:n ja estää yhteydet ilman sitä järjestelmästä eikä sovellusprosessista.

Suorita testi ja vertaa sitten kahta aikajanaa

Käynnistä uudelleen kohteeseen, joka ei maksa mitään, jos se vuotaa, ja tallenna tila aukon aikana eikä sen jälkeen. Puhtain menetelmä on käynnistysanturi: oneshot-yksikkö tai ajastettu tehtävä, joka käynnistyy niin aikaisin kuin alusta sallii, tallentaa oletusreitin ja palomuurin tilan, yrittää yhtä pyyntöä lyhyellä aikakatkaisulla ja lisää rivin paikalliseen tiedostoon. Vertaa tätä tietuetta VPN-palvelun alkamisaikaan, joka on peräisin journalctl -b -u tai järjestelmälokista.

Suorita sitten tavallinen testi: tunneli ylhäällä, katkaise yhteys, katso estetäänkö suora liikenne, palauta. Toisen läpäiseminen ja ensimmäisen epäonnistuminen on normaali tulos, ja se tarkoittaa, että täytäntöönpano on asiakaspuolella, sovelletaan kun asiakasohjelma yhdistää eikä käynnistyksen yhteydessä. Viimeisellä auditoimallani koneella esto tuli NetworkManagerin lähettäjäskriptistä: läsnä ja oikein ja hyödytön niille sekunneille ennen kuin liitäntä nousi. Kirjoita molemmat tulokset muistiin, koska uudelleenkäynnistyksen kestäminen tarkoittaa jotain vasta kun sanot, mikä kerros kesti ja mistä hetkestä lähtien.

Sulje aukko katkaisematta paluutietäsi

Jos esto puuttuu käynnistyksen yhteydessä, siirrä täytäntöönpanoa kerrosta alaspäin sen sijaan että lisäisit toisen asiakassäännön. Tallenna sääntöjoukko ja lataa se yksiköstä, joka on järjestetty ennen kuin verkko on käyttökelpoinen, ja varmista, ettei tämä yksikkö tarvitse DNS-kyselyä tai verkkomounttia, jota sen pitäisi suojata. Laajuus on yhtä tärkeä kuin ajoitus: käyttäjätunnukseen tai cgroupiin osuvat säännöt jättävät jokaisen järjestelmäpalvelun eston ulkopuolelle, ja sääntöjoukko, joka käsittelee vain IPv4:n, jättää IPv6:n ja DNS:n tavoitettaviksi.

Jätä itsellesi paluutie. Koneella, joka estää käynnistyksessä kaiken eikä sitten pysty todentamaan, ei ole verkkoa ollenkaan, eikä korjaus ole eston poistaminen vaan tunnistetiedon tai järjestyksen korjaaminen. Pidä dokumentoitu paikallisen konsolin menettely ja kapea, tarkoituksellinen poikkeus sille, mitä tunneli todella tarvitsee, kuten palvelimen osoite ja ennen tunnelia käytetty nimipalvelin.

Ennen kuin luotat järjestelyyn, vahvista neljä asiaa järjestyksessä. Käytäntö on tallennettu jonnekin, josta käynnistys lukee. Tämä lukija käynnistyy ennen kuin liitäntä on käyttökelpoinen. Esto kattaa molemmat osoiteperheet ja DNS:n. VPN voi yhä todentaa, kun esto on aktiivinen. Kun kaikki neljä pitävät, uudelleenkäynnistys ei muuta mitään.