Perfils de tallafocs enfront de la sortida VPN: per què públic no és un camí
Un perfil de tallafocs tria quin conjunt de regles s'aplica. No diu res sobre quina interfície va portar el paquet, i un bloqueig explícit guanya un permís més estret.
La regla sona precisa: permet el trànsit local al perfil privat i només el trànsit VPN al públic. No ho és, perquè un perfil de xarxa tria quin conjunt de regles de tallafocs s'aplica i no diu res sobre quin adaptador va portar un paquet. Tractar el nom del perfil com un requisit de camí és l'error que fa que un disseny de sortida restringida sembli acabat quan no ho és.
Primer anoteu els fluxos i després decidiu quin mecanisme pot fer complir realment cadascun. Aquesta llista de fluxos és l'únic artefacte que sobreviu al canvi de regles següent.
La categoria tria regles, no rutes
Quan Windows classifica una xarxa com a pública o privada, el tallafocs aplica el conjunt de regles configurat per a aquest perfil. La classificació segueix la xarxa a la qual s'ha unit l'adaptador, i el conjunt de regles decideix què s'hi permet. Cap d'aquests fets no depèn de si el trànsit d'una aplicació va fer servir el túnel. Aquesta independència és tota la dificultat.
L'encaminament fa l'elecció del camí, mitjançant la mètrica de la interfície i el prefix que instal·la el túnel. Un perfil pot estar etiquetat com a públic mentre la connexió d'una aplicació pren el camí físic, i el tallafocs encara informarà que s'ha aplicat el conjunt de regles públic.
Per això una regla limitada al perfil no pot voler dir només túnel. Les dues propietats les decideixen components diferents i l'una no pot substituir l'altra.
| 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 |
Un bloqueig explícit supera un permís més estret
Les directrius de Microsoft sobre regles de tallafocs distingeixen un permís com a excepció a una acció de bloqueig per defecte d'un bloqueig explícit que entra en conflicte amb un permís. Els bloquejos explícits guanyen aquest conflicte, i les regles de sortida obeeixen la mateixa precedència.
Per tant, la recepta popular d'afegir una regla que ho bloqueja tot i confiar en un permís més estret col·locat a sobre no fa el que el seu autor espera. El Tallafocs de Windows no resol el conflicte per l'ordre de regles assignat per l'administrador. El bloqueig simplement s'aplica, i l'aplicació que es connecta informa d'un temps d'espera esgotat. La regla que semblava l'excepció mai no va entrar en joc.
La forma admesa és una política de denegació per defecte amb regles de permís aprovades, on cada permís anomena un programa, un servei o una destinació amb prou precisió per poder-se revisar. Aquest disseny sobreviu a una auditoria, perquè cada excepció és visible i cap no depèn de l'ordre en què es va crear.
Dues regles que es contradiuen són pitjor que una regla, perquè el comportament resultant és correcte i inexplicable alhora.
Doneu a la política de sortida un sol propietari
Un client VPN admès ja manté el seu propi comportament de bloqueig i les seves pròpies excepcions de punt final. Afegir regles manuals no coordinades pot deixar aquest client fora del túnel que necessita per configurar-se, o deixar obert un segon camí que ningú no va notar.
Decidiu qui posseeix la política de sortida abans d'escriure regles: la configuració pròpia del client, una política de tallafocs gestionada o una llista local d'excepcions documentada amb un propietari. Després reconcilieu les capes en lloc d'apilar experiments fins que alguna cosa es connecti. Un propietari amb nom és també a qui pregunteu quan dues capes no es posen d'acord.
Preserveu un canal de recuperació abans de canviar res. Una màquina remota tancada fora del seu propi camí de gestió és un resultat pitjor que el buit de política que tancàveu. La regla de recuperació és més fàcil de justificar quan està escrita per endavant, i més fàcil de trobar quan un canvi va malament a una hora que a ningú no agrada.
Proveu quatre resultats en lloc de llegir l'etiqueta
Una política és tan bona com els casos que distingeix, així que tracteu l'etiqueta del perfil com un punt de partida i no com un resultat. Quatre resultats us diuen si funciona: la sol·licitud LAN prevista té èxit, una sol·licitud d'internet coberta té èxit, una sol·licitud directa prohibida falla, i el cas de fallada del túnel es comporta com es va dissenyar en lloc de retrocedir en silenci. Anoteu els quatre resultats al costat del canvi de regles. Un pla de proves amb quatre casos anomenats és prou curt per executar-lo cada vegada i prou concret per fallar sorollosament.
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 primera ordre mostra com es classifica cada xarxa connectada, cosa que sovint no és el que la persona que va escriure la regla va suposar. La segona mostra l'acció per defecte de cada perfil, i la tercera llista els bloquejos de sortida habilitats, incloent-hi qualsevol que anul·li en silenci un permís més estret.
Torneu a executar els quatre casos després d'un canvi de xarxa, perquè un perfil es pot reclassificar quan la màquina s'uneix a una xarxa diferent. Una etiqueta de perfil coincident no és prova que el camí fos el que volíeu.