Miksi VPN-tilaan sidottu palomuuriportti ei ole sääntö pingata vain tunnelin kautta

Kuvittele palomuurisääntö, joka kytkee ICMP-echon päälle palvelimen julkiselle osoitteelle aina, kun nimetty VPN-profiili on yhdistettynä. Se luetaan kuten „ping vain tunnelin kautta”, ja tämä luenta on väärä tavalla, jolla on merkitystä. Sääntö ei rajoita, kuka voi tavoittaa isäntään; se muuttaa sitä, mihin julkinen liitäntä vastaa, kun jokin toinen yhteys sattuu olemaan päällä. Nämä ovat kaksi eri käytäntöä, ja toinen niistä laajentaa altistusta hiljaa.

Sääntö, jonka luulet kirjoittaneesi

Tarkoitettu vaatimus on yleensä kapea: valvontajärjestelmän tai VPN:n ainoan ylläpitäjän pitäisi voida vahvistaa, että palvelin on elossa. Lauseeksi kirjoitettuna se kuulostaa tunnelin pääsynvalvonnalta. Palomuurioliona kirjoitettuna siitä tulee julkisen profiilin ehto, koska sinne echo-pyyntö saapuu.

Kun ehtona on yhteystila eikä lähdeosoite, sallittujen lähettäjien joukko ei ole enää VPN-vertaisten joukko. Kuka tahansa, joka tavoittaa julkisen osoitteen, voi lähettää echo-pyynnön portin ollessa auki. Tunneli ei muuttunut poluksi; tunnelista tuli kytkin.

Ideaa markkinoivat eivät yleensä valehtele halutusta vaikutuksesta. He tarvitsivat tarkistuksen, joka vastaa vain kun linkki on kunnossa, ja linkin kuntoa oli helpointa tarkkailla VPN:n kautta. Virhe on kohdella saatavuussignaalia pääsypäätöksenä ja automatisoida se sitten.

Mittä portti oikeasti ohjaa

Tämä suunnittelu sulauttaa kaksi riippumatonta asiaa, ja niiden erottaminen on suurin osa korjausta. Ensimmäinen on laajuus: mikä paikallinen osoite, mitkä etäosoitteet, mikä protokolla ja mikä ICMP-tyyppi. Toinen on ehto: onko sääntöolio tällä hetkellä käytössä. Laajuus on se, mitä palomuuri arvioi pakettia kohden; ehto on se, mitä skripti kirjoittaa käytäntösäilöön, ja ne sovitetaan täysin eri kelloilla.

Jos vaatimus on todella vain VPN-vertaiset, laajuus vastaa siihen ilman mitään yhteystilan logiikkaa: sido sääntö tunnelin liitäntään tai tunnelin osoitealueeseen, rajaa etäosoitteet asiakasjoukkoon ja määritä echo-tyyppi „ICMP”:n sijaan. Tämä sääntö pysyy oikeana, kun VPN ei ole päällä, eikä asiaankuulumaton profiili voi avata sitä.

Jos vaatimus on todella julkinen portti, sano se käytännön tekstissä, koska hyväksymiskriteerit muuttuvat. Julkisen portin on nimettävä täsmällinen profiili, määriteltävä, mitä „yhdistetty” tarkoittaa, ja todettava, että julkiset lähettäjät ovat suunnitellusti laajuudessa. Suurin osa sekaannuksesta katoaa hetkellä, jolloin jonkun on pakko kirjoittaa tuo lause.

Rakenna olio kerran ja kytke sitä sitten

Valmistele yksi sääntö, jolla on vakaa identiteetti, pois käytöstä, ja anna ohjaimen muuttaa vain sen käyttötilaa. Sääntöjen luominen näyttönimen mukaan joka ajolla on se tapa, jolla käytäntösäilöön jää viisi lähes identtistä oliota eikä luotettavaa tapaa poistaa niitä.

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 pysyvä tunniste; näyttönimi on dokumentaatio, jota ihminen voi muokata. Sovita -Name-kohtaan, niin skripti lakkaa tuottamasta kaksoiskappaleita. Sama komennon muoto kattaa IPv6-tapauksen -Protocol ICMPv6 -IcmpType 128-kohdalla, mutta se on erillinen sääntö, koska echo-tyypin numerot eroavat kahden perheen välillä.

Pidä osoiteperhe ja ICMP-tyyppi selvinä toisestakin syystä: -Protocol ICMPv4 ilman tyyppiä sallii jokaisen ICMPv4-viestin, jonka profiili sallii, mukaan lukien ne, joita et koskaan aikonut hyväksyä. Tyypin 8 nimeäminen kaventaa säännön echo-pyyntöön, ja se on ainoa, mitä tavoitettavuustarkistus lähettää.

Missä automaatio on ristiriidassa aikomuksen kanssa

Asiakasprofiilin kysely parin minuutin välein ei voi tuottaa välitöntä rajaa. Yhteyden katkeamisen ja seuraavan kyselyn välillä sääntö vastaa edelleen julkisessa osoitteessa; yhteyden nousemisen ja seuraavan kyselyn välillä se ei vastaa. Tämän viiveen myöntäminen on rehellistä, väittäminen että suunnittelu pakottaa tiukan invariantin, ei ole.

Tilatarkistuksessa itsessään on laajuusansa. Get-VpnConnection raportoi koneelle määritetyt asiakasprofiilit, oletuksena nykyiselle käyttäjälle ja kaikille käyttäjille -AllUserConnection-valitsimella. Se ei raportoi etäkäyttäjiä, jotka ovat parhaillaan kirjautuneet RRAS-palvelimeen; se on toinen havainto toisella komennolla. Väärän päälle rakennettu portti ei ole yhteydessä mihinkään.

Kata sitten tilat, joita kukaan ei skriptaa: käynnistys, jossa sääntö on jo päällä edelliseltä ajalta, ohjaimen kaatuminen portin ollessa auki, ja profiili, joka poistetaan säännön jäädessä eloon. Jokainen tarvitsee määritellyn oletuksen, ja julkisen luvan turvallinen oletus on pois päältä. Jos vaatimus todella ei siedä kyselyikkunaa, tilaan sidottu sääntö on väärä väline ja valvonta kuuluu tunnelille, ei julkiselle liitännälle.

Testaa lopuksi julkinen pyyntö kahdesti, kerran valitun yhteyden ollessa päällä ja kerran sen ollessa alhaalla, isännästä, joka ei ole VPN:ssä. Onnistunut ping tunnelin sisältä ei todista tästä käytännöstä mitään, ja juuri sen mittauksen useimmat käyttöönotot jättävät väliin.