VPN-trafika filtrilo aŭ IPsec-regulo: kie Windows devigas pordon

Itinero vidas celon, ne servon. Decidu, ĉu vi bezonas alirfiltrilon en la VPN-profilo aŭ IPsec-regulon, kiu postulas protekton por la fluo.

Unu Windows-VPN-uzanto devus atingi HTTPS sur servilo kaj ne SMB sur la sama servilo, kaj itinero ne povas esprimi tion. Ambaŭ petoj portas la saman celadreson, do la prefikso, kiu sendas trafikon en la tunelon, ankaŭ portas la fluon, kiun vi volis ekskludi. Ilia apartigo postulas regulon, kiu ekzamenas ion pli subtilan ol la celo.

Du malsamaj intencoj estas konstruitaj per du malsamaj Windows-mekanismoj. Ilia miksado produktas politikon, kiu aspektas kompleta dum ĝi devigas duonon de tio, kion vi intencis.

Itinero ne povas apartigi du servojn ĉe unu adreso

Denaska VPN-enkursigado bazas sin sur prefiksoj: ĝi decidas, kiuj celoj vojaĝas tra la tunelo kaj kiuj restas ekstere. Tio estas la ĝusta ilo por teni unu subreton interne kaj alian ekstere, kaj ĝi estas blinda al pordoj laŭ sia konstruo. Trafika filtrilo en la VPN-profilo aldonas duan dimension: ĝi kongruigas protokolon, foran adreson kaj foran pordon por tio, kio rajtas transiri tiun interfacon. IPsec-regulo laboras en tria loko kaj esprimas, kiuj fluoj postulas protekton kaj kun kiu ili aŭtentikiĝas. La tri respondas al malsamaj demandoj kaj neniu anstataŭas la aliajn.

Komencu per skribo de la intencita frazo. Permesi nur HTTPS estas alirfrazo, dum postuli IPsec por HTTPS estas protekta frazo, kaj ambaŭ kondukas al malsama agordo.

Alirlimigo kaj protekta postulo malkongruas

Alirlimigo diras, kio rajtas uzi la interfacon, kaj ĝi estas devigata per permeso de aro kaj rifuzo de ĉio alia. Protekta postulo diras, kiuj fluoj devas esti ĉifritaj kaj aŭtentikigitaj, kaj ĝi estas devigata per traktado de sekurecaj asocioj, kiuj kongruas kun ili. La unua produktas blokitan peton, kiam io ne estas en la listo, dum la dua produktas konekton, kiu aŭ portas la postulatan protekton aŭ ne establiĝas. Trakti unu kiel la alian estas kiel politiko finiĝas per blokado de nenio aŭ protektado de nenio.

La praktika sekvo estas, ke filtrila listo estas fermita aro. Post kiam listo ekzistas en la profilo, trafiko tra tiu interfaco, kiu kongruas kun neniu ero, estas rifuzata, do DNS, aŭtentikigaj interŝanĝoj kaj ĉiu dependaĵo, kiun la aplikaĵo bezonas, postulas proprajn erojn. Aldoni unu larĝan regulon por silentigi la rifuzojn remalfermas la tutan interfacon kaj kviete nuligas la limigon. La listo devus esti tiel mallonga, kiel la postulo permesas, kaj tiel kompleta, kiel la aplikaĵo postulas.

Konstruu la filtrilan liston kiel kompletan aron

VPNv2-profiloj portas la filtrilan liston aparte de la itinera listo, kaj ĝiaj eroj estas profilaj propraĵoj anstataŭ komandoj. Por la HTTPS-ekzemplo la ero bezonas protokolon 6, la foran adreson kaj la foran pordon, deplojitajn per la administra kanalo aŭ ProfileXML por la uzata profiltipo. La difino de VPNv2-trafika filtrilo de Microsoft asertas, ke kondiĉoj ene de unu regulo kombiniĝas, dum apartaj regul-identigiloj agas kiel alternativoj.

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

Pordaj valoroj en tiu listo priskribas la servan pordon ĉe la fora fino, kaj la loka pordo devus resti nelimigita, por ke la efemera fontpordo de la kliento ne estu filtrita. Fari tion malrekte produktas regulon, kiu kongruas kun nenio, kaj enigmon, kiu konsumas posttagmezon.

Skribu la itineron kaj la filtrilon kiel du apartajn decidojn. La itinero decidas, ke ĉi tiu servilo estas atingata tra la tunelo, kaj la filtrilo decidas, kiuj servoj rajtas uzi tiun vojon.

Pruvu ambaŭ rezultojn per du petoj

Testu la permesitan fluon kaj la rifuzitan fluon aparte, kaj legu la malsukceson anstataŭ la mankan paĝon. Rifuzo, kiu alvenas rapide, estas politika decido, dum tempolimo pli probable estas manka itinero aŭ servo, kiu ne aŭskultas. La subaj komandoj rulas ambaŭ petojn kaj montras la validajn regulojn.

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

Rapida rifuzo en la SMB-testo kun sukcesa HTTPS-testo estas la rezulto, kiun la filtrilo devis produkti. Rifuzo ĉe ambaŭ pordoj signifas, ke la listo mankas ion, kion la seanco bezonas, kaj tempolimo ĉe ambaŭ indikas enkursigadon anstataŭ filtradon. Se la protektitaj fluoj montras neniun sekurecan asocion en la IPsec-eligo, la protekta postulo ne estas plenumita eĉ kiam la konekto sukcesas. Legu ĉiujn kvar elirojn kune, ĉar ĉiu sola subtenas alian rakonton.

Registru la efektivan profilon, la regulan aron kaj la politikon de la kunulo apud la rezultoj. Historiaj kongruecaj notoj pri pli malnovaj Windows-klientoj ne priskribas, kion la hodiaŭaj administrataj profilaj funkcioj subtenas ĉe aparta pordego. Versio-specifa konduto apartenas al la registro, ne al la supozo.

Rilataj artikoloj