Oorleef ’n VPN-doodskakelaar ’n herbegin? Hoe om dit te verifieer

Herbegin is die algemeenste manier waarop mense ’n doodskakelaar toets, en dit is die toets wat die meeste lieg. Die merkkassie in die kliënt is ’n voorkeur; wat saak maak, is of iets ’n blokkade afdwing tussen die oomblik wanneer die netwerkstapel opkom en die oomblik wanneer die tonnel werklik gevestig is. Op Windows is daardie iets gewoonlik ’n filter in die Windows Filtering Platform, op Linux ’n reëlversameling wat deur ’n eenheid gelaai word, op macOS ’n pf-anker, op Android die stelsel se eie altyd-aan- en toesluitvlae. Daardie reëlings gedra hulle baie anders oor ’n herbegin, en net die platformvlakkes is in plek voordat enigiemand kan aanmeld.

Herbegin vra drie afsonderlike vrae

Verdeel die vraag. Eerstens, bestaan die beleid op skyf in ’n vorm wat iets by selflaai lees? Tweedens, hardloop daardie leser voordat enige verkeer kan uitgaan? Derdens, dek die beleid die verkeer waaroor jy sorg, dit wil sê elke proses, beide adresfamilies en DNS. ’n Ja op die eerste en ’n nee op die tweede lewer presies die fout wat mense rapporteer as ’n doodskakelaar wat nie ’n herbegin oorleef nie: verkeer ontsnap vir ’n paar sekondes tydens die opstart, en niemand merk dit tot iemand gaan soek.

Hou die lae uitmekaar. ’n Gestoor vuurmuurreëlversameling, ’n diens wat by selflaai begin en ’n kliëntvoorkeur is drie verskillende objekte met drie verskillende lewensduurte. Die voorkeur oorleef herbeginne omdat dit ’n waarde in ’n konfigurasielêer is. Die reëls is die enigste ding wat pakkette blokkeer, en hulle verdwyn saam met die kern wat hulle gehou het.

Vind die objek wat die blokkade herstel

Op Linux woon netfilter-reëls in die kern. Niks skryf hulle by selflaai terug nie, tensy jy dit gereël het: iptables-save plus netfilter-persistent, nftables.service wat /etc/nftables.conf laai, of ’n systemd-eenheid wat jou eie skrip uitvoer. Kyk wat geaktiveer is eerder as wat jy onthou jy opgestel het.

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

’n Leë reëlversameling ’n paar sekondes ná selflaai is die antwoord op die vraag in die titel. Op Windows vra jy die kliëntdiens hoe dit begin, en dump dan die platformfiltertoestand terwyl die tonnel af is.

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

Die tweede opdrag skryf wfpstate.xml na die huidige gids. Soek na filters met ’n blokkeeraksie wat reeds bestaan voordat die kliënt aansluit. Die Base Filtering Engine begin vroeg in die selflaai en herstel filters wat met die persistente vlag bygevoeg is, wat is waarom sommige doodskakelaars verkeer blokkeer voordat enige kliëntvenster bestaan en ander nie. Op macOS, sudo pfctl -s info rapporteer of pf geaktiveer is, sudo pfctl -s rules wys wat gelaai is, en VPN-kliënte heg gewoonlik hulle reëls aan ’n anker eerder as die hoofreëlversameling. ’n Reël wat utun3 noem, kan na die volgende selflaai na ’n ander koppelvlak wys, want daardie nommer word by looptyd toegeken.

Let op die gaping tussen netwerk-op en tonnel-op

Die gevaarlike interval is nie die hele herbegin nie, dit is die gaping. Die koppelvlak ontvang ’n huurkontrak en ’n verstekroete op een punt, die VPN-diens begin op ’n ander, en die tonnel verifieer later nog, soms eers nadat ’n gebruiker aangemeld het en ’n geloofsbriewe-agent hardloop. As die blokkade laaste toegepas word, verlaat alles in die gaping onbeskermd.

