Firewall-profiele teenoor VPN-uitgang: waarom publiek nie 'n roete is nie
'n Firewall-profiel kies watter reëlstel geld. Dit sê niks oor watter koppelvlak die pakket gedra het nie, en 'n eksplisiete blokkade wen van 'n nouer toelating.
Die reël klink presies: laat plaaslike verkeer op die private profiel toe en slegs VPN-verkeer op die publieke een. Dit is nie, want 'n netwerkprofiel kies watter firewall-reëlstel geld en sê niks oor watter adapter 'n pakket gedra het nie. Om die profielnaam as 'n roetevereiste te behandel, is die fout wat 'n ontwerp met beperkte uitgang laat lyk asof dit klaar is terwyl dit nie is nie.
Skryf eers die vloei neer en besluit dan watter meganisme elkeen werklik kan afdwing. Daardie vloeilye is die enigste artefak wat die volgende reëlverandering oorleef.
Die kategorie kies reëls, nie roetes nie
Wanneer Windows 'n netwerk as publiek of privaat klassifiseer, pas die firewall die reëlstel toe wat vir daardie profiel opgestel is. Die klassifikasie volg die netwerk waarby die adapter aangesluit het, en die reëlstel besluit wat daarop toegelaat word. Nie een van daardie feite hang daarvan af of 'n toepassing se verkeer die tonnel gebruik het nie. Daardie onafhanklikheid is die hele moeilikheid.
Roetebepaling maak die padkeuse, deur die koppelvlakmetriek en die voorvoegsel wat die tonnel installeer. 'n Profiel kan dus as publiek gemerk word terwyl 'n toepassing se verbinding die fisiese pad volg, en die firewall sal steeds rapporteer dat die publieke reëlstel toegepas is.
Dit is waarom 'n reël wat op die profiel gerig is nie net-tonnel kan beteken nie. Die twee eienskappe word deur verskillende komponente besluit en die een kan nie die ander vervang nie.
| 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 |
'n Eksplisiete blokkade staan bo 'n nouer toelating
Microsoft se riglyne vir firewall-reëls onderskei 'n toelatingsuitsondering op 'n verstekblokkeeraksie van 'n eksplisiete blokkade wat met 'n toelating bots. Eksplisiete blokkades wen daardie botsing, en uitgaande reëls gehoorsaam dieselfde voorrang.
Die gewilde resep om 'n alles-blokkeer-reël by te voeg en op 'n nouer toelating daarbo te vertrou, doen dus nie wat sy skrywer verwag nie. Windows Firewall los die botsing nie op deur die reëlorde wat die administrateur toegewys het nie. Die blokkade geld eenvoudig, en die verbindende toepassing rapporteer 'n tydverstreke. Die reël wat soos die uitsondering gelyk het, was nooit in die wedloop nie.
Die ondersteunde vorm is 'n verstek-weier-beleid met goedgekeurde toelatingsreëls, waar elke toelating 'n program, 'n diens of 'n bestemming presies genoeg noem om nagesien te kan word. Daardie ontwerp oorleef 'n oudit, want elke uitsondering is sigbaar en nie een daarvan hang af van die orde waarin dit geskep is nie.
Twee reëls wat mekaar weerspreek, is slegter as een reël, want die gevolglike gedrag is terselfdertyd korrek en onverklaarbaar.
Gee die uitgaande beleid 'n enkele eienaar
'n Ondersteunde VPN-kliënt onderhou reeds sy eie blokkeergedrag en sy eie eindpunt-uitsonderings. Om ongekoördineerde handmatige reëls by te voeg, kan daardie kliënt buite die tonnel laat beland wat hy vir die opstelling nodig het, of 'n tweede pad oop laat wat niemand raakgesien het nie.
Besluit wie die uitgaande beleid besit voordat jy reëls skryf: die kliënt se eie konfigurasie, 'n bestuurde firewall-beleid, of 'n gedokumenteerde plaaslike uitsonderingslys met 'n eienaar. Versoen dan die lae in plaas daarvan om eksperimente te stapel tot iets verbind. 'n Genoemde eienaar is ook die een wat jy vra wanneer twee lae verskil.
Bewaar 'n herstelkanaal voordat jy iets verander. 'n Afgeleë masjien wat van sy eie bestuurspad uitgesluit is, is 'n slegter uitkoms as die beleidsgaping wat jy wou toemaak. Die herstelreël is makliker om te regverdig wanneer dit vooraf neergeskryf is, en makliker om te vind wanneer 'n verandering op 'n uur wat niemand geniet, verkeerd loop.
Toets vier uitkomste in plaas daarvan om die etiket te lees
'n Beleid is net so goed soos die gevalle wat dit onderskei, so behandel die profieletiket as 'n vertrekpunt eerder as 'n resultaat. Vier uitkomste sê of dit werk: die beoogde LAN-versoek slaag, 'n gedekte internetversoek slaag, 'n verbode direkte versoek misluk, en die tonnelmislukkingsgeval gedra hom soos ontwerp in plaas daarvan om stilweg terug te val. Skryf die vier resultate langs die reëlverandering neer. 'n Toetsplan met vier benoemde gevalle is kort genoeg om elke keer te loop en spesifiek genoeg om hard te misluk.
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
Die eerste opdrag wys hoe elke gekoppelde netwerk geklassifiseer is, wat dikwels nie is wat die persoon wat die reël geskryf het, aangeneem het nie. Die tweede wys die verstekaksie per profiel, en die derde lys geaktiveerde uitgaande blokkades, insluitend dié wat 'n nouer toelating stilweg buite werking sal stel.
Voer die vier gevalle weer uit ná 'n netwerkverandering, want 'n profiel kan herklassifiseer word wanneer die masjien by 'n ander netwerk aansluit. 'n Passende profieletiket is nie bewys dat die pad die een was wat jy bedoel het nie.