Brannmurprofilar kontra VPN-utgang: kvifor offentleg ikkje er ei rute

Regelen høyrest presis ut: tillat lokal trafikk på den private profilen og berre VPN-trafikk på den offentlege. Det er han ikkje, for ein nettverksprofil vel kva brannmurregelsett som gjeld og seier ingenting om kva adapter som bar ein pakke. Å handsame profilnamnet som eit krav til ruta er feilen som får eit design med avgrensa utgang til å sjå ferdig ut når det ikkje er det.

Skriv først ned flyta, og avgjer deretter kva mekanisme som faktisk kan handheve kvar av dei. Den flytlista er det einaste artefaktet som overlever den neste regelendringa.

Kategorien vel reglar, ikkje ruter

Når Windows klassifiserer eit nettverk som offentleg eller privat, brukar brannmuren regelsettet som er konfigurert for den profilen. Klassifiseringa følgjer nettverket adapteren knytte seg til, og regelsettet avgjer kva som er tillate på det. Ingen av desse fakta avheng av om trafikken til eit program brukte tunnelen. Nettopp denne uavhengigheita er heile vanskegrada.

Rutevalet blir teke av ruting, gjennom grensesnittmetrikken og prefikset tunnelen installerer. Ein profil kan difor vere merkt offentleg medan tilkoplinga til eit program tek den fysiske vegen, og brannmuren vil framleis rapportere at det offentlege regelsettet vart brukt.

Difor kan ein regel avgrensa til profilen ikkje bety berre tunnel. Dei to eigenskapane blir avgjorde av ulike komponentar, og den eine kan ikkje erstatte den andre.

Ei eksplisitt blokkering overstyrer eit snevrare løyve

Retningslinjene til Microsoft for brannmurreglar skil mellom eit løyve som unntak frå ei standard blokkeringshandling og ei eksplisitt blokkering som er i konflikt med eit løyve. Eksplisitte blokkeringar vinn den konflikten, og utgåande reglar følgjer same prioritet.

Så den populære oppskrifta med å leggje til ein regel som blokkerer alt og stole på eit snevrare løyve plassert over han, gjer ikkje det forfattaren ventar. Windows Firewall løyser ikkje konflikten etter regelrekkjefølgja administratoren har tildelt. Blokkeringa gjeld rett og slett, og programmet som koplar til rapporterer tidsavbrot. Regelen som såg ut som unntaket var aldri med i spelet.

Den støtta forma er ein standardavvisningspolicy med godkjende løyvereglar, der kvart løyve namngir eit program, ei teneste eller ein destinasjon presist nok til å kunne gjennomgåast. Det designet toler ein revisjon, fordi kvart unntak er synleg og ingen av dei avheng av rekkjefølgja dei vart oppretta i.

To reglar som motseler kvarandre er verre enn ein regel, fordi åtferda som følgjer er korrekt og uforklarleg samstundes.

Gi den utgåande policyen ein eigar

Ein støtta VPN-klient vedlikeheld allereie si eiga blokkeringsåtferd og sine eigne unntak for endepunkt. Å leggje til ikkje-koordinerte manuelle reglar kan strande den klienten utanfor tunnelen han treng for oppsett, eller la ein andre veg stå open som ingen la merke til.

Avgjer kven som eig den utgåande policyen før du skriv reglar: konfigurasjonen til klienten sjølv, ein administrert brannmurpolicy eller ei dokumentert lokal unntaksliste med ein eigar. Avstem deretter laga i staden for å stable eksperiment til noko koplar til. Ein namngitt eigar er også den du spør når to lag er usamde.

Ta vare på ein gjenopprettingskanal før du endrar noko. Ein fjernmaskin låst ute frå sin eigen administrasjonsveg er eit verre utfall enn holet i policyen du lukka. Gjenopprettingsregelen er lettare å forsvare når han er skriven ned på førehand, og lettare å finne når ei endring går gale på ei tid ingen likar.

Test fire utfall i staden for å lese etiketten

Ein policy er berre så god som tilfella han skil mellom, så handsam profiletiketten som eit utgangspunkt og ikkje eit resultat. Fire utfall fortel om han verkar: den tiltenkte LAN-førespurnaden lukkast, ein dekt internettførespurnad lukkast, ein forboden direkte førespurnad mislukkast, og tilfellet med tunnelfeil oppfører seg som designa i staden for å falle stille tilbake. Skriv dei fire resultata ned ved sida av regelendringa. Ein testplan med fire namngitte tilfelle er kort nok til å køyrast kvar gong og spesifikk nok til å feile høgt.

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 korleis kvart tilkopla nettverk er klassifisert, noko som ofte ikkje er det personen som skreiv regelen antok. Den andre viser standardhandlinga per profil, og den tredje listar aktiverte utgåande blokkeringar, inkludert dei som stille vil overstyre eit snevrare løyve.

Køyr dei fire tilfella igjen etter ei nettverksendring, fordi ein profil kan bli reklassifisert når maskinen koplar seg til eit anna nettverk. Ein samsvarande profiletikett er ikkje prov på at ruta var den du meinte.