LocalSubnet in una regola firewall SMB non copre i client VPN

I desktop dell'ufficio raggiungono la condivisione, gli utenti VPN vanno in timeout e lo stesso account funziona da un hotspot del telefono. Le autorizzazioni della condivisione raramente sono la differenza; di solito lo è l'indirizzo che arriva al file server. Una regola limitata a LocalSubnet ammette le sottoreti collegate del server stesso, e un pool VPN instradato separatamente non è una di esse. Due progettazioni colmano il divario, e lasciano dietro registrazioni molto diverse.

Due progettazioni, un sintomo

La prima progettazione aggiunge il pool VPN alla condizione di indirizzo remoto della regola. Il server vede quindi l'indirizzo tunnel di ogni client, così i suoi log possono distinguere un utente remoto da un altro. La seconda progettazione instrada il traffico VPN attraverso un gateway che lo traduce in un indirizzo LAN prima che il server lo veda. Ciò ripristina la connettività e rimuove la distinzione nello stesso passaggio.

La tabella descrive ruoli anziché indirizzi, e sono i tuoi prefissi a decidere quale riga si applica. Stampa i valori reali del server invece di copiare un esempio da un post di blog:

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

La tabella è un ausilio decisionale, non un'affermazione su ogni installazione. Un host con interfacce aggiuntive, un secondo collegamento di sede o una maschera diversa ha un insieme locale diverso.

Il riferimento New-NetFirewallRule di Microsoft documenta le condizioni di indirizzo remoto e la parola chiave LocalSubnet. Leggilo prima di decidere che la parola chiave indichi tutti gli indirizzi privati, perché non è così.

Confronta ciò che il server riceve davvero

Leggi la regola effettiva invece di quella che qualcuno ricorda di aver creato. Verifica che sia abilitata, che si applichi al profilo attivo e che la sua condizione di indirizzo remoto corrisponda alla sorgente che il server vede. Una regola abilitata solo sul profilo Domain non fa nulla quando la scheda è passata a Public dopo un cambio di rete.

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

Il primo comando stampa i filtri di indirizzo associati alle regole di condivisione file, e il secondo mostra quali profili sono attivi e come viene trattato il traffico in ingresso non corrispondente. Cerca anche una regola di blocco e una policy gestita centralmente. Le regole di blocco hanno la precedenza su quelle di autorizzazione, e una policy che disabilita l'unione delle regole locali può rendere inerte una nuova eccezione locale.

È il caso in cui la regola sembra corretta nella console e non ha alcun effetto sul traffico. Controlla contemporaneamente l'assegnazione del profilo, perché un portatile che si è unito a un'altra rete può passare al profilo Public senza che nessuno tocchi il firewall.

Prova il trasporto prima del login

Separa la raggiungibilità dall'autenticazione. Un listener su TCP 445 dimostra che un servizio è associato alla porta; non dimostra che un pacchetto remoto possa raggiungerla. Una connessione TCP completata, a sua volta, non dice ancora nulla sulla configurazione della sessione SMB o sulle autorizzazioni della condivisione. Prova l'handshake da entrambi i lati prima di modificare una regola.

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

Il primo comando indica se un handshake TCP riesce dalla macchina su cui lo esegui, e il secondo aggiunge l'indirizzo risolto e i dettagli dell'interfaccia. Eseguilo dal client VPN e da un desktop dell'ufficio, poi confronta. Ping non risponde a nessuna delle due domande, perché ICMP può essere bloccato mentre SMB è aperto, o consentito mentre il firewall scarta 445.

Se l'handshake fallisce solo dalla VPN, l'ambito sorgente è il principale sospetto. Se riesce e la condivisione ti rifiuta ancora, passa alla diagnosi della sessione e delle autorizzazioni SMB invece di modificare le regole del firewall.

Quando il NAT sorgente elimina la distinzione

Con la traduzione nel percorso, il server non può distinguere i singoli client VPN per indirizzo. Ogni utente remoto arriva come il gateway. Qualsiasi autorizzazione che dipenda dal distinguerli deve essere applicata dove le loro identità sono ancora visibili, il che di solito significa il concentratore VPN o un proxy che autentica. La regola del firewall può ammettere il traffico; non può ripristinare una distinzione che la traduzione ha rimosso.

Una volta consentito quell'indirizzo del gateway, ogni utente remoto viene registrato sotto un unico indirizzo, quindi la regola concede l'intero pool a chiunque possa raggiungere il gateway. Se conta una decisione per utente, mantieni visibili gli indirizzi originali o sposta la decisione a un livello che conosce ancora l'utente. Altrimenti ogni utente remoto eredita le autorizzazioni dell'unico indirizzo che il server può vedere, e la traccia di controllo non può più distinguerli. È una decisione di progettazione, non un dettaglio del firewall.

Scegli deliberatamente tra le due progettazioni. Limita la regola al pool VPN reale quando il server deve vedere chi si è connesso, e accetta il percorso tradotto solo quando il server non ha davvero bisogno di quell'informazione. Annota l'intervallo sorgente scelto accanto alla regola, perché la prossima persona che eseguirà il debug guarderà prima la tabella degli indirizzi.