LocalSubnet i en SMB-brandväggsregel täcker inte VPN-klienter
En tillåtelseregel med LocalSubnet täcker serverns egna subnät, inte en routad VPN-pool. Jämför källadressen som servern ser innan du utökar omfånget.
Kontorsskrivbord når utdelningen, VPN-användare får tidsgräns och samma konto fungerar från en mobil hotspot. Utdelningens behörigheter är sällan skillnaden; adressen som når filservern är det oftast. En regel begränsad till LocalSubnet släpper in serverns egna anslutna subnät, och en separat routad VPN-pool är inte ett av dem. Två konstruktioner stänger gapet, och de lämnar mycket olika loggar efter sig.
Två konstruktioner, ett symptom
Den första konstruktionen lägger till VPN-poolen i regelns villkor för fjärradress. Servern ser då varje klients tunneladress, så dess loggar kan skilja en fjärranvändare från en annan. Den andra konstruktionen routar VPN-trafik genom en gateway som översätter den till en LAN-adress innan servern ser den. Det återställer anslutningen och tar bort distinktionen i samma steg.
Tabellen beskriver roller och inte adresser, och dina egna prefix avgör vilken rad som gäller. Skriv ut serverns verkliga värden i stället för att kopiera ett exempel från ett blogginlägg:
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLengthTabellen är ett beslutsstöd, inte ett påstående om varje driftsättning. En värd med extra gränssnitt, en andra platslänk eller en annan mask har en annan lokal mängd.
| 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 referens för New-NetFirewallRule dokumenterar villkoren för fjärradress och nyckelordet LocalSubnet. Läs den innan du bestämmer att nyckelordet betyder alla privata adresser, för det gör det inte.
Jämför vad servern faktiskt tar emot
Läs den effektiva regeln i stället för den som någon minns att de skapade. Kontrollera att den är aktiverad, gäller den aktiva profilen och att villkoret för fjärradress stämmer med källan som servern ser. En regel som bara är aktiverad på Domain-profilen gör ingenting när adaptern har flyttats till Public efter en nätverksändring.
Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundActionDet första kommandot skriver ut adressfiltren som är kopplade till filutdelningsreglerna, och det andra visar vilka profiler som är aktiva och hur inkommande trafik som inte matchar behandlas. Leta också efter en blockeringsregel och en centralt hanterad policy. Blockeringsregler går före tillåtelseregler, och en policy som stänger av sammanslagning av lokala regler kan göra ett nytt lokalt undantag verkningslöst.
Det är fallet där regeln ser korrekt ut i konsolen och inte har någon effekt på trafiken. Kontrollera profiltilldelningen samtidigt, för en bärbar dator som har anslutit till ett annat nätverk kan flytta till Public-profilen utan att någon rör brandväggen.
Testa transporten före inloggningen
Separera nåbarhet från autentisering. En lyssnare på TCP 445 bevisar att en tjänst är bunden till porten; det bevisar inte att ett fjärrpaket kan nå den. En slutförd TCP-anslutning säger i sin tur ännu ingenting om upprättandet av SMB-sessionen eller utdelningens behörigheter. Testa handskakningen från båda sidor innan du redigerar en regel.
Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel DetailedDet första kommandot rapporterar om en TCP-handskakning lyckas från maskinen du kör det på, och det andra lägger till den uppslagna adressen och gränssnittsdetaljer. Kör det från VPN-klienten och från ett kontorsskrivbord och jämför sedan. Ping svarar inte på någon av frågorna, eftersom ICMP kan vara blockerat medan SMB är öppet, eller tillåtet medan brandväggen släpper 445.
Om handskakningen misslyckas bara från VPN är källomfånget huvudmisstänkt. Om den lyckas och utdelningen fortfarande nekar dig, gå vidare till diagnos av SMB-session och behörigheter i stället för att redigera brandväggsregler.
När käll-NAT tar bort distinktionen
Med översättning i vägen kan servern inte skilja enskilda VPN-klienter åt efter adress. Varje fjärranvändare kommer in som gatewayen. Varje auktorisering som beror på att skilja dem åt måste tillämpas där deras identiteter fortfarande är synliga, vilket oftast betyder VPN-koncentratorn eller en autentiserande proxy. Brandväggsregeln kan släppa in trafik; den kan inte återställa en distinktion som översättningen tog bort.
När den gatewayadressen är tillåten registreras varje fjärranvändare under en enda adress, så regeln ger hela poolen till alla som kan nå gatewayen. Om ett beslut per användare spelar roll, håll de ursprungliga adresserna synliga eller flytta beslutet till ett lager som fortfarande känner till användaren. Annars ärver varje fjärranvändare behörigheterna för den enda adress som servern kan se, och granskningsspåret kan inte längre skilja dem åt. Det är ett designbeslut, inte en brandväggsdetalj.
Välj medvetet mellan de två konstruktionerna. Begränsa regeln till den verkliga VPN-poolen när servern måste se vem som anslöt, och acceptera den översatta vägen bara när servern verkligen inte behöver den informationen. Anteckna det valda källområdet bredvid regeln, för nästa person som felsöker detta kommer att titta på adresstabellen först.