Pas d’internet sur un VPN Windows ? Le pool d’adresses est le suspect

Windows affiche le tunnel comme connecté et l’étiquette Pas d’accès à Internet, ce que les gens lisent comme une bizarrerie de Windows. C’est une affirmation sur ce que le client a reçu : aucune passerelle par défaut utilisable, aucun résolveur fonctionnel et aucun chemin de retour pour les adresses à l’intérieur du tunnel. Quand le serveur est une connexion entrante de Windows, un seul réglage explique la plupart de ces rapports. L’étiquette n’est pas un diagnostic, mais elle resserre la recherche sur trois endroits.

Lisez le bail avant de le modifier

Lancez ipconfig /all sur le client et trouvez l’adaptateur VPN parmi les entrées. L’adresse, la passerelle par défaut et le serveur DNS qu’il liste sont les faits dont vous avez besoin, et ils diffèrent souvent de ce que l’administrateur suppose avoir été distribué.

Trois schémas correspondent à trois pannes. Une adresse dans 169.254.0.0/16 signifie que le client n’a rien reçu du tout et s’est attribué une adresse locale de lien. Une adresse plausible sans passerelle signifie que le pool a été servi sans l’option qui donne au client une route par défaut. Un bail complet qui n’atteint toujours rien indique un transfert ou une traduction côté serveur.

Notez les valeurs avant de toucher au serveur. L’étape suivante les compare à la plage que le serveur croit distribuer, et la mémoire est un piètre substitut à un bail.

Pourquoi l’attribution automatique peut laisser sans passerelle

L’entrée Connexions entrantes a ses propres propriétés IPv4, séparées de l’adaptateur physique. La valeur par défaut y propose d’attribuer des adresses automatiquement, ce qui repose sur l’allocateur intégré de la connexion pour fournir une adresse, un masque, une passerelle et DNS.

Sur une station de travail autonome, cet allocateur n’a aucune plage où puiser, sauf si autre chose sur la machine en fournit une, si bien que le client peut se retrouver avec une adresse locale de lien ou avec une adresse mais sans passerelle. La connexion semble établie parce que la liaison est montée, alors que la configuration derrière est incomplète.

C’est pourquoi passer à une plage spécifiée corrige tant de ces rapports. Vous cessez de demander à un service qui ne tourne peut-être pas d’inventer un bail et commencez à énoncer le bail vous-même.

La même confusion apparaît quand quelqu’un s’attend à ce que le serveur DHCP du routeur LAN serve les clients du tunnel. La découverte par diffusion ne traverse pas un tunnel routé, donc ce serveur ne voit jamais la requête. Supposer le contraire est la raison la plus fréquente de blâmer un pool pour un client qui ne lui a jamais rien demandé.

Définissez une plage explicite que le serveur peut router

Choisissez un petit bloc dans un sous-réseau que le serveur peut atteindre, hors de la plage que le routeur LAN distribue et hors de tout autre pool du réseau. Si le serveur est sur 172.20.10.0/24 et le routeur détient 172.20.10.1, un bloc court près du haut de ce sous-réseau, disons de 172.20.10.201 à 172.20.10.209, garde les baux du tunnel à l’écart de la distribution que le routeur gère déjà.

Saisissez-le dans les propriétés IPv4 de la connexion entrante, reconnectez le client et relisez l’adaptateur avant de changer quoi que ce soit d’autre. La seconde lecture est ce qui vous dit si le pool était la panne ou seulement une panne parmi plusieurs.

Ces commandes impriment la configuration obtenue et les routes dont le client dispose maintenant :

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

La passerelle du bail devrait être une adresse que le serveur détient, et la route par défaut du client devrait y pointer. Si le bail est complet mais qu’aucune route n’existe, le serveur a attribué sans pousser de passerelle, et les réglages du pool restent l’endroit où regarder.

Une adresse n’est pas un chemin vers internet

Recevoir un bail ne déplace que des paquets du client vers le serveur. Pour accéder à internet, le serveur doit transférer ces paquets et les traduire vers sa propre liaison montante, et c’est une configuration distincte avec ses propres modes de défaillance.

Le partage de connexion Internet est le raccourci. Il transforme l’adaptateur orienté Internet en passerelle partagée et gère son propre adressage, ce qui peut réécrire l’adresse de cet adaptateur et laisser une règle NAT existante pointer vers une valeur qui n’existe plus. Notez les réglages d’origine avant de l’activer.

L’alternative routée garde l’adressage stable et vous demande de configurer explicitement le transfert et la traduction. Aucune des deux approches n’est fausse ; les mélanger à moitié produit un tunnel avec un bail et sans sortie, ce qui est exactement le symptôme avec lequel vous avez commencé. Choisissez un modèle et terminez-le avant d’ajouter l’autre.

Écartez d’abord le chemin extérieur

Aucun pool ne peut aider si le tunnel ne se forme jamais. Le protocole décide de ce que le chemin doit transporter : PPTP veut TCP 1723 et GRE, qui est le protocole IP 47 et non un port ; L2TP/IPsec veut UDP 1701 plus 500 et 4500 ; SSTP veut TCP 443.

Un routeur qui transfère le port mais pas le protocole produit une tentative de connexion qui ne s’authentifie jamais. C’est une panne différente d’un tunnel qui se forme puis n’atteint rien, et les deux ne doivent pas être déboguées ensemble.

Testez depuis le même LAN et depuis le réseau distant. Si la tentative depuis le LAN fonctionne et que la distante n’atteint jamais l’authentification, le chemin extérieur est le problème. Si les deux s’authentifient et que seul le client distant n’a pas internet, revenez au pool et à la sortie.