LocalSubnet in een SMB-firewallregel dekt geen VPN-clients

Kantoor-desktops bereiken de share, VPN-gebruikers lopen in een time-out, en hetzelfde account werkt vanaf een telefoonhotspot. De share-machtigingen zijn zelden het verschil; het adres dat bij de fileserver aankomt meestal wel. Een regel die beperkt is tot LocalSubnet staat de eigen aangesloten subnetten van de server toe, en een apart gerouteerde VPN-pool is er daar geen van. Twee ontwerpen dichten de kloof, en ze laten heel verschillende sporen achter.

Twee ontwerpen, één symptoom

Het eerste ontwerp voegt de VPN-pool toe aan de voorwaarde voor het externe adres van de regel. De server ziet dan het tunneladres van elke client, zodat zijn logs de ene externe gebruiker van de andere kunnen onderscheiden. Het tweede ontwerp routeert VPN-verkeer via een gateway die het naar een LAN-adres vertaalt voordat de server het ziet. Dat herstelt de verbinding en verwijdert tegelijkertijd het onderscheid.

De tabel beschrijft rollen in plaats van adressen, en je eigen prefixen bepalen welke rij geldt. Druk de echte waarden van de server af in plaats van een voorbeeld uit een blogpost te kopiëren:

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLength

De tabel is een hulpmiddel bij de beslissing, geen bewering over elke implementatie. Een host met extra interfaces, een tweede sitelink of een ander masker heeft een andere lokale set.

De New-NetFirewallRule-referentie van Microsoft documenteert de voorwaarden voor externe adressen en het trefwoord LocalSubnet. Lees die voordat je besluit dat het trefwoord alle privéadressen betekent, want dat doet het niet.

Vergelijk wat de server werkelijk ontvangt

Lees de effectieve regel in plaats van degene die iemand denkt te hebben gemaakt. Controleer dat hij is ingeschakeld, op het actieve profiel van toepassing is, en dat zijn voorwaarde voor het externe adres overeenkomt met de bron die de server ziet. Een regel die alleen op het Domain-profiel is ingeschakeld, doet niets wanneer de adapter na een netwerkwijziging naar Public is verschoven.

Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

De eerste opdracht drukt de adresfilters af die aan de bestanddelingsregels zijn gekoppeld, en de tweede laat zien welke profielen actief zijn en hoe niet-overeenkomend inkomend verkeer wordt behandeld. Zoek ook naar een blokkeringsregel en naar centraal beheerd beleid. Blokkeringsregels gaan voor op toestemmingsregels, en beleid dat het samenvoegen van lokale regels uitschakelt, kan een nieuwe lokale uitzondering zonder effect maken.

Dat is het geval waarin de regel in de console correct lijkt en geen effect heeft op verkeer. Controleer tegelijkertijd de profieltoewijzing, want een laptop die zich bij een ander netwerk heeft aangemeld, kan naar het Public-profiel verschuiven zonder dat iemand de firewall aanraakt.

Test het transport voordat je inlogt

Scheid bereikbaarheid van authenticatie. Een listener op TCP 445 bewijst dat een service aan de poort is gebonden; het bewijst niet dat een extern pakket die kan bereiken. Een voltooide TCP-verbinding zegt op zijn beurt nog niets over het opzetten van een SMB-sessie of over share-machtigingen. Test de handshake van beide kanten voordat je een regel bewerkt.

Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel Detailed

De eerste opdracht meldt of een TCP-handshake slaagt vanaf de machine waarop je hem uitvoert, en de tweede voegt het opgeloste adres en interfacedetails toe. Voer hem uit vanaf de VPN-client en vanaf een kantoordeksktop, en vergelijk dan. Ping beantwoordt geen van beide vragen, omdat ICMP geblokkeerd kan zijn terwijl SMB open is, of toegestaan terwijl de firewall 445 laat vallen.

Als de handshake alleen vanaf de VPN mislukt, is het bronbereik de hoofdverdachte. Als hij slaagt en de share weigert je nog steeds, ga dan naar diagnose van SMB-sessie en machtigingen in plaats van firewallregels te bewerken.

Wanneer bron-NAT het onderscheid wegneemt

Met vertaling in het pad kan de server individuele VPN-clients niet meer op adres onderscheiden. Elke externe gebruiker komt binnen als de gateway. Elke autorisatie die afhangt van het onderscheiden van hen, moet worden afgedwongen waar hun identiteiten nog zichtbaar zijn, wat meestal de VPN-concentrator of een authenticeerende proxy betekent. De firewallregel kan verkeer toelaten; hij kan een onderscheid dat vertaling heeft weggenomen niet herstellen.

Zodra dat gatewayadres is toegestaan, wordt elke externe gebruiker onder één adres geregistreerd, dus de regel verleent de hele pool aan iedereen die de gateway kan bereiken. Als een beslissing per gebruiker belangrijk is, houd de oorspronkelijke adressen dan zichtbaar of verplaats de beslissing naar een laag die de gebruiker nog kent. Anders erft elke externe gebruiker de machtigingen van het ene adres dat de server kan zien, en het auditspoor kan hen daarna niet meer onderscheiden. Dat is een ontwerpbeslissing, geen firewalldetail.

Kies bewust tussen de twee ontwerpen. Beperk de regel tot de echte VPN-pool wanneer de server moet zien wie er verbonden is, en accepteer het vertaalde pad alleen wanneer de server die informatie echt niet nodig heeft. Noteer het gekozen bronbereik naast de regel, want de volgende persoon die dit debugt, kijkt eerst naar de adrestabel.