Vai VPN drošības slēdzis pārdzīvo restartu? Kā to pārbaudīt

Restarts ir visbiežākā metode, ar ko cilvēki pārbauda drošības slēdzi, un tas ir tests, kas visbiežāk melo. Klienta izvēles rūtiņa ir tikai iestatījums; svarīgi ir tas, vai kaut kas uzspiež bloķēšanu starp brīdi, kad tīkla steks paceļas, un brīdi, kad tunelis patiešām ir izveidots. Operētājsistēmā Windows tas parasti ir filtrs pakalpojumā Windows Filtering Platform, Linux tas ir vienības ielādēts noteikumu kopums, macOS tā ir pf enkura vieta, Android tās ir pašas sistēmas visur-ieslēgts un bloķēšanas karodziņi. Šie risinājumi restartā uzvedas ļoti atšķirīgi, un tikai platformas līmeņa risinājumi ir savā vietā pirms kāds var pieteikties.

Restarts uzliek trīs atsevišķus jautājumus

Sadaliet jautājumu. Pirmkārt, vai politika diskā pastāv tādā formā, ko kaut kas nolasa starta laikā? Otrkārt, vai šis lasītājs darbojas pirms jebkurš trafiks var iziet? Treškārt, vai politika aptver trafiku, kas jums svarīgs, proti, katru procesu, abas adrešu saimes un DNS. Jā uz pirmo un nē uz otro rada tieši to bojājumu, ko cilvēki apraksta kā drošības slēdzi, kas nepārdzīvo restartu: starta laikā trafiks uz dažām sekundēm izplūst, un neviens to nepamana, līdz kāds aiziet pārbaudīt.

Turiet slāņus atsevišķi. Saglabāts ugunsmūra noteikumu kopums, pakalpojums, kas sākas starta laikā, un klienta iestatījums ir trīs dažādi objekti ar trim dažādiem mūžiem. Iestatījums pārdzīvo restartus, jo tas ir vērtība konfigurācijas failā. Noteikumi ir vienīgais, kas bloķē paketes, un tie pazūd kopā ar kodolu, kas tos turēja.

Atrodiet objektu, kas atjauno bloķēšanu

Linux netfilter noteikumi dzīvo kodolā. Nekas tos starta laikā nepārraksta, ja vien jūs to neesat iekārtojis: iptables-save plus netfilter-persistent, nftables.service ielādē /etc/nftables.conf, vai systemd vienība, kas palaiž jūsu paša skriptu. Pārbaudiet, kas ir iespējots, nevis to, ko atceraties esam konfigurējis.

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

Tukšs noteikumu kopums dažas sekundes pēc starta ir atbilde uz virsrakstā uzdoto jautājumu. Operētājsistēmā Windows pajautājiet klienta pakalpojumam, kā tas sākas, un pēc tam izdrukājiet platformas filtra stāvokli, kamēr tunelis ir lejā.

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

Otrā komanda ieraksta wfpstate.xml pašreizējā mapē. Meklējiet filtrus ar bloķēšanas darbību, kas jau pastāv pirms klients pievienojas. Base Filtering Engine sākas agri starta laikā un atjauno filtrus, kas pievienoti ar pastāvīgo karodziņu, tāpēc daži drošības slēdži bloķē trafiku pirms jebkāda klienta loga pastāvēšanas, bet citi nē. Operētājsistēmā macOS sudo pfctl -s info ziņo, vai pf ir iespējots, sudo pfctl -s rules parāda, kas ir ielādēts, un VPN klienti parasti pievieno savus noteikumus enkuram, nevis galvenajam kopumam. Noteikums, kas nosauc utun3, pēc nākamā starta var norādīt uz citu saskarni, jo šis numurs tiek piešķirts izpildes laikā.

Vērojiet starpību starp tīkla pacelšanos un tuneļa pacelšanos

Bīstamais intervāls nav viss restarts, bet gan starpība. Saskarne vienā brīdī saņem nomu un noklusējuma maršrutu, VPN pakalpojums sākas citā, un tunelis autentificējas vēl vēlāk, dažreiz tikai pēc tam, kad lietotājs ir pieteicies un ir palaists akreditācijas datu aģents. Ja bloķēšana tiek piemērota pēdējā, viss starpībā iziet atklāti.

