Firewallprofiler kontra VPN-udgang: hvorfor offentlig ikke er en rute

Reglen lyder præcis: tillad lokal trafik på den private profil og kun VPN-trafik på den offentlige. Det er den ikke, for en netværksprofil vælger, hvilket firewallregelsæt der gælder, og siger intet om, hvilken adapter der bar en pakke. At behandle profilnavnet som et krav til ruten er den fejl, der får et design med begrænset udgang til at se færdigt ud, når det ikke er.

Skriv først flowene ned, og beslut derefter, hvilken mekanisme der reelt kan håndhæve hver af dem. Den flowliste er det eneste artefakt, der overlever den næste regelændring.

Kategorien vælger regler, ikke ruter

Når Windows klassificerer et netværk som offentligt eller privat, anvender firewallen det regelsæt, der er konfigureret til den profil. Klassificeringen følger det netværk, adapteren har tilsluttet sig, og regelsættet afgør, hvad der er tilladt på det. Ingen af disse kendsgerninger afhænger af, om en applikations trafik brugte tunnelen. Netop den uafhængighed er hele vanskeligheden.

Rutevalget træffes af routing, via grænseflademetrikken og det præfiks, som tunnelen installerer. En profil kan derfor være mærket offentlig, mens en applikations forbindelse tager den fysiske vej, og firewallen vil stadig rapportere, at det offentlige regelsæt blev anvendt.

Derfor kan en regel, der er afgrænset til profilen, ikke betyde kun tunnel. De to egenskaber afgøres af forskellige komponenter, og den ene kan ikke erstatte den anden.

En eksplicit blokering overtrumfer en snævrere tilladelse

Microsofts vejledning om firewallregler skelner mellem en tilladelse som undtagelse til en standardblokeringshandling og en eksplicit blokering, der er i konflikt med en tilladelse. Eksplicitte blokeringer vinder den konflikt, og udgående regler følger samme forrang.

Så den populære opskrift at tilføje en regel, der blokerer alt, og stole på en snævrere tilladelse placeret over den, gør ikke det, dens forfatter forventer. Windows Firewall løser ikke konflikten efter den regelrækkefølge, administratoren har tildelt. Blokeringen gælder ganske enkelt, og den forbindende applikation rapporterer en timeout. Reglen, der lignede undtagelsen, var aldrig med i spillet.

Den understøttede form er en standardafvisningspolitik med godkendte tilladelsesregler, hvor hver tilladelse navngiver et program, en tjeneste eller en destination præcist nok til at kunne gennemgås. Det design overlever en revision, fordi hver undtagelse er synlig, og ingen af dem afhænger af den rækkefølge, de blev oprettet i.

To regler, der modsiger hinanden, er værre end én regel, fordi den resulterende adfærd er korrekt og uforklarlig på samme tid.

Giv den udgående politik én ejer

En understøttet VPN-klient vedligeholder allerede sin egen blokeringsadfærd og sine egne undtagelser for endepunkter. Tilføjer man ikke-koordinerede manuelle regler, kan den klient strande uden for den tunnel, den har brug for til opsætning, eller efterlade en anden vej åben, som ingen bemærkede.

Beslut, hvem der ejer den udgående politik, før du skriver regler: klientens egen konfiguration, en administreret firewallpolitik eller en dokumenteret lokal undtagelsesliste med en ejer. Afstem derefter lagene i stedet for at stable eksperimenter, indtil noget forbinder. En navngivet ejer er også den, man spørger, når to lag er uenige.

Bevar en genopretningskanal, før du ændrer noget. En fjernmaskine låst ude af sin egen administrationsvej er et værre udfald end det politikhul, du var ved at lukke. Genopretningsreglen er lettere at begrunde, når den er skrevet ned på forhånd, og lettere at finde, når en ændring går galt på et tidspunkt, ingen nyder.

Test fire udfald i stedet for at læse etiketten

En politik er kun så god som de tilfælde, den skelner, så behandl profilens etiket som et udgangspunkt frem for et resultat. Fire udfald fortæller, om den virker: den tilsigtede LAN-anmodning lykkes, en dækket internetanmodning lykkes, en forbudt direkte anmodning mislykkes, og tilfældet med tunnelfejl opfører sig som designet i stedet for at falde stille tilbage. Skriv de fire resultater ned ved siden af regelændringen. En testplan med fire navngivne tilfælde er kort nok til at køre hver gang og specifik nok til at fejle højlydt.

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

Den første kommando viser, hvordan hvert tilsluttet netværk er klassificeret, hvilket ofte ikke er det, personen bag reglen antog. Den anden viser standardhandlingen pr. profil, og den tredje lister aktiverede udgående blokeringer, inklusive dem, der stille vil tilsidesætte en snævrere tilladelse.

Kør de fire tilfælde igen efter en netværksændring, for en profil kan blive omklassificeret, når maskinen tilslutter sig et andet netværk. En matchende profiletiket er ikke bevis for, at ruten var den, du havde til hensigt.