LocalSubnet yn in SMB-firewallregel dekt gjin VPN-klanten
In regel mei LocalSubnet lit de eigen subnetten fan de server ta, net in routere VPN-pool. Fergelykje it boarne-adres dat de server sjocht foardat jo it berik ferbreedzje.
Kantoarburo's berikke de share, VPN-brûkers krije in time-out, en itselde akkount wurket fan in hotspot fan in tillefoan. De dielpermissys binne selden it ferskil; it adres dat by de bestandsserver oankomt meastal wol. In regel dy't beheind is ta LocalSubnet, lit de eigen oanbuorre subnetten fan de server ta, en in apart routere VPN-pool is ien fan dy net. Twa ûntwerpen tichtsje it gat, en se litte hiel ferskillende records efter.
Twa ûntwerpen, ien symptoom
It earste ûntwerp foeget de VPN-pool ta oan 'e remote-adresbetingst fan 'e regel. De server sjocht dan it tunneladres fan elke klant, sadat syn logs ien remote brûker fan in oare skiede kinne. It twadde ûntwerp rûnet VPN-ferkear troch in gateway dy't it nei in LAN-adres fertaalt foardat de server it sjocht. Dat herstelt de ferbining en ferwideret tagelyk it ûnderskied.
De tabel beskriuwt rollen ynstee fan adressen, en jo eigen prefiksen beslute hokker rige jildt. Printsje de echte wearden fan 'e server ynstee fan in foarbyld fan in blogpost te kopiearjen:
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLengthDe tabel is in helpmiddel by de beslissing, gjin bewearing oer elke ynset. In host mei ekstra ynterfaces, in twadde sitelink of in oar masker hat in oare lokale set.
| 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 |
De referinsje foar New-NetFirewallRule fan Microsoft dokumintearret de remote-adresbetingsten en it kaaiwurd LocalSubnet. Lês dy foardat jo beslute dat it kaaiwurd alle partikuliere adressen betsjut, want dat docht it net.
Fergelykje wat de server echt ûntfangt
Lês de effektive regel ynstee fan de regel dy't immen tinkt oanmakke te hawwen. Kontrolearje dat er oan stiet, dat er op it aktive profyl fan tapassing is, en dat syn remote-adresbetingst oerienkomt mei de boarne dy't de server sjocht. In regel dy't allinnich op it Domain-profyl oan stiet, docht neat as de adapter nei in netwurkferoaring nei Public gliden is.
Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundActionIt earste kommando printsje de adresfilters dy't oan 'e bestanddielfregels ferbûn binne, en it twadde lit sjen hokker profylen aktyf binne en hoe't net-matchere ynkommend ferkear behannele wurdt. Sjoch ek nei in blokkearjende regel en nei sintraal beheard belied. Blokregels hawwe foarrang boppe regels dy't tastean, en in belied dat it gearfoegjen fan lokale regels útskeakelet, kin in nije lokale útsûndering ynert meitsje.
Dat is it gefal wêrby't de regel yn 'e konsole korrekt liket en gjin effekt hat op ferkear. Kontrolearje tagelyk de profyltawizing, want in laptop dy't by in oar netwurk kaam is, kin sûnder dat immen de firewall oanrekket nei it Public-profyl ferpleatse.
Test it transport foar de oanmelding
Skied berikberens fan autentikaasje. In listener op TCP 445 bewiist dat in tsjinst oan 'e poarte bûn is; it bewiist net dat in remote pakket dy berikke kin. In foltôge TCP-ferbining seit op syn beurt noch neat oer SMB-sesje-opset of dielpermissys. Test de hânskodding fan beide kanten foardat jo in regel bewurkje.
Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel DetailedIt earste kommando rapportearret oft in TCP-hânskodding slagget fan 'e masine wêrop jo it útfiere, en it twadde foeget it oploste adres en ynterface-details ta. Rin it fan 'e VPN-klant en fan in kantoarburo, en fergelykje dan. Ping beantwurdet gjin fan beide fragen, want ICMP kin blokkearre wêze wylst SMB iepen is, of tastien wylst de firewall 445 lit falle.
As de hânskodding allinnich fan 'e VPN ôf mislearret, is it boarneberik de haadfertinking. As it slagget en de share wegert jo noch, geane jo oer nei diagnoaze fan SMB-sesje en permissys ynstee fan firewallregels te bewurkjen.
Wannear't boarne-NAT it ûnderskied fuorthellet
Mei fertaling yn it paad kin de server yndividuele VPN-klanten net mear by adres skiede. Elke remote brûker komt binnen as de gateway. Elke autorisaasje dy't ôfhinget fan it ûnderskieden fan harren, moat útfierd wurde wêr't harren identiteiten noch sichtber binne, wat meastentiids de VPN-konsintrator of in autentisearjende proxy betsjut. De firewallregel kin ferkear tastean; hy kin in ûnderskied dat fertaling fuorthelle hat, net weromsette.
Sadree't dat gateway-adres tastien is, wurdt elke remote brûker ûnder ien inkeld adres registrearre, dat de regel jout de hiele pool oan elkenien dy't de gateway berikke kin. As in beslissing per brûker wichtich is, hâld dan de orizjinele adressen sichtber of ferpleats de beslissing nei in laach dy't de brûker noch ken. Oars ervet elke remote brûker de permissys fan it iene adres dat de server sjen kin, en it audittrajekt kin se dêrnei net mear skiede. Dat is in ûntwerpbeslissing, gjin detail fan de firewall.
Kies bewust tusken de twa ûntwerpen. Behein de regel ta de echte VPN-pool as de server sjen moat wa't ferbûn is, en akseptearje it fertaalde paad allinnich as de server dy ynformaasje echt net nedich hat. Registrearje it keazen boarneberik njonken de regel, want de folgjende persoan dy't dit debugt, sjocht earst nei de adrestabel.