Kial fajroŝirma pordego ligita al VPN-stato ne estas regulo por ping nur tra la tunelo

Imagu fajroŝirman regulon, kiu ŝaltas ICMP-echon por la publika adreso de la servilo ĉiam, kiam nomita VPN-profilo estas konektita. Ĝi legeblas kiel «ping nur tra la tunelo», kaj tiu legado malĝustas laŭ maniero, kiu gravas. La regulo ne limigas, kiu povas atingi la gastiganton; ĝi ŝanĝas, al kio la publika interfaco respondas, dum iu alia konekto hazarde estas aktiva. Temas pri du malsamaj politikoj, kaj unu el ili kviete plivastigas la elmeton.

La regulo, kiun vi pensas, ke vi skribis

La celata postulo kutime estas mallarĝa: la monitora sistemo, aŭ la sola administranto en la VPN, devus povi konfirmi, ke la servilo vivas. Skribite kiel frazo, ĝi sonas kiel alirkontrolo al la tunelo. Skribite kiel fajroŝirma objekto, ĝi fariĝas kondiĉo ĉe la publika profilo, ĉar ĝuste tien alvenas la echo-peto.

Post kiam la kondiĉo estas konekta stato anstataŭ fonta adreso, la aro de permesitaj sendantoj ne plu estas la aro de VPN-partneroj. Ĉiu, kiu povas atingi la publikan adreson, povas sendi echo-peton dum la pordego malfermitas. La tunelo ne fariĝis la vojo; la tunelo fariĝis la ŝaltilo.

Tiuj, kiuj propagandas ĉi tiun ideon, kutime ne mensogas pri la efiko, kiun ili volis. Ili bezonis kontrolon, kiu respondas nur kiam la ligilo sanas, kaj la sano de la ligilo estis plej facile observebla tra la VPN. La eraro estas trakti haveblecan signalon kiel alirdecidon kaj poste aŭtomatigi ĝin.

Kion la pordego efektive kontrolas

Ĉi tiu dezajno kunfandas du sendependajn aferojn, kaj ilia apartigo estas la plej granda parto de la korekto. La unua estas amplekso: kiu loka adreso, kiuj malproksimaj adresoj, kiu protokolo kaj kiu ICMP-tipo. La dua estas kondiĉo: ĉu la regula objekto estas ŝaltita en ĉi tiu momento. Amplekso estas tio, kion fajroŝirmo taksas por ĉiu pakaĵo; kondiĉo estas tio, kion skripto skribas en la politikan konservejon, kaj la du estas kunordigitaj laŭ tute malsamaj horloĝoj.

Se la postulo vere estas nur VPN-partneroj, amplekso respondas ĝin sen ia konekta-stata logiko: ligi la regulon al la tunela interfaco aŭ al la tunela adresaro, limigu la malproksimajn adresojn al la klienta baseno, kaj precizigu la echo-tipon anstataŭ «ICMP». Tiu regulo restas ĝusta, kiam neniu VPN estas aktiva, kaj ĝin ne povas malfermi nerrilata profilo.

Se la postulo vere estas publika pordego, diru tion en la politika teksto, ĉar la akceptkriterioj ŝanĝiĝas. Publika pordego devas nomi la precizan profilon, difini, kion signifas «konektita», kaj deklari, ke publikaj sendantoj estas en la amplekso laŭ la dezajno. Plejparto de la konfuzo malaperas en la momento, kiam iu estas devigata skribi tiun frazon.

Konstruu la objekton unufoje, poste ŝaltu ĝin

Antaŭprovizu unu regulon kun stabila identeco, malŝaltita, kaj lasu la regilon ŝanĝi nur ĝian ŝaltan staton. Krei regulojn laŭ la montrata nomo ĉe ĉiu rulo estas la maniero, kiel politika konservejo finiĝas kun kvin preskaŭ identaj objektoj kaj sen fidinda maniero forigi ilin.

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

La nomo estas la daŭra identigilo; la montrata nomo estas dokumentaro, kiun homo povas redakti. Kunordigu laŭ -Name kaj la skripto ĉesos produkti duplikatojn. La sama komanda formo kovras la IPv6-kazon per -Protocol ICMPv6 -IcmpType 128, sed tio estas aparta regulo, ĉar la echo-tipaj numeroj malsamas inter la du familioj.

Tenu la adresan familion kaj la ICMP-tipon eksplicitaj ankaŭ pro dua kialo: -Protocol ICMPv4 sen tipo permesas ĉiun ICMPv4-mesaĝon, kiun la profilo permesas, inkluzive de tiuj, kiujn vi neniam intencis akcepti. Nomi tipon 8 mallarĝigas la regulon al echo-peto, kio estas la sola afero, kiun sendas atingebla-kontrolo.

Kie la aŭtomatigo kontraŭdiras la intencon

Enketi klientan profilon ĉiun kelkajn minutojn ne povas produkti tujan limon. Inter la falo de la konekto kaj la sekva enketo la regulo ankoraŭ respondas ĉe la publika adreso; inter la leviĝo de la konekto kaj la sekva enketo ĝi ne respondas. Konfesi tiun prokraston estas honeste, aserti, ke la dezajno trudas striktan invarianton, ne estas.

En la stata kontrolo mem estas ampleksa kaptilo. Get-VpnConnection raportas klientajn profilojn agorditajn sur la maŝino, defaŭlte por la nuna uzanto kaj por ĉiuj uzantoj per -AllUserConnection. Ĝi ne raportas la malproksimajn uzantojn, kiuj nun estas telefonitaj en RRAS-servilon; tio estas alia observado per alia komando. Pordego konstruita sur la malĝusta ne estas konektita al io.

Poste kovru la statojn, kiujn neniu skriptas: starto kun la regulo jam ŝaltita el antaŭa rulo, kraŝo de la regilo dum la pordego malfermitas, kaj forviŝita profilo dum ĝia regulo restas viva. Ĉiu bezonas difinitan defaŭlton, kaj la sekura defaŭlto por publika permeso estas malŝaltita. Se la postulo vere ne toleras la enketan fenestron, stata regulo estas la malĝusta ilo kaj la plenumado apartenas al la tunelo, ne al la publika interfaco.

Fine, testu la publikan peton dufoje, unufoje kun la elektita konekto aktiva kaj unufoje kun ĝi malaktiva, de gastiganto, kiu ne estas en la VPN. Sukcesa ping el la interno de la tunelo pruvas nenion pri ĉi tiu politiko, kaj ĝuste tiun mezuron plej multaj deplojoj preterlasas.