VPN-verkeersfilter of IPsec-reël: waar Windows ’n poort afdwing

Een Windows-VPN-gebruiker moet HTTPS op ’n bediener bereik en nie SMB op dieselfde bediener nie, en ’n roete kan dit nie uitdruk nie. Albei versoeke dra dieselfde bestemmingsadres, so die voorvoegsel wat verkeer in die tonnel stuur, dra ook die vloei wat jy wou uitsluit. Om hulle te skei vereis ’n reël wat iets fyner as die bestemming ondersoek.

Twee verskillende bedoelings word met twee verskillende Windows-meganismes gebou. Om hulle te meng lewer ’n beleid wat volledig lyk terwyl dit die helfte van wat jy bedoel het, afdwing.

’n Roete kan nie twee dienste by een adres skei nie

Inheemse VPN-roetering is op voorvoegsels gebaseer: dit besluit watter bestemmings deur die tonnel reis en watter buite bly. Dit is die regte instrument om een subnet binne en ’n ander buite te hou, en dit is per konstruksie blind vir poorte. ’n Verkeersfilter op die VPN-profiel voeg ’n tweede dimensie by: dit pas protokol, afgeleë adres en afgeleë poort vir wat daardie koppelvlak mag oorsteek. ’n IPsec-reël werk op ’n derde plek en druk uit watter vloei beskerming vereis en met wie hulle verifieer. Die drie beantwoord verskillende vrae en nie een vervang die ander nie.

Begin deur die bedoelde sin te skryf. Laat slegs HTTPS toe is ’n toegangsin, terwyl vereis IPsec vir HTTPS ’n beskermingsin is, en die twee lei tot verskillende konfigurasie.

Toegangsbeperking en beskermingsvereiste wyk uiteen

’n Toegangsbeperking sê wat die koppelvlak mag gebruik, en dit word afgedwing deur ’n stel toe te laat en alles anders te weier. ’n Beskermingsvereiste sê watter vloei geënkripteer en geauthentiseer moet word, en dit word afgedwing deur sekuriteitsassosiasies te onderhandel wat daarby pas. Die eerste lewer ’n geblokkeerde versoek wanneer iets nie op die lys is nie, terwyl die tweede ’n verbinding lewer wat óf die vereiste beskerming dra óf nie tot stand kom nie. Om een as die ander te behandel, is hoe ’n beleid niks blokkeer of niks beskerm nie.

Die praktiese gevolg is dat ’n filterlys ’n geslote stel is. Sodra ’n lys op die profiel bestaan, word verkeer oor daardie koppelvlak wat geen inskrywing pas nie, geweier, so DNS, verifikasie-uitruilings en enige afhanklikheid wat die toepassing nodig het, vereis hul eie inskrywings. Om een breë reël by te voeg om die weierings stil te maak, heropen die hele koppelvlak en kanselleer die beperking stilweg. Die lys moet so kort wees as wat die vereiste toelaat en so volledig as wat die toepassing eis.

Bou die filterlys as ’n volledige stel

VPNv2-profiele dra die filterlys apart van die roetelys, en sy inskrywings is profieleienskappe eerder as opdragte. Vir die HTTPS-voorbeeld het die inskrywing protokol 6, die afgeleë adres en die afgeleë poort nodig, ontplooi deur die bestuurskanaal of ProfileXML vir die profieltiepe wat gebruik word. Microsoft se definisie van VPNv2-verkeersfilter sê dat voorwaardes binne een reël saamwerk, terwyl aparte reëlidentifiseerders as alternatiewe optree.

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

Poortwaardes in daardie lys beskryf die dienspoort aan die verre kant, en die plaaslike poort moet onbeperk bly sodat die kliënt se efemere bronpoort nie uitgefilter word nie. Om dit omgekeerd te doen, lewer ’n reël wat niks pas nie en ’n raaisel wat ’n middag neem.

Skryf die roete en die filter as twee aparte besluite. Die roete besluit dat hierdie bediener deur die tonnel bereik word, en die filter besluit watter dienste daardie pad mag gebruik.

Bewys albei uitkomste met twee versoeke

Toets die toegelate vloei en die geweierde vloei apart, en lees die mislukking eerder as die ontbrekende bladsy. ’n Weiering wat vinnig aankom, is ’n beleidsbesluit, terwyl ’n tydsverloop waarskynlik ’n ontbrekende roete of ’n diens is wat nie luister nie. Die opdragte hieronder voer albei versoeke uit en wys die reëls wat geld.

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

’n Vinnige verwerping op die SMB-toets met ’n suksesvolle HTTPS-toets is die uitkoms wat die filter veronderstel was om te lewer. ’n Weiering op albei poorte beteken die lys mis iets wat die sessie nodig het, en ’n tydsverloop op albei dui op roetering eerder as filtering. As die beskermde vloei geen sekuriteitsassosiasie in die IPsec-uitset wys, is die beskermingsvereiste nie nagekom nie, selfs wanneer die verbinding slaag. Lees al vier uitsette saam, want elkeen alleen ondersteun ’n ander verhaal.

Teken die effektiewe profiel, die reëlstel en die eweknie se beleid saam met die resultate aan. Historiese versoenbaarheidsnotas oor ouer Windows-kliënte beskryf nie wat vandag se bestuurde profielfunksies op ’n bepaalde poort ondersteun nie. Weergawespesifieke gedrag hoort in die rekord eerder as in die aanname.