Firewallprofielen versus VPN-uitgang: waarom openbaar geen pad is
Een firewallprofiel kiest welke regelset geldt. Het zegt niets over welke interface het pakket heeft gedragen, en een expliciete blokkade wint van een smallere toestemming.
De regel klinkt precies: lokaal verkeer toestaan op het privéprofiel en alleen VPN-verkeer op het openbare. Dat is het niet, want een netwerkprofiel kiest welke firewallregelset geldt en zegt niets over welke adapter een pakket heeft gedragen. De profielnaam als padvereiste behandelen is de fout waardoor een ontwerp met beperkte uitgang af lijkt terwijl het dat niet is.
Schrijf eerst de stromen op en bepaal daarna welk mechanisme elk ervan werkelijk kan afdwingen. Die stromenlijst is het enige artefact dat de volgende regelwijziging overleeft.
De categorie kiest regels, geen routes
Wanneer Windows een netwerk als openbaar of privé classificeert, past de firewall de regelset toe die voor dat profiel is geconfigureerd. De classificatie volgt het netwerk waar de adapter lid van is geworden, en de regelset bepaalt wat daarop is toegestaan. Geen van die feiten hangt ervan af of het verkeer van een toepassing de tunnel gebruikte. Juist die onafhankelijkheid is de hele moeilijkheid.
De padkeuze wordt gemaakt door routing, via de interfacemetriek en het prefix dat de tunnel installeert. Een profiel kan dus als openbaar gelabeld zijn terwijl de verbinding van een toepassing het fysieke pad neemt, en de firewall meldt nog steeds dat de openbare regelset is toegepast.
Daarom kan een regel die tot het profiel beperkt is niet alleen tunnel betekenen. De twee eigenschappen worden door verschillende componenten bepaald en de ene kan de andere niet vervangen.
| 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 |
Een expliciete blokkade gaat voor een smallere toestemming
De richtlijnen van Microsoft voor firewallregels onderscheiden een toestemming als uitzondering op een standaardblokkeeractie van een expliciete blokkade die in strijd is met een toestemming. Expliciete blokkades winnen dat conflict, en uitgaande regels volgen dezelfde voorrang.
Het populaire recept om een regel toe te voegen die alles blokkeert en te vertrouwen op een smallere toestemming daarboven doet dus niet wat de auteur ervan verwacht. Windows Firewall lost het conflict niet op via de regelvolgorde die de beheerder heeft toegewezen. De blokkade geldt eenvoudigweg, en de toepassing die verbinding maakt meldt een time-out. De regel die op de uitzondering leek, was nooit in het spel.
De ondersteunde vorm is een standaardweigeringsbeleid met goedgekeurde toestemmingsregels, waarbij elke toestemming een programma, een service of een bestemming precies genoeg benoemt om te kunnen worden beoordeeld. Dat ontwerp doorstaat een audit, omdat elke uitzondering zichtbaar is en geen ervan afhangt van de volgorde waarin ze is gemaakt.
Twee regels die elkaar tegenspreken zijn erger dan een regel, omdat het resulterende gedrag tegelijk correct en onverklaarbaar is.
Geef het uitgaande beleid een eigenaar
Een ondersteunde VPN-client onderhoudt al zijn eigen blokkeergedrag en zijn eigen uitzonderingen voor eindpunten. Het toevoegen van niet-afgestemde handmatige regels kan die client buiten de tunnel laten stranden die hij nodig heeft om in te stellen, of een tweede pad open laten dat niemand opmerkte.
Bepaal wie het uitgaande beleid bezit voordat je regels schrijft: de eigen configuratie van de client, een beheerd firewallbeleid of een gedocumenteerde lokale uitzonderingenlijst met een eigenaar. Verzoen daarna de lagen in plaats van experimenten te stapelen tot er iets verbindt. Een genoemde eigenaar is ook degene die je vraagt wanneer twee lagen het oneens zijn.
Behoud een herstelkanaal voordat je iets wijzigt. Een externe machine die buiten zijn eigen beheerpad is buitengesloten, is een slechtere uitkomst dan het beleidsgat dat je aan het dichten was. De herstelregel is gemakkelijker te rechtvaardigen als hij vooraf is opgeschreven, en gemakkelijker te vinden als een wijziging misgaat op een uur dat niemand prettig vindt.
Test vier uitkomsten in plaats van het label te lezen
Een beleid is zo goed als de gevallen die het onderscheidt, dus behandel het profiellabel als een startpunt en niet als een resultaat. Vier uitkomsten vertellen of het werkt: de bedoelde LAN-aanvraag slaagt, een gedekte internetaanvraag slaagt, een verboden directe aanvraag mislukt, en het geval van tunneluitval gedraagt zich zoals ontworpen in plaats van stil terug te vallen. Schrijf de vier resultaten naast de regelwijziging. Een testplan met vier benoemde gevallen is kort genoeg om elke keer te draaien en specifiek genoeg om luid te falen.
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
De eerste opdracht laat zien hoe elk verbonden netwerk is geclassificeerd, wat vaak niet is wat de persoon die de regel schreef aannam. De tweede toont de standaardactie per profiel, en de derde somt ingeschakelde uitgaande blokkades op, inclusief de blokkades die stil een smallere toestemming zullen overrulen.
Voer de vier gevallen opnieuw uit na een netwerkwijziging, want een profiel kan opnieuw worden geclassificeerd wanneer de machine lid wordt van een ander netwerk. Een overeenkomend profiellabel is geen bewijs dat het pad het pad was dat je bedoelde.