Op systemd-gashere, lees die ordening eerder as om dit te raai. Voer systemctl cat op die VPN- en vuurmuureenhede uit en kyk vir After= of Before= teenoor network-pre.target en network-online.target. ’n Vuurmuureenheid wat ná network-online.target georden is, verloor teen die koppelvlak; een wat deur network-pre.target versoek en voor dieselfde teiken georden word, wen. Op Windows is die ekwivalente vrae die diens se begintipe en sy afhanklikhede, want ’n diens wat op Manual gestel is, kan nie ’n selflaaiproses blokkeer nie. As jou vereiste verkeer voor aanmelding insluit, is net ’n toestelvlak-reëling voldoende: ’n Always On VPN-toesteltonnel verifieer met ’n masjien-sertifikaat en verbind voordat die gebruiker aanmeld, en Microsoft dokumenteer die toesteltonnel-konfigurasie apart van die gebruikerstonnel. Android volg die ander roete en dwing altyd-aan-VPN af en blokkeer verbindings daarsonder vanuit die stelsel eerder as vanuit ’n toepassingsproses.

Voer die toets uit en vergelyk dan twee tydlyne

Herbegin met ’n bestemming wat niks kos as dit lek nie, en vang toestand gedurende die gaping vas eerder as daarna. Die skoonste metode is ’n selflaai-ondersoek: ’n oneshot-eenheid of ’n geskeduleerde taak wat so vroeg as die platform toelaat begin, die verstekroete en die vuurmuurtoestand aanteken, een versoek met ’n kort tydslimiet probeer en ’n reël by ’n plaaslike lêer voeg. Vergelyk daardie rekord met die VPN-diens se begintyd uit journalctl -b -u of die Stelsellog.

Voer dan die gewone toets uit: tonnel op, verbreek die verbinding, kyk of direkte verkeer geblokkeer word, herstel. Om die tweede te slaag en die eerste te faal is die normale uitslag, en dit beteken die afdwinging is aan die kliëntkant, toegepas wanneer die kliënt verbind eerder as by selflaai. Op die laaste masjien wat ek geoudit het, het die blokkade van ’n NetworkManager-verspreiderskrip gekom: teenwoordig en korrek en nutteloos vir die sekondes voordat die koppelvlak opgekom het. Skryf beide uitslae neer, want om ’n herbegin te oorleef beteken net iets sodra jy sê watter laag oorleef het en van watter oomblik af.

Sluit die gaping sonder om jou terugpad te breek

As die blokkade by selflaai ontbreek, skuif afdwinging ’n laag af eerder as om ’n tweede kliëntreël by te voeg. Stoor die reëlversameling en laai dit uit ’n eenheid wat georden is voordat die netwerk bruikbaar is, en maak seker daardie eenheid het nie ’n DNS-soektog of ’n netwerkmonttering nodig wat dit veronderstel is om te beskerm nie. Omvang saak net soveel soos tydsberekening: reëls wat op ’n gebruikers-ID of ’n cgroup pas, laat elke stelseldeem buiten die blokkade, en ’n reëlversameling wat net IPv4 hanteer, laat IPv6 en DNS bereikbaar.

Los vir jouself ’n weg terug. ’n Masjien wat alles by selflaai blokkeer en dan nie kan verifieer nie, het glad geen netwerk nie, en die regstelling is nie om die blokkade te skrap nie, maar om die geloofsbriewe of die ordening te herstel. Hou ’n gedokumenteerde plaaslike konsole-prosedure en ’n smal, doelbewuste uitsondering vir wat die tonnel werklik nodig het, soos die bedieneradres en die oplosser wat gebruik word voordat die tonnel bestaan.

Voordat jy die opstelling vertrou, bevestig vier dinge in volgorde. Die beleid word êrens gestoor waar selflaai lees. Daardie leser hardloop voordat die koppelvlak bruikbaar is. Die blokkade dek beide adresfamilies en DNS. Die VPN kan steeds verifieer terwyl die blokkade aktief is. Wanneer al vier geld, verander ’n herbegin niks.