Le téléphone n'ouvre pas la page : vérifiez l'adresse d'écoute

L'ordinateur portable sert la page sur localhost, le téléphone rejoint le même VPN, et le navigateur du téléphone signale que le site est inaccessible. Rien ne cloche encore au niveau du tunnel, car le tunnel ne fait que livrer des paquets. Un serveur de développement lié à l'interface de boucle locale n'accepte jamais une connexion adressée à autre chose, donc le premier endroit à examiner est la socket en écoute, pas le VPN.

Passez en revue la socket, le réglage de liaison, la règle du pare-feu et l'URL, dans cet ordre.

La socket répond à une question plus étroite

Un écouteur créé sur 127.0.0.1 accepte le trafic de la machine elle-même et refuse tout ce qui arrive sur une autre adresse. Un écouteur sur l'adresse générique accepte sur toutes les interfaces locales, y compris celle du VPN, ce qui est plus large que ce dont la plupart des installations de développement ont besoin. Un écouteur lié à une adresse VPN précise est l'option utile la plus étroite, et elle ne fonctionne que tant que cette adresse existe.

Deux pièges de nommage en découlent. Dans le navigateur du téléphone, localhost désigne le téléphone, pas l'ordinateur portable. L'adresse générique est une valeur de liaison, pas quelque chose à saisir dans une URL. Quiconque teste avec l'une ou l'autre signalera une panne où le réseau n'est jamais intervenu.

IPv6 ajoute un troisième cas, car une socket peut accepter IPv4 et IPv6 selon des options faciles à négliger. Lisez la famille d'adresses dans la liste. Une entrée générique pour une famille ne décrit pas l'autre.

Lisez l'adresse d'écoute

Inspectez la socket avant de modifier la configuration. L'adresse locale, le port et le processus propriétaire identifient ensemble si le serveur est joignable depuis le VPN.

Get-NetTCPConnection -State Listen -LocalPort 8080 | Select-Object LocalAddress,LocalPort,OwningProcess
Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 8080).OwningProcess
ipconfig | Select-String -Pattern 'IPv4'
Get-NetFirewallRule -DisplayName '*8080*' | Format-Table DisplayName,Enabled,Profile,Direction,Action

Une adresse locale de 127.0.0.1 tranche la question : aucune modification du pare-feu n'aidera, car l'application n'écoute pas sur l'interface du VPN. Une adresse générique ou celle du VPN signifie que la socket est correcte et que la frontière suivante s'applique.

Confirmez aussi le processus propriétaire, car un service sans rapport sur un port courant peut faire paraître le tableau correct alors que le serveur visé n'a jamais démarré. Faites correspondre le chemin de l'exécutable, pas seulement le nom. Un processus obsolète d'une exécution antérieure est un imposteur fréquent.

Changez la liaison via l'application

Utilisez l'option d'adresse d'écoute documentée du framework et redémarrez le processus. Si l'ordinateur portable possède l'adresse privée 10.77.0.1, l'URL du téléphone devient http://10.77.0.1:8080/ et cette adresse doit être routée via le VPN ; rien d'autre dans la configuration ne change.

N'ajoutez pas d'adresses arbitraires à Windows et ne modifiez pas la passerelle pour forcer une liaison. Ces changements survivent à la session de débogage et surprennent la personne suivante. Un serveur démarré avant que l'adresse du VPN existe peut aussi échouer à se lier, donc l'ordre de démarrage compte pour une interface transitoire. Donnez-lui une nouvelle tentative ou démarrez-le après le tunnel. Un échec de liaison au démarrage ressemble exactement à un problème de pare-feu le lendemain matin.

Pour HTTPS, gardez le nom d'hôte du service et la validation du certificat intacts. Un avertissement de certificat sur une adresse brute est un problème de nommage, pas une étape à ignorer, et le DNS privé doit s'accorder avec l'écouteur choisi.

Ouvrez une règle, pas tout le réseau

Une fois que la socket accepte sur l'adresse du VPN, le pare-feu décide si la requête arrive. Limitez la règle à cette application, ce protocole, ce port local et la source distante autorisée, et confirmez quel profil est actif sur l'adaptateur VPN.

Utilisez l'adresse source que Windows voit réellement, y compris toute traduction effectuée par la passerelle, car une règle écrite pour l'adresse d'origine du client ne correspondra pas à une adresse traduite.

Une page qui se charge et affiche une erreur applicative est un progrès : un rejet HTTP est une panne différente d'une absence de connexion TCP, et l'enquête suivante relève de la politique d'accès de l'application, pas du réseau.

Terminez en demandant la page depuis le téléphone prévu et en confirmant qu'un appareil exclu ne peut toujours pas l'atteindre. Un écouteur qui fonctionne avec une règle qui admet tout n'est pas le même résultat.