Contexte
Une entreprise dispose de deux sites reliés par un VPN site-à-site entre deux firewalls :
- Siège (
192.168.1.0/24) — héberge les serveurs principaux dont un serveur de fichiersFILESRV-SIEGEet un contrôleur de domaineDC-SIEGE - Site distant (
192.168.2.0/24) — dispose de son propre DC localDC-SITEet d’un serveur de fichiers localFILESRV-SITE
Le VPN a été configuré la semaine dernière par l’administrateur réseau pour permettre aux utilisateurs du site distant d’accéder aux ressources du siège, notamment un partage \\FILESRV-SIEGE\commun accessible à tous les collaborateurs de l’entreprise.
Lundi matin, les utilisateurs du site distant remontent qu’ils ne peuvent pas accéder au partage \\FILESRV-SIEGE\commun. En revanche :
- Les ressources locales (
\\FILESRV-SITE\...) fonctionnent parfaitement - Le DC local
DC-SITErépond normalement, les GPO s’appliquent, les utilisateurs peuvent se connecter - Depuis le siège, un administrateur teste l’accès à
\\FILESRV-SITE\...— ça fonctionne sans problème - Le VPN est bien monté, les deux firewalls indiquent le tunnel comme actif
- Depuis le site distant, un
ping 192.168.1.0vers le siège répond correctement
Problème
Les utilisateurs du site distant ne peuvent pas accéder aux partages réseau du siège malgré un tunnel VPN actif. Identifier la cause et rétablir l’accès.
Cause racine : Lors de la configuration du VPN, l’administrateur a créé les règles firewall dans les deux sens mais a oublié d’autoriser le port 445 (SMB) dans le sens site distant → siège. La règle existe dans le sens siège → site distant (ce qui explique que le siège accède aux partages du site sans problème), mais le flux retour n’a pas été ouvert sur le firewall du siège.
Le ping fonctionne car l’ICMP est autorisé dans les deux sens. Le tunnel VPN est bien actif. Seul le trafic SMB entrant au siège depuis le site distant est bloqué.
Diagnostic :
Depuis un poste du site distant :
Test-NetConnection -ComputerName 192.168.1.10 -Port 445→ TcpTestSucceeded : False — le port 445 est bloqué en direction du siège
Test-NetConnection -ComputerName 192.168.1.10 -Port 443→ TcpTestSucceeded : True — d’autres ports passent, confirme que le VPN fonctionne
Depuis un poste du siège vers le site distant :
Test-NetConnection -ComputerName 192.168.2.10 -Port 445→ TcpTestSucceeded : True — le sens inverse fonctionne, confirme l’asymétrie de la règle
Résolution :
Sur le firewall du siège, ajouter une règle autorisant le trafic entrant depuis le réseau du site distant vers le serveur de fichiers :
| Champ | Valeur |
|---|---|
| Source | 192.168.2.0/24 |
| Destination | 192.168.1.10 (FILESRV-SIEGE) |
| Port | 445 (TCP) |
| Action | Allow |
| Interface | VPN / LAN |
Vérification depuis un poste du site distant :
Test-NetConnection -ComputerName 192.168.1.10 -Port 445
# TcpTestSucceeded : True
net use Z: \\FILESRV-SIEGE\commun
# La commande doit aboutir sans erreur
La connectivité site à site à l’air bonne
Je suppose que le serveur DC du site est également le serveur DNS des clients
2 choses :
– Le serveur DC du site ne doit pas connaitre le nom DNS du serveur fichier du site principale FILESRV-SIEGE
– Les flux sur les firewall ne sont pas ouvert pour un accès SMB depuis le site distant vers le serveur de fichier du siège
Mêmes pistes. On manque d’informations : on ne connaît pas la configuration des règles FW dans le tunnel VPN, la résolution DNS n’a pas été testée. On ne connaît pas non plus les autorisations SMB sur le partage du siège (on nous dit que ça a été configuré, pas que ça a été testé). A noter que l’enregistrement DNS du serveur siège sera dans la même zone DNS que les autres serveurs du domaine, donc sauf à une erreur de réplication DNS entre les deux DC, on pourrait l’exclure.