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

Én Windows VPN-bruker skal nå HTTPS på en server og ikke SMB på samme server, og en rute kan ikke uttrykke det. Begge forespørslene bærer samme destinasjonsadresse, så prefikset som sender trafikk inn i tunnelen bærer også flyten du ville utelukke. Å skille dem krever en regel som undersøker noe finere enn destinasjonen.

To ulike intensjoner bygges med to ulike Windows-mekanismer. Å blande dem gir en policy som ser komplett ut mens den håndhever halvparten av det du mente.

En rute kan ikke skille to tjenester på én adresse

Innebygd VPN-ruting er prefiksbasert: den avgjør hvilke destinasjoner som går gjennom tunnelen og hvilke som blir utenfor. Det er riktig verktøy for å holde ett subnett innenfor og et annet utenfor, og den er blind for porter av konstruksjon. Et trafikkfilter på VPN-profilen legger til en andre dimensjon: det matcher protokoll, fjernadresse og fjernport for det som kan krysse grensesnittet. En IPsec-regel arbeider på et tredje sted og uttrykker hvilke flyter som krever beskyttelse og med hvem de autentiserer. De tre svarer på ulike spørsmål, og ingen erstatter de andre.

Begynn med å skrive den tiltenkte setningen. Tillat bare HTTPS er en tilgangssetning, mens krev IPsec for HTTPS er en beskyttelsessetning, og de to fører til ulik konfigurasjon.

Tilgangsbegrensning og beskyttelseskrav går hver sin vei

En tilgangsbegrensning sier hva som kan bruke grensesnittet, og den håndheves ved å tillate et sett og avvise alt annet. Et beskyttelseskrav sier hvilke flyter som må krypteres og autentiseres, og det håndheves ved å forhandle sikkerhetsassosiasjoner som passer dem. Det første gir en blokkert forespørsel når noe ikke står på listen, mens det andre gir en tilkobling som enten bærer den påkrevde beskyttelsen eller ikke opprettes. Å behandle det ene som det andre er hvordan en policy ender med ikke å blokkere noe eller ikke beskytte noe.

Den praktiske konsekvensen er at en filterliste er et lukket sett. Når en liste finnes på profilen, avvises trafikk over grensesnittet som ikke matcher noen oppføring, så DNS, autentiseringsutvekslinger og enhver avhengighet applikasjonen trenger krever egne oppføringer. Å legge til én bred regel for å dempe avvisningene åpner hele grensesnittet igjen og opphever begrensningen i det stille. Listen bør være så kort som kravet tillater og så komplett som applikasjonen krever.

Bygg filterlisten som et komplett sett

VPNv2-profiler bærer filterlisten atskilt fra rutelisten, og oppføringene er profilegenskaper fremfor kommandoer. For HTTPS-eksemplet trenger oppføringen protokoll 6, fjernadressen og fjernporten, utrullet via administrasjonskanalen eller ProfileXML for profiltypen som brukes. Microsofts definisjon av VPNv2-trafikkfilter fastslår 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 filtreres bort. Å gjøre det motsatte gir en regel som ikke matcher noe, og et puslespill som tar en ettermiddag.

Skriv ruten og filteret som to separate beslutninger. Ruten avgjør at denne serveren nås gjennom tunnelen, og filteret avgjør hvilke tjenester som kan bruke den veien.

Bevis begge utfallene med to forespørsler

Test den tillatte flyten og den avviste flyten hver for seg, og les feilen i stedet for den manglende siden. En avvisning som kommer raskt er en policybeslutning, mens en tidsavbrudd mer sannsynlig er 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 med en vellykket HTTPS-test er utfallet filteret skulle produsere. Avvisning på begge porter betyr at listen mangler noe økten trenger, og tidsavbrudd på begge peker på ruting fremfor filtrering. Hvis de beskyttede flytene viser ingen sikkerhetsassosiasjon i IPsec-utdataene, er beskyttelseskravet ikke oppfylt selv når tilkoblingen lykkes. Les alle fire utdataene sammen, fordi hver alene støtter en annen historie.

Registrer den gjeldende profilen, regelsettet og motpartens policy sammen med resultatene. Historiske kompatibilitetsnotater om eldre Windows-klienter beskriver ikke hva dagens administrerte profilfunksjoner støtter på en bestemt gateway. Versjonsspesifikk atferd hører til i registreringen, ikke i antakelsen.