LocalSubnet dans une règle de pare-feu SMB ne couvrira pas les clients VPN

Les postes de bureau atteignent le partage, les utilisateurs VPN expirent et le même compte fonctionne depuis un point d'accès mobile. Les autorisations de partage sont rarement la différence ; l'adresse qui arrive au serveur de fichiers l'est généralement. Une règle limitée à LocalSubnet autorise les sous-réseaux attachés du serveur lui-même, et un pool VPN routé séparément n'en fait pas partie. Deux conceptions comblent cet écart, et elles laissent des enregistrements très différents.

Deux conceptions, un symptôme

La première conception ajoute le pool VPN à la condition d'adresse distante de la règle. Le serveur voit alors l'adresse de tunnel de chaque client, si bien que ses journaux peuvent distinguer un utilisateur distant d'un autre. La seconde conception achemine le trafic VPN par une passerelle qui le traduit en adresse LAN avant que le serveur ne le voie. Cela rétablit la connectivité et supprime la distinction dans la même étape.

Le tableau décrit des rôles plutôt que des adresses, et vos propres préfixes déterminent quelle ligne s'applique. Imprimez les valeurs réelles du serveur au lieu de copier un exemple trouvé dans un billet de blog :

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

Le tableau est une aide à la décision, pas une affirmation sur chaque déploiement. Un hôte doté d'interfaces supplémentaires, d'une seconde liaison de site ou d'un masque différent a un ensemble local différent.

La référence New-NetFirewallRule de Microsoft documente les conditions d'adresse distante et le mot-clé LocalSubnet. Lisez-la avant de décider que le mot-clé désigne toutes les adresses privées, car ce n'est pas le cas.

Comparez ce que le serveur reçoit réellement

Lisez la règle effective plutôt que celle dont quelqu'un se souvient l'avoir créée. Vérifiez qu'elle est activée, qu'elle s'applique au profil actif et que sa condition d'adresse distante correspond à la source que voit le serveur. Une règle activée uniquement sur le profil Domaine ne fait rien lorsque l'adaptateur est passé en Public après un changement de réseau.

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

La première commande imprime les filtres d'adresse attachés aux règles de partage de fichiers, et la seconde montre quels profils sont actifs et comment le trafic entrant non correspondant est traité. Recherchez aussi une règle de blocage et une stratégie gérée centralement. Les règles de blocage ont priorité sur les règles d'autorisation, et une stratégie qui désactive la fusion des règles locales peut rendre une nouvelle exception locale inopérante.

C'est le cas où la règle paraît correcte dans la console et n'a aucun effet sur le trafic. Vérifiez l'affectation de profil en même temps, car un ordinateur portable qui a rejoint un autre réseau peut passer au profil Public sans que personne ne touche au pare-feu.

Testez le transport avant la connexion

Séparez l'accessibilité de l'authentification. Un écouteur sur TCP 445 prouve qu'un service est lié au port ; il ne prouve pas qu'un paquet distant peut l'atteindre. Une connexion TCP établie, quant à elle, ne dit encore rien de l'établissement de la session SMB ni des autorisations de partage. Testez la poignée de main des deux côtés avant de modifier une règle.

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

La première commande indique si une poignée de main TCP réussit depuis la machine sur laquelle vous l'exécutez, et la seconde ajoute l'adresse résolue et les détails de l'interface. Exécutez-la depuis le client VPN et depuis un poste de bureau, puis comparez. Ping ne répond à aucune des deux questions, car ICMP peut être bloqué alors que SMB est ouvert, ou autorisé alors que le pare-feu rejette 445.

Si la poignée de main échoue uniquement depuis le VPN, la portée source est le principal suspect. Si elle réussit et que le partage vous refuse encore, passez au diagnostic de la session SMB et des autorisations plutôt qu'à la modification des règles de pare-feu.

Quand le NAT source supprime la distinction

Avec une traduction sur le chemin, le serveur ne peut pas distinguer les clients VPN individuels par leur adresse. Chaque utilisateur distant arrive comme la passerelle. Toute autorisation qui dépend de leur distinction doit être appliquée là où leurs identités sont encore visibles, ce qui signifie généralement le concentrateur VPN ou un proxy authentifiant. La règle de pare-feu peut admettre le trafic ; elle ne peut pas rétablir une distinction que la traduction a supprimée.

Une fois cette adresse de passerelle autorisée, chaque utilisateur distant est enregistré sous une seule adresse, si bien que la règle accorde tout le pool à quiconque peut atteindre la passerelle. Si une décision par utilisateur compte, gardez les adresses d'origine visibles ou déplacez la décision vers une couche qui connaît encore l'utilisateur. Sinon, chaque utilisateur distant hérite des autorisations de la seule adresse que le serveur peut voir, et la piste d'audit ne peut plus les distinguer ensuite. C'est une décision de conception, pas un détail de pare-feu.

Choisissez délibérément entre les deux conceptions. Limitez la règle au véritable pool VPN lorsque le serveur doit voir qui s'est connecté, et n'acceptez le chemin traduit que lorsque le serveur n'a vraiment pas besoin de cette information. Notez la plage source choisie à côté de la règle, car la prochaine personne qui déboguer cela consultera d'abord la table des adresses.