LocalSubnet i en SMB-firewallregel dækker ikke VPN-klienter
En LocalSubnet-tilladelsesregel dækker serverens egne undernet, ikke en routet VPN-pulje. Sammenlign kildeadressen, som serveren ser, før du udvider omfanget.
Kontorcomputere når delingen, VPN-brugere får timeout, og den samme konto virker fra et telefonhotspot. Delingstilladelserne er sjældent forskellen; adressen, der ankommer til fileserveren, er det som regel. En regel begrænset til LocalSubnet tillader serverens egne tilsluttede undernet, og en separat routet VPN-pulje er ikke et af dem. To designs lukker hullet, og de efterlader meget forskellige registreringer.
To designs, ét symptom
Det første design føjer VPN-puljen til reglens betingelse for fjernadresse. Serveren ser derefter hver klients tunneladresse, så dens logfiler kan skelne én fjernbruger fra en anden. Det andet design sender VPN-trafik gennem en gateway, der oversætter den til en LAN-adresse, før serveren ser den. Det genskaber forbindelsen og fjerner forskellen i samme trin.
Tabellen beskriver roller snarere end adresser, og dine egne præfikser afgør, hvilken række der gælder. Udskriv serverens faktiske værdier i stedet for at kopiere et eksempel fra et blogindlæg:
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLengthTabellen er et beslutningsværktøj, ikke en påstand om enhver udrulning. En vært med ekstra netværkskort, et andet site-link eller en anden maske har et andet lokalt sæt.
| 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 |
Microsofts reference til New-NetFirewallRule dokumenterer betingelserne for fjernadresse og nøgleordet LocalSubnet. Læs den, før du beslutter, at nøgleordet betyder alle private adresser, for det gør det ikke.
Sammenlign, hvad serveren faktisk modtager
Læs den gældende regel i stedet for den, nogen husker at have oprettet. Kontroller, at den er aktiveret, at den gælder for den aktive profil, og at dens betingelse for fjernadresse svarer til den kilde, serveren ser. En regel, der kun er aktiveret i domæneprofilen, gør intet, når netværkskortet er skiftet til Offentlig efter en netværksændring.
Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundActionDen første kommando udskriver de adressefiltre, der er knyttet til fildelelstilladelserne, og den anden viser, hvilke profiler der er aktive, og hvordan ikke-matchende indgående trafik behandles. Se også efter en blokeringsregel og en centralt administreret politik. Blokeringsregler har forrang for tilladelsesregler, og en politik, der deaktiverer lokal regelsammenlægning, kan gøre en ny lokal undtagelse virkningsløs.
Det er tilfældet, hvor reglen ser korrekt ud i konsollen og ikke har nogen effekt på trafikken. Kontroller profiltildelingen samtidig, for en bærbar computer, der er kommet på et andet netværk, kan skifte til Offentlig profil, uden at nogen rører firewallen.
Test transporten før login
Adskil tilgængelighed fra godkendelse. En lytter på TCP 445 beviser, at en tjeneste er bundet til porten; det beviser ikke, at en fjernpakke kan nå den. En fuldført TCP-forbindelse siger til gengæld endnu intet om SMB-sessionsopsætning eller delingstilladelser. Test håndtrykket fra begge sider, før du redigerer en regel.
Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel DetailedDen første kommando rapporterer, om et TCP-håndtryk lykkes fra den maskine, du kører den på, og den anden tilføjer den opløste adresse og interfaceoplysninger. Kør den fra VPN-klienten og fra en kontorcomputer, og sammenlign derefter. Ping besvarer ingen af spørgsmålene, fordi ICMP kan være blokeret, mens SMB er åben, eller tilladt, mens firewallen dropper 445.
Hvis håndtrykket kun fejler fra VPN, er kildens omfang den mest sandsynlige årsag. Hvis det lykkes, og delingen stadig afviser dig, gå til diagnosticering af SMB-session og tilladelser i stedet for at redigere firewallregler.
Når source NAT fjerner forskellen
Med oversættelse i stien kan serveren ikke skelne enkelte VPN-klienter efter adresse. Hver fjernbruger ankommer som gatewayen. Enhver autorisation, der afhænger af at skelne dem, skal håndhæves der, hvor deres identiteter stadig er synlige, hvilket normalt betyder VPN-koncentratoren eller en godkendende proxy. Firewallreglen kan tillade trafik; den kan ikke genskabe en forskel, som oversættelsen fjernede.
Når den gatewayadresse er tilladt, registreres hver fjernbruger under én enkelt adresse, så reglen giver hele puljen til enhver, der kan nå gatewayen. Hvis en beslutning pr. bruger betyder noget, så hold de oprindelige adresser synlige eller flyt beslutningen til et lag, der stadig kender brugeren. Ellers arver hver fjernbruger tilladelserne fra den ene adresse, som serveren kan se, og revisionssporet kan ikke længere skelne dem. Det er en designbeslutning, ikke en firewalldetalje.
Vælg bevidst mellem de to designs. Begræns reglen til den rigtige VPN-pulje, når serveren skal se, hvem der har forbundet, og accepter kun den oversatte vej, når serveren virkelig ikke har brug for den information. Notér det valgte kildeområde ved siden af reglen, for den næste person, der fejlfinder dette, vil først se på adressetabellen.