LocalSubnet v pravilu požarnega zidu SMB ne bo pokril odjemalcev VPN
Pravilo dovoljenja z LocalSubnet pokriva lastne podomrežja strežnika, ne usmerjenega sklada VPN. Primerjajte izvorni naslov, ki ga vidi strežnik, preden razširite obseg.
Namizni računalniki v pisarni dosežejo skupno mapo, uporabnikom VPN poteče čas in isti račun deluje z mobilne dostopne točke. Dovoljenja skupne mape so redko razlika; naslov, ki prispe na strežnik datotek, je običajno razlika. Pravilo, omejeno na LocalSubnet, spusti lastna priključena podomrežja strežnika, ločeno usmerjen sklad VPN pa ni eno od njih. Dve zasnovi zapreta to vrzel in za seboj pustita zelo različne zapise.
Dve zasnovi, en simptom
Prva zasnova doda sklad VPN v pogoj oddaljenega naslova pravila. Strežnik nato vidi naslov tunela vsakega odjemalca, zato lahko njegovi dnevniki ločijo enega oddaljenega uporabnika od drugega. Druga zasnova usmerja promet VPN skozi prehod, ki ga prevede v naslov LAN, preden ga strežnik vidi. To obnovi povezljivost in v istem koraku odstrani razliko.
Tabela opisuje vloge, ne naslovov, in o tem, katera vrstica velja, odločajo vaše predpone. Natisnite dejanske vrednosti strežnika, namesto da kopirate primer iz bloga:
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLengthTabela je pripomoček za odločitev, ne trditev o vsaki namestitvi. Gostitelj z dodatnimi vmesniki, drugo povezavo lokacije ali drugo masko ima drugačen krajevni nabor.
| 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 |
Referenca New-NetFirewallRule podjetja Microsoft dokumentira pogoje oddaljenega naslova in ključno besedo LocalSubnet. Preberite jo, preden se odločite, da ključna beseda pomeni vse zasebne naslove, ker ne.
Primerjajte, kaj strežnik v resnici prejme
Preberite veljavno pravilo, ne tisto, za katero nekdo misli, da jo je ustvaril. Preverite, da je omogočeno, da velja za dejavni profil in da se njegov pogoj oddaljenega naslova ujema z virom, ki ga vidi strežnik. Pravilo, omogočeno samo v profilu Domain, ne naredi ničesar, ko je omrežni vmesnik po spremembi omrežja prešel v Public.
Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundActionPrvi ukaz natisne naslovne filtre, povezane s pravili skupne rabe datotek, drugi pa pokaže, kateri profili so dejavni in kako se obravnava neustrezni dohodni promet. Poiščite tudi pravilo blokiranja in osrednje upravljano politiko. Pravila blokiranja imajo prednost pred pravili dovoljenja, politika, ki izklopi združevanje krajevnih pravil, pa lahko novo krajevno izjemo naredi neučinkovito.
To je primer, ko je pravilo v konzoli videti pravilno in nima nobenega vpliva na promet. Hkrati preverite dodelitev profila, ker lahko prenosnik, ki se je pridružil drugemu omrežju, preide v profil Public, ne da bi se kdo dotaknil požarnega zidu.
Preizkusite prenos pred prijavo
Ločite dosegljivost od preverjanja pristnosti. Poslušalec na TCP 445 dokazuje, da je storitev vezana na vrata; ne dokazuje, da lahko oddaljeni paket doseže ta vrata. Dokončana povezava TCP pa še ne pove ničesar o vzpostavitvi seje SMB ali dovoljenjih skupne rabe. Preden uredite pravilo, preizkusite rokovanje z obeh strani.
Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel DetailedPrvi ukaz sporoči, ali rokovanje TCP uspe s stroja, na katerem ga zaženete, drugi pa doda razrešeni naslov in podrobnosti vmesnika. Zaženite ga z odjemalca VPN in z namiznega računalnika v pisarni, nato primerjajte. Ping ne odgovori na nobeno od obeh vprašanj, ker je ICMP lahko blokiran, medtem ko je SMB odprt, ali dovoljen, medtem ko požarni zid zavrže 445.
Če rokovanje spodleti samo z VPN, je izvorni obseg glavni osumljenec. Če uspe in skupna mapa še vedno zavrača, pojdite na diagnostiko seje in dovoljenj SMB, namesto da bi urejali pravila požarnega zidu.
Ko izvorni NAT odstrani razliko
S prevajanjem na poti strežnik ne more ločiti posameznih odjemalcev VPN po naslovu. Vsak oddaljeni uporabnik prispe kot prehod. Vsaka avtorizacija, ki je odvisna od njihovega ločevanja, mora biti uveljavljena tam, kjer so njihove identitete še vidne, kar običajno pomeni koncentrator VPN ali preverjevalni posrednik. Pravilo požarnega zidu lahko spusti promet; ne more obnoviti razlike, ki jo je prevajanje odstranilo.
Ko je ta naslov prehoda dovoljen, se vsak oddaljeni uporabnik zabeleži pod enim samim naslovom, zato pravilo dodeli celoten sklad vsakomur, ki lahko doseže prehod. Če je odločitev za posameznega uporabnika pomembna, ohranite izvirne naslove vidne ali premaknite odločitev v plast, ki uporabnika še pozna. Sicer vsak oddaljeni uporabnik podeduje dovoljenja enega naslova, ki ga strežnik vidi, in revizijska sled jih pozneje ne more ločiti. To je odločitev o zasnovi, ne podrobnost požarnega zidu.
Zavestno izberite eno od dveh zasnov. Omejite pravilo na pravi sklad VPN, ko mora strežnik videti, kdo se je povezal, in sprejmite prevedeno pot le, ko strežnik te informacije res ne potrebuje. Zabeležite izbrani izvorni obseg ob pravilu, ker bo naslednja oseba, ki bo to razhroščevala, najprej pogledala naslovno tabelo.