Rregulli tingëllon i saktë: lejo trafikun lokal në profilin privat dhe vetëm trafikun VPN në atë publik. Nuk është, sepse një profil rrjeti zgjedh cili grup rregullash firewall-i zbatohet dhe nuk thotë asgjë për atë se cili përshtatës e mbajti paketën. Trajtimi i emrit të profilit si kërkesë rruge është gabimi që e bën një projekt daljeje të kufizuar të duket i përfunduar kur nuk është.

Fillimisht shkruani rrjedhat, pastaj vendosni cili mekanizëm mund të zbatojë vërtet secilën prej tyre. Ai listë rrjedhash është i vetmi artefakt që i mbijeton ndryshimit të radhës të rregullave.

Kategoria zgjedh rregulla, jo rrugë

Kur Windows e klasifikon një rrjet si publik ose privat, firewall-i zbaton grupin e rregullave të konfiguruar për atë profil. Klasifikimi ndjek rrjetin të cilit iu bashkua përshtatësi, dhe grupi i rregullave vendos çfarë lejohet në të. Asnjë prej këtyre fakteve nuk varet nga fakti nëse trafiku i një aplikacioni përdori tunelin. Pikërisht kjo pavarësi është e gjithë vështirësia.

Zgjedhjen e rrugës e bën rrugëtimi, përmes metrikës së ndërfaqes dhe prefiksit që instalon tuneli. Një profil mund të etiketohet si publik ndërkohë që lidhja e një aplikacioni ndjek rrugën fizike, dhe firewall-i prapëseprapë do të raportojë se është zbatuar grupi publik i rregullave.

Prandaj një rregull i kufizuar në profil nuk mund të nënkuptojë vetëm tunel. Këto dy veti vendosen nga komponentë të ndryshëm dhe njëra nuk mund të zëvendësojë tjetrën.

FlowWhat decides itWhat a rule can enforce
VPN client to its endpointRouting plus the outer transportAllow the client process before the tunnel exists
Application to an internet hostInterface metric and prefix lengthBlock the process unless the tunnel interface is up
Application to a LAN hostLocal subnet routeAllow one destination, not the whole category

Një bllokim i qartë mund një leje më të ngushtë

Udhëzimet e Microsoft për rregullat e firewall-it dallojnë një leje si përjashtim nga veprimi i parazgjedhur i bllokimit nga një bllokim i qartë që bie ndesh me një leje. Bllokimet e qarta fitojnë atë konflikt, dhe rregullat dalëse i binden të njëjtit përparësi.

Pra receta popullore për të shtuar një rregull që bllokon gjithçka dhe për t'u mbështetur në një leje më të ngushtë të vendosur sipër nuk bën atë që pret autori i saj. Firewall-i i Windows nuk e zgjidh konfliktin sipas rendit të rregullave të caktuar nga administratori. Bllokimi thjesht zbatohet, dhe aplikacioni që lidhet raporton skadim kohe. Rregulli që dukej si përjashtimi nuk ishte kurrë në lojë.

Forma e mbështetur është një politikë refuzimi të parazgjedhur me rregulla leje të miratuara, ku çdo leje emërton një program, një shërbim ose një destinacion mjaftueshëm saktësisht sa për t'u rishikuar. Ai projekt i reziston një auditimi, sepse çdo përjashtim është i dukshëm dhe asnjë prej tyre nuk varet nga rendi në të cilin u krijua.

Dy rregulla që kundërshtojnë njëri-tjetrin janë më keq se një rregull, sepse sjellja që rezulton është e saktë dhe e pashpjegueshme në të njëjtën kohë.

Jepini politikës dalëse një pronar të vetëm

Një klient VPN i mbështetur tashmë mban sjelljen e vet të bllokimit dhe përjashtimet e veta të pikave fundore. Shtimi i rregullave manuale të pakoordinuara mund ta lërë atë klient jashtë tunelit që i nevojitet për konfigurim, ose të lërë hapur një rrugë të dytë që askush nuk e vuri re.

Vendosni kush e zotëron politikën dalëse përpara se të shkruani rregulla: konfigurimi i vetë klientit, një politikë firewall-i e menaxhuar ose një listë lokale përjashtimesh e dokumentuar me pronar. Pastaj rakordoni shtresat në vend që të grumbulloni eksperimente derisa diçka të lidhet. Një pronar i emërtuar është gjithashtu ai që pyetet kur dy shtresa nuk pajtohen.

Ruani një kanal rikuperimi përpara se të ndryshoni çdo gjë. Një makinë në distancë e kyçur jashtë rrugës së vet të menaxhimit është një rezultat më i keq sesa boshllëku i politikës që po mbyllnit. Rregulli i rikuperimit justifikohet më lehtë kur është shkruar paraprakisht, dhe gjendet më lehtë kur një ndryshim shkon keq në një orë që askush nuk e shijon.

Provoni katër rezultate në vend që të lexoni etiketën

Një politikë vlen aq sa rastet që ajo dallon, prandaj trajtojeni etiketën e profilit si pikënisje dhe jo si rezultat. Katër rezultate ju tregojnë nëse funksionon: kërkesa LAN e synuar ka sukses, një kërkesë interneti e mbuluar ka sukses, një kërkesë e drejtpërdrejtë e ndaluar dështon, dhe rasti i dështimit të tunelit sillet siç është projektuar në vend që të tërhiqet në heshtje. Shkruani katër rezultatet pranë ndryshimit të rregullave. Një plan testimi me katër raste të emërtuara është mjaft i shkurtër për t'u ekzekutuar çdo herë dhe mjaft i saktë për të dështuar me zë.

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

Komanda e parë tregon si klasifikohet çdo rrjet i lidhur, gjë që shpesh nuk është ajo që supozoi personi që shkroi rregullin. E dyta tregon veprimin e parazgjedhur për profil, dhe e treta liston bllokimet dalëse të aktivizuara, duke përfshirë ato që do të anulojnë në heshtje një leje më të ngushtë.

Ekzekutoni përsëri katër rastet pas një ndryshimi rrjeti, sepse një profil mund të riklasifikohet kur makina i bashkohet një rrjeti tjetër. Një etiketë profili që përputhet nuk është provë se rruga ishte ajo që kishit ndër mend.

Artikuj të ngjashëm