VPN-trafikfilter eller IPsec-regel: var Windows verkställer en port

En route ser en destination, inte en tjänst. Avgör om du behöver ett åtkomstfilter på VPN-profilen eller en IPsec-regel som kräver skydd för flödet.

En Windows VPN-användare ska nå HTTPS på en server och inte SMB på samma server, och en route kan inte uttrycka det. Båda förfrågningarna bär samma destinationsadress, så prefixet som skickar trafiken in i tunneln bär också det flöde du ville utesluta. Att skilja dem åt kräver en regel som undersöker något finare än destinationen.

Två olika avsikter byggs med två olika Windows-mekanismer. Att blanda dem ger en policy som ser fullständig ut men bara verkställer hälften av det du menade.

En route kan inte skilja två tjänster på en adress

Inbyggd VPN-routing är prefixbaserad: den avgör vilka destinationer som går genom tunneln och vilka som stannar utanför. Det är rätt verktyg för att hålla ett subnät innanför och ett annat utanför, och den är blind för portar av konstruktion. Ett trafikfilter på VPN-profilen lägger till en andra dimension: det matchar protokoll, fjärradress och fjärrport mot det som får korsa gränssnittet. En IPsec-regel arbetar på en tredje plats och uttrycker vilka flöden som kräver skydd och med vem de autentiserar. De tre svarar på olika frågor och ingen ersätter de andra.

Börja med att skriva den avsedda meningen. Tillåt bara HTTPS är en åtkomstmening, medan kräv IPsec för HTTPS är en skyddsmening, och de två leder till olika konfiguration.

Åtkomstbegränsning och skyddskrav går isär

En åtkomstbegränsning säger vad som får använda gränssnittet, och den verkställs genom att tillåta en mängd och neka allt annat. Ett skyddskrav säger vilka flöden som måste krypteras och autentiseras, och det verkställs genom att förhandla säkerhetsassociationer som matchar dem. Det första ger en blockerad förfrågan när något inte står på listan, medan det andra ger en anslutning som antingen bär det krävda skyddet eller inte upprättas. Att behandla det ena som det andra är hur en policy till slut inte blockerar något eller inte skyddar något.

Den praktiska konsekvensen är att en filterlista är en sluten mängd. När en lista finns på profilen nekas trafik över gränssnittet som inte matchar någon post, så DNS, autentiseringsutbyten och varje beroende som programmet behöver kräver egna poster. Att lägga till en bred regel för att tysta nekandena öppnar hela gränssnittet igen och upphäver begränsningen i tysthet. Listan bör vara så kort som kravet tillåter och så fullständig som programmet kräver.

Bygg filterlistan som en fullständig mängd

VPNv2-profiler bär filterlistan åtskild från routelistan, och posterna är profilegenskaper snarare än kommandon. För HTTPS-exemplet behöver posten protokoll 6, fjärradressen och fjärrporten, distribuerade via hanteringskanalen eller ProfileXML för den profiltyp som används. Microsofts definition av VPNv2-trafikfilter anger att villkor inom en regel kombineras medan separata regelidentifierare fungerar som alternativ.

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ärdena i listan beskriver tjänsteporten i fjärränden, och den lokala porten bör förbli obegränsad så att klientens efemära källport inte filtreras bort. Att göra tvärtom ger en regel som inte matchar något, och ett pussel som tar en eftermiddag.

Skriv routen och filtret som två separata beslut. Routen avgör att denna server nås genom tunneln, och filtret avgör vilka tjänster som får använda den vägen.

Bevisa båda utfallen med två förfrågningar

Testa det tillåtna flödet och det nekade flödet var för sig, och läs felet i stället för den saknade sidan. En nekning som kommer snabbt är ett policybeslut, medan en tidsgräns mer sannolikt är en saknad route eller en tjänst som inte lyssnar. Kommandona nedan kör båda förfrågningarna och visar de regler som gäller.

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 snabb nekning i SMB-testet med ett lyckat HTTPS-test är det utfall filtret skulle producera. Nekning på båda portarna betyder att listan saknar något som sessionen behöver, och tidsgräns på båda pekar på routing snarare än filtrering. Om de skyddade flödena visar ingen säkerhetsassociation i IPsec-utdata är skyddskravet inte uppfyllt ens när anslutningen lyckas. Läs alla fyra utdata tillsammans, eftersom var och en för sig stöder en annan historia.

Registrera den gällande profilen, regeluppsättningen och motpartens policy tillsammans med resultaten. Historiska kompatibilitetsnoteringar om äldre Windows-klienter beskriver inte vad dagens hanterade profilfunktioner stöder på en viss gateway. Versionsspecifikt beteende hör till registreringen, inte till antagandet.

Relaterade artiklar