VPN-trafikfilter eller IPsec-regel: hvor Windows håndhæver en port

Én Windows VPN-bruger skal nå HTTPS på en server og ikke SMB på samme server, og en rute kan ikke udtrykke det. Begge anmodninger bærer samme destinationsadresse, så det præfiks, der sender trafik ind i tunnelen, bærer også det flow, du ville udelukke. At skille dem ad kræver en regel, der undersøger noget finere end destinationen.

To forskellige hensigter bygges med to forskellige Windows-mekanismer. At blande dem giver en politik, der ser komplet ud, mens den håndhæver halvdelen af det, du mente.

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

Indbygget VPN-routing er præfiksbaseret: den afgør, hvilke destinationer der rejser gennem tunnelen, og hvilke der bliver udenfor. Det er det rigtige værktøj til at holde et subnet inde og et andet ude, og den er blind for porte af konstruktion. Et trafikfilter på VPN-profilen tilføjer en anden dimension: det matcher protokol, fjernadresse og fjernport for, hvad der må krydse den grænseflade. En IPsec-regel arbejder et tredje sted og udtrykker, hvilke flows der kræver beskyttelse, og med hvem de godkender. De tre besvarer forskellige spørgsmål, og ingen erstatter de andre.

Begynd med at skrive den tilsigtede sætning. Tillad kun HTTPS er en adgangssætning, mens kræv IPsec for HTTPS er en beskyttelsessætning, og de to fører til forskellig konfiguration.

Adgangsbegrænsning og beskyttelseskrav går hver sin vej

En adgangsbegrænsning siger, hvad der må bruge grænsefladen, og den håndhæves ved at tillade et sæt og afvise alt andet. Et beskyttelseskrav siger, hvilke flows der skal krypteres og godkendes, og det håndhæves ved at forhandle sikkerhedsassociationer, der matcher dem. Det første giver en blokeret anmodning, når noget ikke er på listen, mens det andet giver en forbindelse, der enten bærer den krævede beskyttelse eller ikke oprettes. At behandle det ene som det andet er, hvordan en politik ender med ikke at blokere noget eller ikke at beskytte noget.

Den praktiske konsekvens er, at en filterliste er et lukket sæt. Når der findes en liste på profilen, afvises trafik over den grænseflade, der ikke matcher nogen post, så DNS, godkendelsesudvekslinger og enhver afhængighed, applikationen har brug for, kræver deres egne poster. At tilføje én bred regel for at dæmpe afvisningerne åbner hele grænsefladen igen og annullerer begrænsningen i stilhed. Listen skal være så kort, som kravet tillader, og så komplet, som applikationen kræver.

Byg filterlisten som et komplet sæt

VPNv2-profiler bærer filterlisten adskilt fra rutelisten, og dens poster er profilegenskaber frem for kommandoer. Til HTTPS-eksemplet skal posten bruge protokol 6, fjernadressen og fjernporten, udrullet via administrationskanalen eller ProfileXML til den anvendte profiltype. Microsofts definition af VPNv2-trafikfilter angiver, at betingelser inden for én regel kombineres, mens separate regelidentifikatorer fungerer 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

Portværdierne på den liste beskriver tjenesteporten i den fjerne ende, og den lokale port bør forblive ubegrænset, så klientens efemere kildeport ikke filtreres ud. At gøre det omvendt giver en regel, der ikke matcher noget, og et puslespil, der tager en eftermiddag.

Skriv ruten og filteret som to separate beslutninger. Ruten beslutter, at denne server nås gennem tunnelen, og filteret beslutter, hvilke tjenester der må bruge den vej.

Bevis begge udfald med to anmodninger

Test det tilladte flow og det afviste flow hver for sig, og læs fejlen i stedet for den manglende side. En afvisning, der kommer hurtigt, er en politikbeslutning, mens en timeout mere sandsynligt er en manglende rute eller en tjeneste, der ikke lytter. Kommandoerne nedenfor kører begge anmodninger og viser de regler, der gælder.

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 hurtig afvisning i SMB-testen med en vellykket HTTPS-test er det udfald, filteret skulle have produceret. En afvisning på begge porte betyder, at listen mangler noget, sessionen har brug for, og en timeout på begge peger på routing frem for filtrering. Hvis de beskyttede flows viser ingen sikkerhedsassociation i IPsec-outputtet, er beskyttelseskravet ikke opfyldt, selv når forbindelsen lykkes. Læs alle fire output sammen, fordi hvert enkelt alene understøtter en anden historie.

Registrer den effektive profil, regelsættet og modpartens politik sammen med resultaterne. Historiske kompatibilitetsnoter om ældre Windows-klienter beskriver ikke, hvad nutidens administrerede profilfunktioner understøtter på en bestemt gateway. Versionsspecifik adfærd hører i registreringen, ikke i antagelsen.