LocalSubnet en SMB-fajroŝirma regulo ne kovros VPN-klientojn
Permesa regulo LocalSubnet kovras la proprajn subretojn de la servilo, ne enkursigitan VPN-arojn. Komparu la fontadreson, kiun la servilo vidas, antaŭ ol vastigi la amplekson.
Oficejaj labortabloj atingas la kunhavigon, VPN-uzantoj tempas el, kaj la sama konto funkcias el poŝtelefona konekta punkto. La kunhavigaj permesoj malofte estas la diferenco; la adreso, kiu alvenas al la dosier-servilo, kutime estas. Regulo limigita al LocalSubnet permesas la proprajn alkroĉitajn subretojn de la servilo, kaj aparte enkursigita VPN-aro ne estas unu el ili. Du dezajnoj fermas la breĉon, kaj ili lasas tre malsamajn registraĵojn.
Du dezajnoj, unu simptomo
La unua dezajno aldonas la VPN-aron al la kondiĉo pri fora adreso de la regulo. La servilo tiam vidas la tunelan adreson de ĉiu kliento, do ĝiaj protokoloj povas distingi unu foran uzanton de alia. La dua dezajno enkursigas VPN-trafikon tra pordego, kiu tradukas ĝin al LAN-adreso antaŭ ol la servilo vidas ĝin. Tio restarigas la konekteblecon kaj forigas la distingon en la sama paŝo.
La tabelo priskribas rolojn anstataŭ adresojn, kaj viaj propraj prefiksoj decidas, kiu vico validas. Presu la realajn valorojn de la servilo anstataŭ kopii ekzemplon el bloga afiŝo:
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLengthLa tabelo estas decidhelpilo, ne aserto pri ĉiu deplojo. Gastiganto kun pliaj interfacoj, dua ligejo aŭ malsama masko havas malsaman lokan aron.
| Path the packet takes | Address the server records | Filter scope that admits it | What the log can still tell you |
|---|---|---|---|
| Desktop on the server LAN | Its own LAN address | LocalSubnet or the LAN prefix | Which workstation connected |
| Client on the routed VPN pool | Its tunnel address | The VPN pool as a remote address | Which VPN account connected, if the pool is logged |
| Client behind source NAT at the gateway | The gateway's LAN address | The gateway address | Only that some VPN user connected |
| Site-to-site gateway | The remote gateway's tunnel address | The remote site's prefix | Which site connected, not which user |
La referenco pri New-NetFirewallRule de Microsoft dokumentas la kondiĉojn pri fora adreso kaj la ŝlosilvorton LocalSubnet. Legu ĝin antaŭ ol decidi, ke la ŝlosilvorto signifas ĉiujn privatajn adresojn, ĉar ĝi ne signifas.
Komparu, kion la servilo efektive ricevas
Legu la validan regulon anstataŭ tiun, kiun iu memoras esti kreinta. Kontrolu, ke ĝi estas ŝaltita, ke ĝi aplikiĝas al la aktiva profilo, kaj ke ĝia kondiĉo pri fora adreso kongruas kun la fonto, kiun la servilo vidas. Regulo ŝaltita nur en la profilo Domajno faras nenion, kiam la adaptilo glitis al Publika post retŝanĝo.
Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundActionLa unua komando presas la adresfiltrilojn ligitajn al la dosierkunhavigaj reguloj, kaj la dua montras, kiuj profiloj estas aktivaj kaj kiel oni traktas neegalan envenan trafikon. Serĉu ankaŭ blokan regulon kaj centre administritan politikon. Blokaj reguloj havas prioritaton super permesaj reguloj, kaj politiko, kiu malŝaltas lokan regulkunfandadon, povas igi novan lokan escepton senefika.
Tio estas la kazo, kiam la regulo aspektas ĝusta en la konzolo kaj havas neniun efikon al trafiko. Kontrolu la profilatribuon samtempe, ĉar tekkomputilo, kiu aliĝis al alia reto, povas transiri al la Publika profilo sen ke iu ajn tuŝu la fajroŝirmilon.
Testu la transporton antaŭ la ensaluto
Apartigu atingeblon de aŭtentigo. Aŭskultanto sur TCP 445 pruvas, ke servo estas ligita al la pordo; ĝi ne pruvas, ke fora pakaĵo povas atingi ĝin. Kompletigita TCP-konekto siavice ankoraŭ diras nenion pri la starigo de SMB-sesio aŭ la kunhavigaj permesoj. Testu la manpremon de ambaŭ flankoj antaŭ ol redakti regulon.
Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel DetailedLa unua komando raportas, ĉu TCP-manpremo sukcesas el la maŝino, sur kiu vi ĝin rulas, kaj la dua aldonas la solvitan adreson kaj interfacajn detalojn. Rulu ĝin el la VPN-kliento kaj el oficeja labortablo, poste komparu. Ping respondas al neniu el la du demandoj, ĉar ICMP eble estas blokita dum SMB estas malfermita, aŭ permesita dum la fajroŝirmilo forĵetas 445.
Se la manpremo malsukcesas nur el la VPN, la fontamplekso estas la ĉefa suspektato. Se ĝi sukcesas kaj la kunhavigo ankoraŭ rifuzas vin, transiru al diagnozo de SMB-sesio kaj permesoj anstataŭ redakti fajroŝirmajn regulojn.
Kiam fonta NAT forigas la distingon
Kun traduko sur la vojo, la servilo ne povas distingi individuajn VPN-klientojn per adreso. Ĉiu fora uzanto alvenas kiel la pordego. Ajna rajtigo, kiu dependas de ilia distingado, devas esti trudata tie, kie iliaj identecoj ankoraŭ videblas, kio kutime signifas la VPN-koncentrilon aŭ aŭtentigan prokuron. La fajroŝirma regulo povas enlasi trafikon; ĝi ne povas restarigi distingon, kiun la traduko forigis.
Post kiam tiu pordega adreso estas permesita, ĉiu fora uzanto registriĝas sub unu sola adreso, do la regulo donas la tutan aron al iu ajn, kiu povas atingi la pordegon. Se decido por uzanto gravas, tenu la originajn adresojn videblaj aŭ movu la decidon al tavolo, kiu ankoraŭ konas la uzanton. Alie ĉiu fora uzanto heredas la permesojn de la sola adreso, kiun la servilo povas vidi, kaj la revizia spuro ne plu povas ilin distingi. Tio estas dezajna decido, ne fajroŝirma detalo.
Konscie elektu inter la du dezajnoj. Limigu la regulon al la reala VPN-aro, kiam la servilo devas vidi, kiu konektiĝis, kaj akceptu la tradukitan vojon nur kiam la servilo vere ne bezonas tiun informon. Notu la elektitan fontan intervalon apud la regulo, ĉar la sekva persono, kiu sencimigos tion, unue rigardos la adresan tabelon.