Erreur 720 VPN Windows : pool d'adresses ou liaison client ?
L'erreur 720 signifie que la connexion n'a jamais reçu d'adresse utilisable. Séparez les défaillances sur un seul hôte de celles sur de nombreux hôtes avant de réinstaller un adaptateur.
L'erreur 720 apparaît après l'acceptation des identifiants, et c'est pourquoi elle renvoie les gens vers le champ du mot de passe. La connexion a atteint le point où une adresse se négocie et n'en a pas obtenu. Deux défaillances très différentes produisent cette même boîte de dialogue : le serveur n'avait rien à distribuer, ou ce client précis n'a pas pu terminer la négociation. Séparer ces deux cas avant de toucher à quoi que ce soit constitue l'essentiel de la réparation, et la distinction est documentée sur la page de dépannage de Microsoft consacrée à l'erreur 720.
Ce que la boîte de dialogue omet
Le message décrit une défaillance de la négociation PPP, et il est volontairement vague car le client ne peut pas voir pourquoi le serveur a refusé. Ce n'est pas une erreur d'identifiants, et ce n'est pas une affirmation sur le chiffrement du tunnel. Cela signifie que l'adresse ou les paramètres de négociation n'ont pas été livrés.
Côté serveur, la cause habituelle est l'allocation : un pool statique RRAS sans adresses libres, ou une configuration DHCP dont l'étendue est épuisée ou inaccessible, produit exactement ce symptôme chez chaque client qui essaie. Côté client, la cause habituelle est une liaison. Le WAN Miniport qui transporte PPP doit être lié aux bons composants, et une liaison désactivée ou un filtre réseau inséré peut arrêter la négociation sans aucun problème d'appareil visible. Les deux familles demandent des preuves différentes, et le moyen le plus rapide de choisir entre elles est de compter combien de clients sont touchés.
Séparez la population avant le pool
Comptez les clients touchés avant de lire une quelconque configuration. Une défaillance qui frappe tout le monde à la fois est une condition serveur, et une défaillance qui suit une machine d'un réseau à l'autre est une condition client. Ce décompte coûte un message dans un canal de discussion et fait gagner un après-midi.
| Artifact | How you get it | What it rules out | What it cannot rule out |
|---|---|---|---|
| Affected-client count | One message to the people who failed, or a search of today's tickets | A client-only fault, when every client failed within minutes | Which server-side component stopped allocating |
| RRAS event for one attempt | Get-WinEvent on the System log, filtered to the allocation event id | An allocation failure, when no event matches that attempt | A binding fault that appears later in the same negotiation |
| Hidden WAN Miniport bindings | Get-NetAdapter with hidden adapters, then the binding list on the returned name | A disabled ms_wanarp binding or an inserted filter on this client | Pool exhaustion that would also have hit other clients |
| Free-address count | The RRAS pool view, or the DHCP scope statistics | A committed static range or an exhausted scope | Why the address was not delivered to one specific client |
Corrélez ensuite une tentative échouée avec le propre journal du serveur, car RRAS consigne un événement lorsqu'il ne peut pas allouer et cet événement nomme la défaillance plutôt que le symptôme. Si la défaillance suit un client précis, le journal du serveur n'affichera rien pour cette tentative, ce qui est en soi instructif. L'absence d'erreur d'allocation réduit le problème à la négociation de ce client et vous indique quelles commandes lancer ensuite.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }Lisez l'état d'allocation du serveur
Côté RRAS, vérifiez quelle méthode d'allocation est réellement configurée et non celle que la documentation suppose. Un pool statique et une configuration relayée par DHCP échouent de manières différentes, et le correctif appartient à celle qui est utilisée. Pour un pool statique, comptez les adresses libres et cherchez des attributions par utilisateur qui détiennent un bail que personne ne se souvient d'avoir accordé, car un pool qui semble grand peut être entièrement engagé. Pour DHCP, vérifiez que le relais atteint un serveur et que l'étendue dispose de baux libres.
Une étendue épuisée par des clients ordinaires produit le même 720 qu'un pool mal configuré, et la console RRAS semblera parfaitement saine dans les deux cas. Résistez au contournement hérité consistant à découper un pool en plages plus petites : le conseil d'origine décrivait le résultat d'un administrateur, et il ne répare pas une défaillance d'allocation que les propres événements du serveur peuvent nommer directement.
Lisez les liaisons du client sans les casser
Si les preuves désignent un client, inspectez l'adaptateur masqué au lieu de réinstaller la pile. La première commande liste les interfaces WAN Miniport et leurs noms ; la seconde reprend le nom qu'elle a renvoyé, pas un nom copié dans un guide.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsLisez la liste pour la liaison de résolution d'adresses et pour les filtres tiers. Une liaison désactivée est une réparation ciblée, tandis que la présence d'un filtre est une question pour le propriétaire de ce logiciel et non une autorisation de désactiver un produit de sécurité. Supprimer tous les adaptateurs est le seul geste qui détruit les preuves dont vous auriez besoin si la défaillance revenait.
Après la correction, réessayez le même profil puis répétez le cas à deux clients si c'était le symptôme d'origine, car une première connexion réussie masque le problème d'allocation qu'un second client révèle. Tenez la note en quatre champs : quel client, quelle liaison, quel événement et ce qui a changé. Changez aussi une couche par tentative, car un correctif client et une modification de pool appliqués ensemble ne peuvent pas être attribués, et la prochaine défaillance paraîtra nouvelle alors qu'elle est la même.