Brannmurprofiler kontra VPN-utgang: hvorfor offentlig ikke er en rute

Regelen høres presis ut: tillat lokal trafikk på den private profilen og bare VPN-trafikk på den offentlige. Det er den ikke, for en nettverksprofil velger hvilket brannmurregelsett som gjelder og sier ingenting om hvilket adapter som bar en pakke. Å behandle profilnavnet som et krav til ruten er feilen som får et design med begrenset utgang til å se ferdig ut når det ikke er det.

Skriv først ned flytene, og bestem deretter hvilken mekanisme som faktisk kan håndheve hver av dem. Den flytlisten er det eneste artefaktet som overlever den neste regelendringen.

Kategorien velger regler, ikke ruter

Når Windows klassifiserer et nettverk som offentlig eller privat, bruker brannmuren regelsettet som er konfigurert for den profilen. Klassifiseringen følger nettverket adapteret koblet seg til, og regelsettet avgjør hva som er tillatt på det. Ingen av disse fakta avhenger av om trafikken til et program brukte tunnelen. Nettopp denne uavhengigheten er hele vanskeligheten.

Rutevalget tas av ruting, gjennom grensesnittmetrikken og prefikset tunnelen installerer. En profil kan derfor være merket offentlig mens tilkoblingen til et program tar den fysiske veien, og brannmuren vil fortsatt rapportere at det offentlige regelsettet ble brukt.

Derfor kan en regel begrenset til profilen ikke bety bare tunnel. De to egenskapene avgjøres av forskjellige komponenter, og den ene kan ikke erstatte den andre.

En eksplisitt blokkering overstyrer en snevrere tillatelse

Microsofts veiledning for brannmurregler skiller mellom en tillatelse som unntak fra en standard blokkeringshandling og en eksplisitt blokkering som er i konflikt med en tillatelse. Eksplisitte blokkeringer vinner den konflikten, og utgående regler følger samme prioritet.

Så den populære oppskriften med å legge til en regel som blokkerer alt og stole på en snevrere tillatelse plassert over den, gjør ikke det forfatteren forventer. Windows Firewall løser ikke konflikten etter regelrekkefølgen administratoren har tildelt. Blokkeringen gjelder rett og slett, og programmet som kobler til rapporterer tidsavbrudd. Regelen som så ut som unntaket var aldri med i spillet.

Den støttede formen er en standardavvisningspolicy med godkjente tillatelsesregler, der hver tillatelse navngir et program, en tjeneste eller en destinasjon presist nok til å kunne gjennomgås. Det designet tåler en revisjon, fordi hvert unntak er synlig og ingen av dem avhenger av rekkefølgen de ble opprettet i.

To regler som motsier hverandre er verre enn én regel, fordi atferden som følger er korrekt og uforklarlig samtidig.

Gi den utgående policyen én eier

En støttet VPN-klient vedlikeholder allerede sin egen blokkeringsatferd og sine egne unntak for endepunkter. Å legge til ikke-koordinerte manuelle regler kan strande den klienten utenfor tunnelen den trenger for oppsett, eller la en andre vei stå åpen som ingen la merke til.

Bestem hvem som eier den utgående policyen før du skriver regler: klientens egen konfigurasjon, en administrert brannmurpolicy eller en dokumentert lokal unntaksliste med en eier. Avstem deretter lagene i stedet for å stable eksperimenter til noe kobler til. En navngitt eier er også den du spør når to lag er uenige.

Bevar en gjenopprettingskanal før du endrer noe. En fjernmaskin låst ute fra sin egen administrasjonsvei er et verre utfall enn huller i policyen du lukket. Gjenopprettingsregelen er lettere å forsvare når den er skrevet ned på forhånd, og lettere å finne når en endring går galt på en time ingen liker.

Test fire utfall i stedet for å lese etiketten

En policy er bare så god som tilfellene den skiller mellom, så behandle profiletikken som et utgangspunkt og ikke et resultat. Fire utfall forteller om den virker: den tiltenkte LAN-forespørselen lykkes, en dekket internettforespørsel lykkes, en forbudt direkte forespørsel mislykkes, og tilfellet med tunnelfeil oppfører seg som designet i stedet for å falle stille tilbake. Skriv de fire resultatene ned ved siden av regelendringen. En testplan med fire navngitte tilfeller er kort nok til å kjøres hver gang og spesifikk nok til å feile høylytt.

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 kommandoen viser hvordan hvert tilkoblede nettverk er klassifisert, noe som ofte ikke er det personen som skrev regelen antok. Den andre viser standardhandlingen per profil, og den tredje lister aktiverte utgående blokkeringer, inkludert dem som stille vil overstyre en snevrere tillatelse.

Kjør de fire tilfellene igjen etter en nettverksendring, fordi en profil kan reklassifiseres når maskinen kobler seg til et annet nettverk. En samsvarende profiletikett er ikke bevis for at ruten var den du mente.