VPN-trafikkfilter eller IPsec-regel: hvor Windows håndhever en port

Én Windows VPN-bruker må kunne nå HTTPS på en server, men ikke SMB på samme server, og en rute kan ikke uttrykke det. Begge forespørslene har samme destinasjonsadresse, så prefikset som sender trafikk inn i tunnelen bærer også flyten du ville holde utenfor. For å skille dem trengs en regel som ser på noe mer detaljert enn destinasjonen.

To ulike intensjoner bygges med to ulike Windows-mekanismer. Blir de blandet, får man en policy som virker fullstendig, men som bare håndhever halvparten av det du mente.

En rute kan ikke skille to tjenester på samme adresse

Innebygd VPN-ruting er prefiksbasert: den bestemmer hvilke destinasjoner som går gjennom tunnelen og hvilke som blir værende utenfor. Det er det rette verktøyet for å holde ett subnett innenfor og et annet utenfor, og den er blind for porter av natur. Et trafikkfilter på VPN-profilen tilfører en andre dimensjon: det matcher protokoll, fjernadresse og fjernport mot det som kan krysse grensesnittet. En IPsec-regel jobber på et tredje sted og uttrykker hvilke flyter som krever beskyttelse og hvem de autentiserer seg mot. De tre svarer på forskjellige spørsmål, og ingen erstatter de andre.

Start med å skrive ned den tiltenkte setningen. Å tillate bare HTTPS er en tilgangssetning, mens å kreve IPsec for HTTPS er en beskyttelsessetning, og de to fører til forskjellig konfigurasjon.

Tilgangsbegrensning og beskyttelseskrav peker i hver sin retning

En tilgangsbegrensning forteller hva som får bruke grensesnittet, og håndheves ved å tillate et sett og avvise alt annet. Et beskyttelseskrav forteller hvilke flyter som skal krypteres og autentiseres, og håndheves ved å forhandle sikkerhetsassosiasjoner som passer til dem. Det første gir en blokkert forespørsel når noe ikke står på listen, mens det andre gir en forbindelse som enten bærer den påkrevde beskyttelsen eller ikke blir opprettet. Behandler man det ene som det andre, ender en policy med å blokkere ingenting eller beskytte ingenting.

Den praktiske følgen er at en filterliste er et lukket sett. Straks det finnes en liste på profilen, blir trafikk over grensesnittet som ikke matcher noen oppføring avvist, så DNS, autentiseringsutvekslinger og enhver avhengighet applikasjonen trenger, krever egne oppføringer. Legger man til én bred regel for å dempe avvisningene, åpnes hele grensesnittet igjen og begrensningen oppheves i det stille. Listen bør være så kort som kravet tillater og så fullstendig som applikasjonen krever.

Bygg filterlisten som et fullstendig sett

VPNv2-profiler har filterlisten atskilt fra rutelisten, og oppføringene er profilegenskaper og ikke kommandoer. For HTTPS-eksempelet trenger oppføringen protokoll 6, fjernadressen og fjernporten, rullet ut via administrasjonskanalen eller ProfileXML for profiltypen som brukes. Microsofts definisjon av VPNv2-trafikkfilter sier at betingelser innenfor én regel kombineres, mens separate regelidentifikatorer virker som alternativer.

TrafficFilterList/0/Protocol            = 6
TrafficFilterList/0/RemoteAddressRanges = 10.60.4.20/32
TrafficFilterList/0/RemotePortRanges    = 443
RouteList/0/Address                     = 10.60.4.0/24

Portverdiene i listen beskriver tjenesteporten i den fjerne enden, og den lokale porten bør forbli ubegrenset slik at klientens efemere kildeport ikke blir filtrert bort. Gjør man det motsatte, får man en regel som ikke matcher noe, og et puslespill som tar en hel ettermiddag.

Ruten og filteret skrives som to separate beslutninger. Ruten bestemmer at denne serveren nås gjennom tunnelen, og filteret bestemmer hvilke tjenester som får bruke den veien.

Vis begge utfallene med to forespørsler

Den tillatte flyten og den avviste flyten testes hver for seg, og man leser feilen i stedet for den manglende siden. En avvisning som kommer raskt, er en policybeslutning, mens en tidsavbrudd mer sannsynlig skyldes en manglende rute eller en tjeneste som ikke lytter. Kommandoene nedenfor kjører begge forespørslene og viser reglene som gjelder.

Test-NetConnection 10.60.4.20 -Port 443
Test-NetConnection 10.60.4.20 -Port 445
Get-NetIPsecRule -DisplayName *Vpn*
Get-VpnConnection -Name Corp

En rask avvisning i SMB-testen kombinert med en vellykket HTTPS-test er utfallet filteret skulle gi. Avvisning på begge porter betyr at listen mangler noe økten trenger, og tidsavbrudd på begge peker mot ruting og ikke filtrering. Viser de beskyttede flytene ingen sikkerhetsassosiasjon i IPsec-utskriften, er beskyttelseskravet ikke oppfylt selv om forbindelsen lykkes. Alle fire utskriftene må leses sammen, fordi hver av dem alene støtter en annen historie.

Den gjeldende profilen, regelsettet og motpartens policy registreres sammen med resultatene. Historiske kompatibilitetsnotater om eldre Windows-klienter beskriver ikke hva dagens administrerte profilfunksjoner støtter på en gitt gateway. Versjonsavhengig atferd hører hjemme i registreringen, ikke i antagelsen.