Fajroŝirmilaj profiloj kontraŭ VPN-eliro: kial publika ne estas vojo
Fajroŝirmila profilo elektas, kiu regulkompleto validas. Ĝi diras nenion pri tio, kiu interfaco portis la paketon, kaj eksplicita blokado superas pli mallarĝan permeson.
La regulo sonas preciza: permesi lokan trafikon en la privata profilo kaj nur VPN-trafikon en la publika. Ĝi ne estas, ĉar reta profilo elektas, kiu fajroŝirmila regulkompleto validas, kaj diras nenion pri tio, kiu adaptilo portis paketon. Trakti la profilan nomon kiel postulon de vojo estas la eraro, pro kiu restrikta elira dezajno aspektas finita, kiam ĝi ne estas.
Unue skribu la fluojn, poste decidu, kiu mekanismo povas efektive devigi ĉiun el ili. Tiu fluolisto estas la sola artefakto, kiu postvivas la sekvan regulŝanĝon.
La kategorio elektas regulojn, ne vojojn
Kiam Windows klasifikas reton kiel publikan aŭ privatan, la fajroŝirmilo aplikas la regulkompleton agorditan por tiu profilo. La klasifiko sekvas la reton, al kiu la adaptilo aliĝis, kaj la regulkompleto decidas, kio estas permesita en ĝi. Neniu el tiuj faktoj dependas de tio, ĉu la trafiko de aplikaĵo uzis la tunelon. Ĝuste tiu sendependeco estas la tuta malfacilaĵo.
La vojdecidon faras enkursigado, per la interfaca metriko kaj la prefikso, kiun la tunelo instalas. Profilo do povas esti etikedita publika, dum la konekto de aplikaĵo prenas la fizikan vojon, kaj la fajroŝirmilo ankoraŭ raportos, ke la publika regulkompleto estis aplikita.
Tial regulo limigita al la profilo ne povas signifi nur tunelon. La du ecojn decidas malsamaj komponantoj, kaj unu ne povas anstataŭi la alian.
| Flow | What decides it | What a rule can enforce |
|---|---|---|
| VPN client to its endpoint | Routing plus the outer transport | Allow the client process before the tunnel exists |
| Application to an internet host | Interface metric and prefix length | Block the process unless the tunnel interface is up |
| Application to a LAN host | Local subnet route | Allow one destination, not the whole category |
Eksplicita blokado superas pli mallarĝan permeson
La gvidlinioj de Microsoft pri fajroŝirmilaj reguloj distingas permeson kiel escepton al la implicita bloka ago de eksplicita blokado, kiu kontraŭdiras permeson. Eksplicitaj blokadoj gajnas tiun konflikton, kaj eliraj reguloj sekvas la saman prioritaton.
Do la populara recepto aldoni regulon, kiu blokas ĉion, kaj fidi pli mallarĝan permeson metitan super ĝi, ne faras tion, kion ĝia aŭtoro atendas. Windows Firewall ne solvas la konflikton laŭ la regulordo difinita de la administranto. La blokado simple validas, kaj la konektanta aplikaĵo raportas tempolimon. La regulo, kiu aspektis kiel la escepto, neniam partoprenis.
La subtenata formo estas implicita malpermesa politiko kun aprobitaj permesaj reguloj, kie ĉiu permeso nomas programon, servon aŭ celon sufiĉe precize, por ke ĝi povu esti reviziita. Tiu dezajno postvivas revizion, ĉar ĉiu escepto estas videbla kaj neniu dependas de la ordo, en kiu ĝi estis kreita.
Du reguloj, kiuj kontraŭdiras unu la alian, estas pli malbonaj ol unu regulo, ĉar la rezulta konduto estas samtempe ĝusta kaj neklarigebla.
Donu al la elira politiko unu solan posedanton
Subtenata VPN-kliento jam prizorgas sian propran blokadan konduton kaj siajn proprajn esceptojn de finpunktoj. Aldoni nekunordigitajn manajn regulojn povas lasi tiun klienton ekster la tunelo, kiun ĝi bezonas por agordo, aŭ lasi malfermita duan vojon, kiun neniu rimarkis.
Decidu, kiu posedas la eliran politikon antaŭ ol skribi regulojn: la propra agordo de la kliento, administrita fajroŝirmila politiko aŭ dokumentita loka esceptlisto kun posedanto. Poste kongruigu la tavolojn anstataŭ staki eksperimentojn, ĝis io konektiĝos. Nomita posedanto estas ankaŭ tiu, kiun vi demandas, kiam du tavoloj malkongruas.
Konservu reakiran kanalon antaŭ ol ŝanĝi ion ajn. Fora maŝino ŝlosita ekster sia propra administra vojo estas pli malbona rezulto ol la politika manko, kiun vi fermis. La reakira regulo estas pli facile pravigebla, kiam ĝi estas anticipe skribita, kaj pli facile trovebla, kiam ŝanĝo fuŝiĝas en horo, kiun neniu ŝatas.
Testu kvar rezultojn anstataŭ legi la etikedon
Politiko estas nur tiom bona, kiom la kazojn ĝi distingas, do traktu la profilan etikedon kiel komencan punkton, ne kiel rezulton. Kvar rezultoj diras al vi, ĉu ĝi funkcias: la intencita LAN-peto sukcesas, kovrita interreta peto sukcesas, malpermesita rekta peto malsukcesas, kaj la kazo de tunela fiasko kondutas sin kiel planite anstataŭ silente retiriĝi. Skribu la kvar rezultojn apud la regulŝanĝo. Testplano kun kvar nomitaj kazoj estas sufiĉe mallonga por ruli ĉiufoje kaj sufiĉe specifa por malsukcesi laŭte.
Get-NetConnectionProfile | Select-Object Name,NetworkCategory,InterfaceAlias Get-NetFirewallProfile | Select-Object Name,DefaultOutboundAction Get-NetFirewallRule -Direction Outbound -Enabled True | Where-Object Action -eq Block | Select-Object DisplayName,Profile
La unua komando montras, kiel ĉiu konektita reto estas klasifikita, kio ofte ne estas tio, kion supozis la persono, kiu verkis la regulon. La dua montras la implicitan agon por profilo, kaj la tria listigas ŝaltitajn elirajn blokadojn, inkluzive tiujn, kiuj silente nuligos pli mallarĝan permeson.
Rulu la kvar kazojn denove post reta ŝanĝo, ĉar profilo povas esti reklasifikita, kiam la maŝino aliĝas al alia reto. Kongrua profila etikedo ne estas pruvo, ke la vojo estis tiu, kiun vi intencis.