Miks VPN-i olekule reageeriv tulemüürivärav ei ole reegel, mis lubab pingi ainult tunnelist

Kujutage ette tulemüürireeglit, mis lülitab serveri avaliku aadressi jaoks ICMP echo sisse iga kord, kui nimetatud VPN-profiil on ühendatud. See loeb nagu „ping ainult tunnelist”, ja see lugemine on vale viisil, mis loeb. Reegel ei piira, kes pääseb hostile; see muudab, millele avalik liides vastab, kui mõni teine ühendus juhtub olema üleval. Need on kaks erinevat poliitikat ja üks neist laiendab kokkupuudet vaikselt.

Reegel, mille te arvate kirjutanud olevat

Kavatsetud nõue on tavaliselt kitsas: jälgimissüsteem või ainus administraator VPN-is peaks saama kinnitada, et server on elus. Lausena kirjutatuna kõlab see tunnelile juurdepääsu kontrollina. Tulemüüriobjektina kirjutatuna muutub see avaliku profiili tingimuseks, sest sinna echo-päring saabub.

Kui tingimuseks saab ühenduse olek, mitte lähteaadress, ei ole lubatud saatjate hulk enam VPN-i partnerite hulk. Igaüks, kes pääseb avalikule aadressile, võib saata echo-päringu, kui värav on avatud. Tunnelist ei saanud teed; tunnelist sai lüliti.

Selle idee propageerijad tavaliselt ei valeta soovitud mõju kohta. Neil oli vaja kontrolli, mis vastab ainult siis, kui ühendus on terve, ja ühenduse tervist oli kõige lihtsam jälgida VPN-i kaudu. Viga on käsitleda kättesaadavuse signaali juurdepääsuotsusena ja seejärel seda automatiseerida.

Mida värav tegelikult kontrollib

See disain ühendab kaks sõltumatut asja ja nende eraldamine on paranduse suurem osa. Esimene on ulatus: milline kohalik aadress, millised kaugadressid, milline protokoll ja milline ICMP-tüüp. Teine on tingimus: kas reegliobjekt on praegu lubatud. Ulatus on see, mida tulemüür hindab iga paketi kohta; tingimus on see, mida skript poliitikahoidlasse kirjutab, ja neid kahte sobitatakse täiesti erinevatel kelladel.

Kui nõue on tõesti ainult VPN-i partnerid, vastab ulatus sellele ilma igasuguse ühenduseoleku loogikata: siduge reegel tunneli liidese või tunneli aadressivahemikuga, piirake kaugadressid kliendikogumiga ja määrake echo-tüüp, mitte „ICMP”. See reegel jääb õigeks, kui ükski VPN ei ole üleval, ja kõrvaline profiil ei saa seda avada.

Kui nõue on tõesti avalik värav, öelge seda poliitika tekstis, sest vastuvõtukriteeriumid muutuvad. Avalik värav peab nimetama täpse profiili, määratlema, mida tähendab „ühendatud”, ja kinnitama, et avalikud saatjad on disaini järgi ulatuses. Suurem osa segadusest kaob hetkel, mil keegi on sunnitud selle lause üles kirjutama.

Ehitage objekt üks kord ja siis lülitage seda

Varustage eelnevalt üks reegel stabiilse identiteediga, keelatud olekus, ja laske kontrolleril muuta ainult selle lubatud olekut. Reeglite loomine kuvatava nime järgi igal käivitusel on viis, kuidas poliitikahoidla lõpetab viie peaaegu identse objektiga ja ilma usaldusväärse viisita neid eemaldada.

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

Nimi on püsiv identifikaator; kuvatav nimi on dokumentatsioon, mida inimene võib muuta. Sobitage -Name järgi ja skript lõpetab duplikaatide tootmise. Sama käsuvorm katab IPv6 juhtumi -Protocol ICMPv6 -IcmpType 128 abil, mis on eraldi reegel, sest echo-tüübi numbrid erinevad kahe perekonna vahel.

Hoidke aadressiperekond ja ICMP-tüüp selgesõnalised ka teisel põhjusel: -Protocol ICMPv4 ilma tüübita lubab iga ICMPv4-sõnumit, mida profiil lubab, sealhulgas neid, mida te ei kavatsenud kunagi vastu võtta. Tüübi 8 nimetamine kitsendab reegli echo-päringule, mis on ainus, mida kättesaadavuskontroll saadab.

Kus automatiseerimine läheb kavatsusega vastuollu

Kliendiprofiili küsitlemine iga paari minuti järel ei saa anda kohest piiri. Ühenduse kukkumise ja järgmise küsitluse vahel vastab reegel endiselt avalikul aadressil; ühenduse tõusmise ja järgmise küsitluse vahel ei vasta. Selle viivituse tunnistamine on aus, väita, et disain kehtestab range invariant, ei ole.

Olekukontrollis endas on ulatuse lõks. Get-VpnConnection teatab masinasse seadistatud kliendiprofiilidest, vaikimisi praeguse kasutaja jaoks ja kõigi kasutajate jaoks koos -AllUserConnection. See ei teata kaugkasutajatest, kes on praegu RRAS-serverisse sisse helistanud; see on teine vaatlus teise käsuga. Vale asja peale ehitatud värav ei ole millegagi ühendatud.

Seejärel katke olekud, mida keegi ei skripti: käivitamine reegliga, mis on juba eelmisest käivitusest lubatud, kontrolleri krahh avatud väravaga ja kustutatud profiil, mille reegel jääb elama. Igaüks vajab määratletud vaikeväärtust ja avaliku loa turvaline vaikeväärtus on keelatud. Kui nõue tõesti ei talu küsitlusakent, on olekupõhine reegel vale vahend ja jõustamine kuulub tunnelile, mitte avalikule liidesele.

Lõpuks testige avalikku päringut kaks korda, üks kord valitud ühendusega üleval ja üks kord maas, hostist, mis ei ole VPN-is. Edukas ping tunneli seest ei tõesta selle poliitika kohta midagi ja just selle mõõtmise jätavad enamik juurutusi vahele.