systemd resursdatoros lasiet secību, nevis miniet to. Izpildiet systemctl cat VPN un ugunsmūra vienībās un meklējiet After= vai Before= attiecībā uz network-pre.target un network-online.target. Ugunsmūra vienība, kas sakārtota pēc network-online.target, zaudē saskarnei; tā, kuru pieprasa un kura sakārtota pirms network-pre.target, uzvar. Operētājsistēmā Windows līdzvērtīgie jautājumi ir pakalpojuma starta veids un tā atkarības, jo pakalpojums, kas iestatīts uz Manual, nevar bloķēt starta procesu. Ja jūsu prasība ietver trafiku pirms pieteikšanās, to apmierina tikai ierīces līmeņa risinājums: Always On VPN ierīces tunelis autentificējas ar mašīnas sertifikātu un pievienojas pirms lietotājs pieteicas, un Microsoft dokumentē ierīces tuneļa konfigurāciju atsevišķi no lietotāja tuneļa. Android izvēlas citu ceļu, uzspiež visur-ieslēgtu VPN un bloķē savienojumus bez tā no sistēmas, nevis no lietotnes procesa.

Izpildiet testu, pēc tam salīdziniet divas laika līnijas

Restartējiet ar galamērķi, kas neko nemaksā, ja tas noplūst, un fiksējiet stāvokli starpības laikā, nevis pēc tās. Vistīrākā metode ir starta laika zonde: oneshot vienība vai plānots uzdevums, kas sākas pēc iespējas agrāk, ko platforma atļauj, ieraksta noklusējuma maršrutu un ugunsmūra stāvokli, mēģina vienu pieprasījumu ar īsu taimautu un pievieno rindu vietējam failam. Salīdziniet šo ierakstu ar VPN pakalpojuma sākuma laiku no journalctl -b -u vai sistēmas žurnāla.

Pēc tam izpildiet parasto testu: tunelis augšā, pārtrauciet savienojumu, vērojiet, vai tiešais trafiks tiek bloķēts, atjaunojiet. Iziet otro un neizdot pirmo ir normāls rezultāts, un tas nozīmē, ka izpilde ir klienta pusē, tiek piemērota, kad klients pievienojas, nevis starta laikā. Pēdējā mašīnā, ko es auditēju, bloķēšana nāca no NetworkManager izsūtītāja skripta: klātesošs un pareizs un bezjēdzīgs tām sekundēm, pirms saskarne pacēlās. Pierakstiet abus rezultātus, jo restarta pārdzīvošana kaut ko nozīmē tikai tad, kad pasakāt, kurš slānis pārdzīvoja un no kura brīža.

Aizveriet starpību, nesalaužot ceļu atpakaļ

Ja starta laikā bloķēšanas nav, pārvietojiet izpildi vienu slāni zemāk, nevis pievienojiet otru klienta noteikumu. Saglabājiet noteikumu kopumu un ielādējiet to no vienības, kas sakārtota pirms tīkls kļūst lietojams, un pārliecinieties, ka šai vienībai nav vajadzīgs DNS vaicājums vai tīkla montāža, ko tai būtu jāaizsargā. Tvērums ir tikpat svarīgs kā laiks: noteikumi, kas atbilst lietotāja ID vai cgroup, atstāj katru sistēmas dēmonu ārpus bloķēšanas, un kopums, kas apstrādā tikai IPv4, atstāj IPv6 un DNS pieejamus.

Atstājiet sev ceļu atpakaļ. Mašīnai, kas starta laikā bloķē visu un pēc tam nevar autentificēties, vispār nav tīkla, un labojums nav dzēst bloķēšanu, bet gan salabot akreditācijas datus vai secību. Uzturiet dokumentētu vietējās konsoles procedūru un šauru, apzinātu izņēmumu tam, kas tunelim patiešām vajadzīgs, piemēram, servera adresi un atrisinātāju, kas tiek izmantots pirms tuneļa pastāvēšanas.

Pirms uzticaties šim risinājumam, secīgi apstipriniet četras lietas. Politika tiek glabāta tur, kur to nolasa starts. Šis lasītājs darbojas pirms saskarne kļūst lietojama. Bloķēšana aptver abas adrešu saimes un DNS. VPN joprojām var autentificēties, kamēr bloķēšana ir aktīva. Kad visi četri ir izpildīti, restarts neko nemaina.