Ugunsmūra profili pret VPN izeju: kāpēc publiskais nav ceļš
Ugunsmūra profils izvēlas, kura noteikumu kopa ir spēkā. Tas neko nesaka par to, kura saskarne pārvadāja paketi, un skaidrs bloķējums pārspēj šaurāku atļauju.
Noteikums izklausās precīzi: atļaut vietējo datplūsmu privātajā profilā un tikai VPN datplūsmu publiskajā. Tā nav, jo tīkla profils izvēlas, kura ugunsmūra noteikumu kopa ir spēkā, un neko nesaka par to, kurš adapteris pārvadāja paketi. Profila nosaukuma uztveršana kā ceļa prasība ir kļūda, kuras dēļ ierobežotas izejas projekts izskatās pabeigts, lai gan nav.
Vispirms pierakstiet plūsmas, tad izlemiet, kurš mehānisms patiešām var katru no tām īstenot. Šis plūsmu saraksts ir vienīgais artefakts, kas pārdzīvo nākamo noteikumu maiņu.
Kategorija izvēlas noteikumus, nevis maršrutus
Kad Windows klasificē tīklu kā publisku vai privātu, ugunsmūris piemēro šim profilam konfigurēto noteikumu kopu. Klasifikācija seko tīklam, kuram pievienojās adapteris, un noteikumu kopa izlemj, kas tajā ir atļauts. Neviens no šiem faktiem nav atkarīgs no tā, vai lietotnes datplūsma izmantoja tuneli. Tieši šī neatkarība ir viss grūtums.
Ceļa izvēli veic maršrutēšana, izmantojot saskarnes metriku un prefiksu, ko instalē tunelis. Tāpēc profils var būt atzīmēts kā publisks, kamēr lietotnes savienojums iet pa fizisko ceļu, un ugunsmūris joprojām ziņos, ka piemērota publiskā noteikumu kopa.
Tāpēc uz profilu attiecināts noteikums nevar nozīmēt tikai tuneli. Šīs divas īpašības izlemj dažādas komponentes, un viena nevar aizstāt otru.
| 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 |
Skaidrs bloķējums pārspēj šaurāku atļauju
Microsoft ugunsmūra noteikumu vadlīnijas nošķir atļauju kā izņēmumu no noklusējuma bloķēšanas darbības no skaidra bloķējuma, kas ir pretrunā ar atļauju. Skaidri bloķējumi uzvar šajā konfliktā, un izejošo savienojumu noteikumi ievēro to pašu prioritāti.
Tāpēc populārā recepte pievienot visu bloķējošu noteikumu un paļauties uz šaurāku atļauju, kas novietota virs tā, nedara to, ko sagaida tās autors. Windows ugunsmūris konfliktu nerisina pēc administratora piešķirtās noteikumu kārtas. Bloķējums vienkārši iedarbojas, un savienojošā lietotne ziņo par taimautu. Noteikums, kas izskatījās kā izņēmums, nekad nebija spēlē.
Atbalstītā forma ir noklusējuma aizlieguma politika ar apstiprinātiem atļaujas noteikumiem, kur katra atļauja nosauc programmu, pakalpojumu vai galamērķi pietiekami precīzi, lai to varētu pārskatīt. Šāds projekts iztur auditu, jo katrs izņēmums ir redzams un neviens no tiem nav atkarīgs no izveides kārtas.
Divi noteikumi, kas ir pretrunā viens otram, ir sliktāki par vienu noteikumu, jo iegūtā uzvedība ir vienlaikus pareiza un neizskaidrojama.
Piešķiriet izejošajai politikai vienu īpašnieku
Atbalstīts VPN klients jau uztur savu bloķēšanas uzvedību un savus galapunktu izņēmumus. Nesaskaņotu manuālu noteikumu pievienošana var atstāt šo klientu ārpus tuneļa, kas tam vajadzīgs iestatīšanai, vai atstāt atvērtu otru ceļu, ko neviens nepamanīja.
Izlemiet, kam pieder izejošā politika, pirms rakstāt noteikumus: paša klienta konfigurācija, pārvaldīta ugunsmūra politika vai dokumentēts vietējo izņēmumu saraksts ar īpašnieku. Pēc tam saskaņojiet slāņus, nevis kraujiet eksperimentus, līdz kaut kas savienojas. Nosauktais īpašnieks ir arī tas, ko jautā, kad divi slāņi nav vienisprātis.
Saglabājiet atkopšanas kanālu, pirms kaut ko maināt. Attālināta mašīna, kas izslēgta no sava pārvaldības ceļa, ir sliktāks iznākums nekā politikas robs, ko jūs aizvērāt. Atkopšanas noteikumu ir vieglāk attaisnot, ja tas ir iepriekš pierakstīts, un vieglāk atrast, ja izmaiņas noiet greizi tādā stundā, kas nevienam nepatīk.
Pārbaudiet četrus iznākumus, nevis lasiet etiķeti
Politika ir tik laba, cik labi tā nošķir gadījumus, tāpēc profila etiķeti uzskatiet par sākumpunktu, nevis rezultātu. Četri iznākumi pasaka, vai tā strādā: paredzētais LAN pieprasījums izdodas, aptvertais interneta pieprasījums izdodas, aizliegtais tiešais pieprasījums neizdodas, un tuneļa atteices gadījums uzvedas kā projektēts, nevis klusi atkāpjas. Pierakstiet četrus rezultātus blakus noteikumu maiņai. Testa plāns ar četriem nosauktiem gadījumiem ir pietiekami īss, lai to izpildītu katru reizi, un pietiekami konkrēts, lai skaļi izgāztos.
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
Pirmā komanda parāda, kā tiek klasificēts katrs pievienotais tīkls, kas bieži vien nav tas, ko pieņēma noteikuma rakstītājs. Otrā parāda noklusējuma darbību katram profilam, un trešā uzskaita iespējotos izejošos bloķējumus, tostarp tos, kas klusi atcels šaurāku atļauju.
Palaidiet četrus gadījumus vēlreiz pēc tīkla maiņas, jo profils var tikt pārklasificēts, kad mašīna pievienojas citam tīklam. Atbilstoša profila etiķete nav pierādījums, ka ceļš bija tas, ko jūs domājāt.