GVC bloqué sur Acquiring IP : ce n’est pas un problème de mot de passe

Le Global VPN Client reste bloqué sur Acquiring IP, et le réflexe est de ressaisir le mot de passe ou de réinstaller le client. Ni l’un ni l’autre ne touche à l’étape qui a échoué. L’authentification s’est terminée avant même que le client ne demande une adresse, donc ce ne sont pas les identifiants qui vous retiennent sur cette ligne. Ce qui vous retient là, c’est un échange DHCP qui n’est pas terminé, et il peut bloquer à trois endroits différents.

L’authentification et l’attribution d’adresse sont des étapes distinctes

GVC prouve d’abord qui vous êtes, puis demande les paramètres de son adaptateur virtuel selon la stratégie attribuée à votre connexion. Ce sont des étapes successives avec des signatures d’échec différentes. De mauvais identifiants échouent généralement plus tôt, avec un message d’authentification ou de négociation plutôt qu’avec la ligne d’adresse.

Cet ordre explique pourquoi une réinitialisation du mot de passe, un nouvel utilisateur local ou une réinstallation ne changent rien ici. Le client est déjà autorisé ; il attend maintenant un bail que la passerelle ou son partenaire DHCP doit fournir. Même une stratégie qui autorise l’utilisateur mais n’attribue aucune plage d’adresses produit exactement cet écran.

La première question utile n’est donc pas de savoir si les identifiants sont corrects, mais quelle stratégie a été attribuée et ce que cette stratégie dit sur l’adressage de l’adaptateur virtuel. Lisez la configuration effective de cette connexion plutôt que la capture d’écran qui fonctionne chez un collègue.

D’où vient réellement le bail

Deux modèles sont courants. Le pare-feu peut gérer lui-même une étendue DHCP pour les clients VPN, ou relayer la demande à un serveur DHCP externe du réseau interne. Le modèle détermine quels journaux comptent et qui appeler.

Dans le modèle interne, vérifiez que l’étendue existe toujours, appartient à la bonne interface et dispose de baux libres. Une étendue épuisée produit un client qui s’authentifie parfaitement et ne reçoit jamais d’adresse, et le journal de la passerelle peut ne montrer que la demande. Dans le modèle relais, la cible du relais, la route de retour vers la plage des clients VPN et toute autorisation DHCP interne doivent toutes concorder.

Notez quel modèle votre déploiement utilise avant de tester quoi que ce soit. La moitié des conseils contradictoires en ligne suppose l’autre.

Un tunnel peut être monté et perdre quand même le bail

Une connexion de contrôle établie prouve que la négociation a fonctionné, pas que les données tunnellisées passent dans les deux sens. L’échange DHCP a besoin d’une demande et d’une réponse pour survivre au chemin de données, et c’est là que vivent les réglages de chiffrement, la stratégie de la zone VPN et les problèmes de MTU.

Le conseil sur la traversée NAT est l’exemple le plus clair de l’importance du contexte. Certains chemins l’exigent activé, d’autres ne fonctionnent qu’avec lui désactivé, et le NAT intermédiaire ainsi que la connexion négociée décident lequel. Le changer à l’aveugle tout en modifiant les réglages du client signifie que vous ne saurez pas quel changement a produit le résultat. Notez le chemin négocié et les preuves avant de modifier l’encapsulation.

Redémarrer le routeur domestique relève de la même catégorie. Il efface parfois le symptôme, mais il n’identifie pas pourquoi le bail a échoué, et le problème revient à la connexion suivante.

Parcourez le chemin du bail dans l’ordre

Partez de l’adaptateur et progressez vers l’extérieur, afin que chaque étape ne puisse échouer que pour une seule raison :

> Get-NetAdapter | Where-Object Name -like "*GVC*"
> ipconfig /all | findstr /i /c:"GVC" /c:"IPv4" /c:"DHCP"
> Test-NetConnection 10.60.0.1 -Port 443

Une adresse comme 169.254.x.x signifie que l’adaptateur existe et n’a reçu aucune réponse du tout, ce qui pointe vers la source du bail ou le chemin de données. Une adresse correcte dans la plage VPN avec des entrées DNS erronées est une autre panne : le bail a fonctionné et la stratégie a fourni des paramètres incomplets. Un adaptateur qui n’apparaît jamais signifie que le client n’est pas allé jusqu’à le créer.

Dès qu’un bail apparaît, testez la ressource réelle au lieu de proclamer la victoire sur la ligne d’adresse. Si l’accès aux fichiers ou à l’intranet échoue encore, conservez le bail réussi comme preuve et passez à la résolution de noms ou à la stratégie, car vous avez laissé la panne d’origine derrière vous.

La note de SonicWall sur l’adaptateur virtuel énumère plusieurs branches distinctes, et ses anciennes captures d’écran ne doivent pas être lues comme la carte actuelle du menu. Utilisez-la pour confirmer l’étape atteinte, non comme une liste de vérification à appliquer en bloc.