Azure point à site se connecte mais aucune ressource privée ne répond
Connecté signifie seulement que le tunnel est monté. Vérifiez ce que la passerelle peut transporter, comparez les espaces d'adressage, puis résolvez un nom et testez le service lui-même.
Connecté est un état du tunnel, pas une affirmation sur l'accessibilité. Un client point à site peut terminer IKE, recevoir une adresse et n'atteindre rien du tout, car la passerelle ne transmet le trafic que pour les réseaux que le VNet connaît déjà. Faites ces cinq vérifications dans l'ordre et arrêtez-vous au premier échec. Sauter des étapes, c'est ainsi qu'un problème DNS est traité comme un problème de pare-feu pendant une heure.
L'ordre compte plus que la liste.
Vérification 1 : décidez ce que le tunnel doit transporter
Azure VPN Gateway termine le tunnel et transmet le trafic qui appartient au VNet ; ce n'estpas une sortie Internet générale. Si les utilisateurs s'attendent à ce que leur navigation sorte par Azure, la conception est fausse avant même qu'un réglage client n'entre en jeu. Activez le split tunneling pour que l'Internet local reste sur le chemin local, et utilisez une instance NAT ou un tunnel site à site lorsqu'une adresse de sortie fixe est réellement nécessaire.
Notez ce que le client doit atteindre avant de tester quoi que ce soit. Sans cette liste, chaque résultat partiel ressemble à un progrès.
Vérification 2 : comparez les espaces d'adressage avant les certificats
Le chevauchement se juge sur les plages les plus larges, donc deux réseaux qui semblent différents au niveau du sous-réseau entrent tout de même en collision si leurs blocs parents se chevauchent. Le sous-réseau de la passerelle doit être dédié et assez grand pour la SKU, et le pool d'adresses client ne doit entrer en collision ni avec le VNet ni avec quoi que ce soit joignable via un peering. Changez le plan et redéployez, car ajouter des routes pour compenser produit un tunnel qui fonctionne pour certaines destinations et inexplicablement pas pour d'autres. Le provisionnement échoue bruyamment ici, ce qui est le bon cas.
L'authentification est la porte suivante. Les profils certificat, RADIUS et Entra ID ne sont pas interchangeables, et le paquet client diffère pour chacun.
Vérification 3 : résolvez un nom privé depuis l'intérieur
Le client conserve son propre résolveur, sauf si le profil téléchargé contient les serveurs DNS du VNet, et cette liste est intégrée au moment du téléchargement. Ajoutez un forwarder dans le VNet, définissez-le comme serveur DNS du VNet, puis téléchargez et importez à nouveau le paquet client. Réutiliser l'ancien paquet ne teste que l'ancienne liste de résolveurs.
Testez d'abord une adresse, car cela sépare le routage du nommage en une seule étape : Test-NetConnection 10.20.1.4 -Port 3389.
Si l'adresse répond et que le nom ne répond pas, interrogez le résolveur directement avec Resolve-DnsName files.corp.example -Server 10.20.0.4. Si les deux échouent, la panne n'est pas DNS et vous devriez cesser de modifier les paramètres DNS. Le DNS de la plateforme Azure à 168.63.129.16 ne répond que depuis l'intérieur du VNet, donc un client extérieur ne peut pas utiliser cette adresse comme résolveur.
Vérification 4 : testez le service derrière le tunnel
Un tunnel sain et un port fermé sont identiques du point de vue du client. Vérifiez le pare-feu de l'invité, puis le groupe de sécurité réseau du sous-réseau ou de la carte réseau, puis si le service écoute sur l'adresse privée plutôt que seulement sur loopback. Autorisez le pool client comme source au lieu d'ouvrir une règle vers Internet, et rappelez-vous que SMB vers Azure Files a besoin du chemin du point de terminaison privé routé par le tunnel. Quand une ressource répond par IP mais pas par nom, revenez à la vérification 3 plutôt que de toucher à la passerelle.
Un tableau garde les couches séparées pendant que vous travaillez :
| Symptom | Layer to check |
|---|---|
| Name fails, private IP works | Resolver setting or forwarder |
| Private IP also fails | Address plan, NSG, guest firewall |
| Private works, internet fails | Expected; the gateway is not an egress |
| Connects, then drops | Tunnel type or certificate mismatch |
Vérification 5 : consignez le profil avant d'escalader
Mettez le type de passerelle, le type de tunnel, la méthode d'authentification et le système d'exploitation du client dans le ticket. Un profil IKEv2 avec certificat et un profil RADIUS échouent pour des raisons différentes, et un client conçu pour un autre type de tunnel ne se connecte que lorsque la passerelle propose un protocole compatible.
Pour une petite équipe, la conception durable est un VNet, un forwarder DNS et un client split-tunnel documenté. Si l'exigence est une sortie publique fixe, terminez un tunnel site à site sur un pare-feu que vous contrôlez et y routez le trafic Internet, au lieu de demander à la passerelle point à site quelque chose pour quoi elle n'a jamais été conçue.