Ugniasienės profiliai ir VPN išėjimas: kodėl viešas nėra kelias
Ugniasienės profilis parenka, kuri taisyklių grupė galioja. Jis nieko nesako apie tai, kuri sąsaja perdavė paketą, o aiškus blokavimas nugali siauresnį leidimą.
Taisyklė skamba tiksliai: leisti vietinį srautą privačiame profilyje ir tik VPN srautą viešajame. Taip nėra, nes tinklo profilis parenka, kuri ugniasienės taisyklių grupė galioja, ir nieko nesako apie tai, koks adapteris perdavė paketą. Profilio pavadinimo traktavimas kaip kelio reikalavimo yra klaida, dėl kurios riboto išėjimo projektas atrodo baigtas, nors nėra.
Pirmiausia surašykite srautus, tada nuspręskite, kuris mechanizmas iš tiesų gali kiekvieną jų įgyvendinti. Tas srautų sąrašas yra vienintelis artefaktas, kuris išlieka po kito taisyklių pakeitimo.
Kategorija renkasi taisykles, o ne maršrutus
Kai Windows priskiria tinklą viešajam arba privačiam, ugniasienė taiko tam profiliui sukonfigūruotą taisyklių grupę. Priskyrimas seka tinklą, prie kurio prisijungė adapteris, o taisyklių grupė nusprendžia, kas jame leidžiama. Nė vienas iš šių faktų nepriklauso nuo to, ar programos srautas naudojo tunelį. Būtent šis nepriklausomumas ir yra visas sunkumas.
Kelio pasirinkimą atlieka maršrutizavimas, per sąsajos metriką ir priešdėlį, kurį įdiegia tunelis. Todėl profilis gali būti pažymėtas viešu, kol programos ryšys eina fiziniu keliu, ir ugniasienė vis tiek praneš, kad buvo pritaikyta viešoji taisyklių grupė.
Todėl profiliu apribota taisyklė negali reikšti vien tunelio. Šias dvi savybes nusprendžia skirtingi komponentai, ir vienas negali pakeisti kito.
| 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 |
Aiškus blokavimas viršija siauresnį leidimą
Microsoft ugniasienės taisyklių gairės skiria leidimą kaip išimtį iš numatytojo blokavimo veiksmo nuo aiškaus blokavimo, kuris prieštarauja leidimui. Aiškūs blokavimai laimi tą konfliktą, o siunčiamųjų ryšių taisyklės laikosi tos pačios pirmenybės.
Taigi populiarus receptas pridėti viską blokuojančią taisyklę ir pasikliauti aukščiau padėtu siauresniu leidimu nedaro to, ko tikisi jo autorius. Windows ugniasienė konflikto nesprendžia administratoriaus priskirta taisyklių tvarka. Blokavimas tiesiog įsigalioja, o besijungianti programa praneša apie skirtąjį laiką. Taisyklė, kuri atrodė kaip išimtis, niekada nebuvo žaidime.
Palaikoma forma yra numatytojo draudimo politika su patvirtintomis leidimo taisyklėmis, kur kiekvienas leidimas įvardija programą, paslaugą ar paskirties vietą pakankamai tiksliai, kad būtų galima peržiūrėti. Toks projektas atlaiko auditą, nes kiekviena išimtis yra matoma ir nė viena nepriklauso nuo sukūrimo tvarkos.
Dvi taisyklės, kurios prieštarauja viena kitai, yra blogiau nei viena taisyklė, nes gaunamas elgesys yra kartu teisingas ir nepaaiškinamas.
Suteikite siunčiamajai politikai vieną savininką
Palaikomas VPN klientas jau tvarko savo blokavimo elgesį ir savo pabaigos taškų išimtis. Nepritvirtinti rankinių taisyklių pridėjimas gali palikti tą klientą už tunelio, kurio jam reikia sąrankai, arba palikti atvirą antrą kelią, kurio niekas nepastebėjo.
Nuspręskite, kam priklauso siunčiamoji politika, prieš rašydami taisykles: paties kliento konfigūracija, valdoma ugniasienės politika ar dokumentuotas vietinių išimčių sąrašas su savininku. Tada suderinkite sluoksnius, o ne kraukite eksperimentus, kol kažkas prisijungs. Įvardytas savininkas taip pat yra tas, kurio klausiama, kai du sluoksniai nesutaria.
Išsaugokite atkūrimo kanalą, prieš ką nors keisdami. Nuotolinis kompiuteris, užrakintas už savo paties valdymo kelio, yra blogesnis rezultatas nei politiko spraga, kurią uždarėte. Atkūrimo taisyklę lengviau pagrįsti, kai ji iš anksto užrašyta, ir lengviau rasti, kai pakeitimas nepavyksta tokią valandą, kurios niekas nemėgsta.
Išbandykite keturis rezultatus, o ne skaitykite etiketę
Politika yra tokia gera, kiek atvejų ji atskiria, todėl profilio etiketę laikykite išeities tašku, o ne rezultatu. Keturi rezultatai pasako, ar ji veikia: numatytas LAN užklausa pavyksta, apimta interneto užklausa pavyksta, uždrausta tiesioginė užklausa nepavyksta, o tunelio gedimo atvejis elgiasi taip, kaip suprojektuota, o ne tyliai atsitraukia. Užrašykite keturis rezultatus šalia taisyklių pakeitimo. Bandymų planas su keturiais įvardytais atvejais yra pakankamai trumpas, kad būtų vykdomas kiekvieną kartą, ir pakankamai konkretus, kad garsiai žlugtų.
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
Pirmoji komanda parodo, kaip klasifikuojamas kiekvienas prijungtas tinklas, o tai dažnai nėra tai, ką numatė taisyklę rašęs žmogus. Antroji parodo numatytąjį veiksmą pagal profilį, o trečioji išvardija įjungtus siunčiamuosius blokavimus, įskaitant tuos, kurie tyliai panaikins siauresnį leidimą.
Paleiskite keturis atvejus dar kartą po tinklo pakeitimo, nes profilis gali būti perklasifikuotas, kai kompiuteris prisijungia prie kito tinklo. Sutampanti profilio etiketė nėra įrodymas, kad kelias buvo tas, kurį norėjote.