VPN-verkeersfilter of IPsec-regel: waar Windows een poort afdwingt

Een route ziet een bestemming, niet een dienst. Bepaal of u een toegangsfilter op het VPN-profiel nodig hebt of een IPsec-regel die bescherming voor de stroom eist.

Eén Windows VPN-gebruiker moet HTTPS op een server bereiken en niet SMB op dezelfde server, en een route kan dat niet uitdrukken. Beide verzoeken dragen hetzelfde bestemmingsadres, dus het prefix dat verkeer de tunnel in stuurt draagt ook de stroom die u wilde uitsluiten. Ze scheiden vereist een regel die iets fijners dan de bestemming onderzoekt.

Twee verschillende bedoelingen worden met twee verschillende Windows-mechanismen gebouwd. Ze mengen levert een beleid op dat compleet lijkt terwijl het de helft handhaaft van wat u bedoelde.

Een route kan twee diensten op één adres niet scheiden

Native VPN-routering is prefixgebaseerd: het bepaalt welke bestemmingen door de tunnel gaan en welke buiten blijven. Dat is het juiste gereedschap om het ene subnet binnen en het andere buiten te houden, en het is naar zijn aard blind voor poorten. Een verkeersfilter op het VPN-profiel voegt een tweede dimensie toe: het koppelt protocol, extern adres en externe poort aan wat dat interface mag passeren. Een IPsec-regel werkt op een derde plek en drukt uit welke stromen bescherming eisen en met wie ze zich authenticeren. De drie beantwoorden verschillende vragen en geen enkele vervangt de andere.

Begin met het opschrijven van de bedoelde zin. Alleen HTTPS toestaan is een toegangszin, terwijl IPsec voor HTTPS eisen een beschermingszin is, en de twee leiden tot een andere configuratie.

Toegangsbeperking en beschermingseis lopen uiteen

Een toegangsbeperking zegt wat het interface mag gebruiken, en wordt afgedwongen door een verzameling toe te staan en al het andere te weigeren. Een beschermingseis zegt welke stromen versleuteld en geauthenticeerd moeten worden, en wordt afgedwongen door beveiligingsassociaties te onderhandelen die erbij passen. De eerste levert een geblokkeerd verzoek op wanneer iets niet op de lijst staat, terwijl de tweede een verbinding oplevert die ofwel de vereiste bescherming draagt of niet tot stand komt. Het ene als het andere behandelen is hoe een beleid uiteindelijk niets blokkeert of niets beschermt.

De praktische consequentie is dat een filterlijst een gesloten verzameling is. Zodra er een lijst op het profiel staat, wordt verkeer over dat interface dat geen enkele vermelding raakt geweigerd, dus DNS, authenticatie-uitwisselingen en elke afhankelijkheid die de toepassing nodig heeft, vereisen hun eigen vermeldingen. Eén brede regel toevoegen om de weigeringen te dempen heropent het hele interface en trekt de beperking stilletjes in. De lijst moet zo kort zijn als de eis toestaat en zo compleet als de toepassing verlangt.

Bouw de filterlijst als een complete verzameling

VPNv2-profielen dragen de filterlijst los van de routelijst, en de vermeldingen zijn profieleigenschappen in plaats van opdrachten. Voor het HTTPS-voorbeeld heeft de vermelding protocol 6, het externe adres en de externe poort nodig, uitgerold via het beheerkanaal of ProfileXML voor het gebruikte profieltype. Microsofts definitie van het VPNv2-verkeersfilter stelt dat voorwaarden binnen één regel worden gecombineerd terwijl afzonderlijke regelidentificaties als alternatieven werken.

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

Poortwaarden in die lijst beschrijven de dienstpoort aan de verre kant, en de lokale poort moet onbeperkt blijven zodat de efemere bronpoort van de client niet wordt uitgefilterd. Het omgekeerd doen levert een regel op die nergens op past en een puzzel die een middag kost.

Schrijf de route en het filter als twee aparte beslissingen. De route bepaalt dat deze server via de tunnel wordt bereikt, en het filter bepaalt welke diensten dat pad mogen gebruiken.

Bewijs beide uitkomsten met twee verzoeken

Test de toegestane stroom en de geweigerde stroom apart, en lees de fout in plaats van de ontbrekende pagina. Een weigering die snel komt is een beleidsbeslissing, terwijl een time-out waarschijnlijker een ontbrekende route of een dienst is die niet luistert. De opdrachten hieronder voeren beide verzoeken uit en tonen de geldende regels.

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

Een snelle weigering bij de SMB-test met een geslaagde HTTPS-test is de uitkomst die het filter had moeten opleveren. Een weigering op beide poorten betekent dat de lijst iets mist wat de sessie nodig heeft, en een time-out op beide wijst op routering in plaats van filtering. Als de beschermde stromen geen beveiligingsassociatie in de IPsec-uitvoer tonen, is aan de beschermingseis niet voldaan ook al slaagt de verbinding. Lees alle vier uitvoer samen, want elk afzonderlijk ondersteunt een ander verhaal.

Leg het effectieve profiel, de regelset en het beleid van de tegenpartij samen met de resultaten vast. Historische compatibiliteitsnotities over oudere Windows-clients beschrijven niet wat de huidige beheerde profielfuncties op een bepaalde gateway ondersteunen. Versieafhankelijk gedrag hoort in het verslag, niet in de aanname.

Gerelateerde artikelen