Kāpēc ar VPN stāvokli saistīti ugunsmūra vārti nav noteikums ping tikai pa tuneli
Noteikums, kas atbild uz ping tikai tad, kamēr ir savienots nosaukts VPN profils, ir publiskās adreses politika, kas saistīta ar nesaistītu stāvokli, nevis atļauja tikai tunelim.
Iedomājieties ugunsmūra noteikumu, kas ieslēdz ICMP echo servera publiskajai adresei katru reizi, kad ir savienots nosaukts VPN profils. Tas lasās kā „ping tikai pa tuneli“, un šis lasījums ir nepareizs tādā veidā, kam ir nozīme. Noteikums neierobežo, kas var sasniegt resursdatoru; tas maina, uz ko atbild publiskā saskarne, kamēr kāds cits savienojums nejauši ir aktīvs. Tās ir divas dažādas politikas, un viena no tām klusi paplašina iedarbību.
Noteikums, ko, jūsuprāt, esat uzrakstījis
Paredzētā prasība parasti ir šaura: uzraudzības sistēmai vai vienīgajam VPN administratoram jāspēj apstiprināt, ka serveris ir dzīvs. Rakstot to kā teikumu, tas izklausās pēc piekļuves kontroles tunelim. Rakstot to kā ugunsmūra objektu, tas pārvēršas par nosacījumu publiskajā profilā, jo tieši tur pienāk echo pieprasījums.
Tiklīdz nosacījums ir savienojuma stāvoklis, nevis avota adrese, atļauto sūtītāju kopa vairs nav VPN partneru kopa. Ikviens, kas var sasniegt publisko adresi, var nosūtīt echo pieprasījumu, kamēr vārti ir atvērti. Tunelis nekļuva par ceļu; tunelis kļuva par slēdzi.
Cilvēki, kas popularizē šo ideju, parasti nemelo par vēlamo efektu. Viņiem vajadzēja pārbaudi, kas atbild tikai tad, kad saite ir vesela, un saites veselību bija visvieglāk novērot caur VPN. Kļūda ir uzskatīt pieejamības signālu par piekļuves lēmumu un pēc tam to automatizēt.
Ko vārti patiešām kontrolē
Šis dizains sapludina divas neatkarīgas lietas, un to atdalīšana ir lielākā daļa no labojuma. Pirmā ir tvērums: kura vietējā adrese, kuras attālās adreses, kurš protokols un kurš ICMP tips. Otrā ir nosacījums: vai noteikuma objekts šobrīd ir iespējots. Tvērumu ugunsmūris novērtē katrai paketei; nosacījumu skripts ieraksta politikas krātuvē, un abi tiek saskaņoti pilnīgi atšķirīgos pulksteņos.
Ja prasība patiešām ir tikai VPN partneri, tvērums to atbild bez jebkādas savienojuma stāvokļa loģikas: piesaistiet noteikumu tuneļa saskarnei vai tuneļa adrešu diapazonam, ierobežojiet attālās adreses ar klientu kopu un norādiet echo tipu, nevis „ICMP“. Šāds noteikums paliek pareizs, kad nav ieslēgts neviens VPN, un to nevar atvērt nesaistīts profils.
Ja prasība patiešām ir publiski vārti, sakiet to politikas tekstā, jo pieņemšanas kritēriji mainās. Publiskiem vārtiem jānosauc precīzais profils, jādefinē, ko nozīmē „savienots“, un jāpaziņo, ka publiskie sūtītāji pēc dizaina ir tvērumā. Lielākā daļa apjukuma pazūd tajā brīdī, kad kāds tiek spiests uzrakstīt šo teikumu.
Uzbūvējiet objektu vienreiz, tad pārslēdziet to
Iepriekš izveidojiet vienu noteikumu ar stabilu identitāti, atspējotu, un ļaujiet kontrollerim mainīt tikai tā iespējošanas stāvokli. Noteikumu veidošana pēc parādāmā nosaukuma katrā palaidē reizē ir ceļš, kā politikas krātuve nonāk pie pieciem gandrīz identiskiem objektiem un bez uzticama veida, kā tos noņemt.
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
Nosaukums ir noturīgais identifikators; parādāmais nosaukums ir dokumentācija, ko cilvēks drīkst rediģēt. Saskaņojiet pēc -Name, un skripts pārstās veidot dublikātus. Tā pati komandas forma aptver IPv6 gadījumu ar -Protocol ICMPv6 -IcmpType 128, taču tas ir atsevišķs noteikums, jo echo tipa numuri abās saimēs atšķiras.
Turiet adrešu saimi un ICMP tipu skaidri arī otra iemesla dēļ: -Protocol ICMPv4 bez tipa atļauj katru ICMPv4 ziņojumu, ko profils pieļauj, tostarp tos, ko nekad neesat paredzējis pieņemt. Tipa 8 nosaukšana sašaurina noteikumu līdz echo pieprasījumam, un tas ir vienīgais, ko sūta sasniedzamības pārbaude.
Kur automatizācija ir pretrunā ar nodomu
Klienta profila aptauja ik pēc dažām minūtēm nevar radīt tūlītēju robežu. Starp savienojuma pārrāvumu un nākamo aptauju noteikums joprojām atbild publiskajā adresē; starp savienojuma pacelšanu un nākamo aptauju tas neatbild. Šo aizturi atzīt ir godīgi, bet apgalvot, ka dizains uzspiež stingru invariantu, nav godīgi.
Pašā stāvokļa pārbaudē ir tvēruma slazds. Get-VpnConnection ziņo par mašīnā konfigurētajiem klienta profiliem, pēc noklusējuma pašreizējam lietotājam un visiem lietotājiem ar -AllUserConnection. Tas neziņo par attālajiem lietotājiem, kuri šobrīd ir pieslēgušies RRAS serverim; tas ir cits novērojums ar citu komandu. Vārti, kas uzbūvēti uz nepareizā, nav ar neko savienoti.
Tad aptveriet stāvokļus, kurus neviens neskripto: palaišana ar jau iespējotu noteikumu no iepriekšējās reizes, kontrollera avārija ar atvērtiem vārtiem un dzēsts profils, kamēr tā noteikums paliek aktīvs. Katram vajag definētu noklusējumu, un drošais noklusējums publiskai atļaujai ir atspējots. Ja prasība patiešām nepieļauj aptaujas logu, ar stāvokli saistīts noteikums ir nepareizais instruments, un izpilde pieder tunelim, nevis publiskajai saskarnei.
Visbeidzot, pārbaudiet publisko pieprasījumu divreiz: vienreiz ar ieslēgtu izvēlēto savienojumu un vienreiz ar to izslēgtu, no resursdatora, kas nav VPN. Veiksmīgs ping no tuneļa iekšpuses neko nepierāda par šo politiku, un tieši šo mērījumu lielākā daļa ieviešanu izlaiž.