Comment servir un serveur de développement webpack sur une adresse VPN

Choisissez l'adresse d'écoute selon qui doit joindre le serveur de développement, puis limitez la vérification du nom d'hôte et confirmez que la page et le socket de rechargement à chaud se connectent.

Un serveur de développement qui répond sur l'ordinateur portable et nulle part ailleurs est généralement lié à la mauvaise adresse. Un serveur qui accepte la connexion mais refuse la page échoue généralement à une vérification du nom d'hôte. Ce sont des pannes différentes avec des correctifs différents, et le choix de la bonne configuration dépend de qui doit joindre l'espace de travail et de la manière dont il y arrive.

Trois questions décident de la réponse : qui se connecte, quelle adresse il peut joindre et si le rechargement à chaud doit fonctionner pour lui.

Commencez par le socket, pas par le fichier de configuration

Lisez à quoi le processus en cours est réellement lié, dans le même contexte réseau qui l'a démarré, car un conteneur ou un espace de noms peut posséder un socket que le shell de l'hôte ne voit pas. La colonne d'écoute répond à la première question : chemin local uniquement, une interface précise ou toutes les interfaces.

ss -ltn '( sport = :8080 )'
ss -ltnp | grep node

Une adresse de bouclage est la valeur par défaut sûre et inutile pour un client distant. Une liaison générique est pratique et expose le port sur toute interface disposant d'une route, ce qui est plus large que ce que la plupart des gens prévoient sur une machine qui porte aussi un tunnel. Une adresse précise est l'option intermédiaire, et elle ne fonctionne que si l'interface possède cette adresse au moment où le socket est créé. La distinction compte parce que deux de ces trois liaisons semblent identiques dans le navigateur et se comportent tout autrement dès qu'une seconde interface existe.

Alignez-vous sur cette observation avant de toucher aux routes ou aux règles de pare-feu. Si le processus écoute sur la mauvaise adresse, aucun routage par politique ne fera parvenir le client jusqu'à elle.

Choisissez l'adresse de liaison selon qui doit l'atteindre

Si seul vous sur cette machine avez besoin de la page, gardez la liaison de bouclage et arrêtez-vous. Si un collègue sur le même tunnel en a besoin, liez l'adresse de l'interface du tunnel et laissez le pare-feu n'autoriser que cette source. Publier un serveur de développement au-delà des personnes qui le testent activement est une habitude qui finit par exposer un espace de travail à internet.

Si un navigateur dans un conteneur doit joindre le serveur, l'adresse de liaison doit être une adresse vers laquelle le réseau du conteneur peut router, et ce n'est souvent pas celle que l'hôte résout pour lui-même. Décidez du cas avant de modifier la configuration, car les trois cas produisent trois valeurs différentes et une seule est correcte. Deviner ici fait perdre plus de temps que toute autre partie de l'installation.

Réglez ensuite l'adresse sous la forme que votre lanceur lit réellement. Un fichier de configuration et un script qui construit le serveur par programmation ne consomment pas les mêmes options :

devServer: {
  host: "10.77.0.20",
  port: 8080,
  allowedHosts: ["dev.corp.example"],
}

L'adresse de ce fragment est illustrative et représente l'adresse VPN que possède l'hôte. Si le projet construit le serveur avec new WebpackDevServer(options, compiler), passez les options par l'argument du constructeur à la place, car la propriété distincte devServer de la configuration webpack n'est pas consultée sur ce chemin. Cette différence entre le fichier de configuration et l'API Node piège ceux qui copient un extrait dans un projet qui ne le lit jamais. La documentation du dev-server sépare les deux styles de lancement et constitue la référence à laquelle comparer la version utilisée.

Faites correspondre la vérification du nom d'hôte aux noms que vous approuvez

La vérification du nom d'hôte existe pour empêcher une page servie depuis un nom contrôlé par un attaquant de parler à votre serveur de développement via le navigateur. La désactiver avec allowedHosts: "all" supprime cette protection, et la commodité en vaut rarement la peine sur une machine qui peut joindre des services internes. La vérification est peu coûteuse à satisfaire correctement une fois que vous savez quels noms le navigateur enverra.

Énumérez les noms exacts que vous utiliserez, y compris le nom privé qui résout vers l'adresse du tunnel. Si le client résout un nom vers une adresse différente de celle que vous avez liée, vous avez un problème de résolution de noms et non de configuration du serveur, et ajouter le nom à la liste d'autorisation ne le corrigera pas. Confirmez la résolution depuis le client, pas depuis le serveur.

Gardez les trois contrôles distincts en tête : l'adresse de liaison décide quelles interfaces acceptent la connexion, la liste d'autorisation décide quels en-têtes Host sont acceptés, et l'authentification décide qui est autorisé à entrer. Seul le troisième est un contrôle d'accès, et un serveur de développement n'en a généralement aucun. Une adresse de tunnel n'est pas non plus un mécanisme d'authentification, puisque quiconque peut y router est déjà à l'intérieur de la frontière sur laquelle vous comptiez.

Vérifiez la page et le socket de rechargement à chaud ensemble

Chargez une requête fraîche depuis le client prévu avec le schéma configuré, et lisez le résultat plutôt que le cache. Pour HTTPS, conservez le nom d'hôte attendu et la validation du certificat, car un avertissement du navigateur n'est pas un test d'acceptation réussi. Une page qui s'affiche alors que le rechargement à chaud échoue silencieusement est le succès partiel le plus courant ici, et il est facile de le manquer lors d'une vérification rapide.

curl -sS -o /dev/null -w "%{http_code} %{remote_ip}\n" http://dev.corp.example:8080/
curl -sS -i http://10.77.0.20:8080/ | head -n 5

Ouvrez ensuite les diagnostics réseau du navigateur et observez la connexion WebSocket. Une page peut se charger via un nom d'hôte, un port et un schéma tandis que le socket de rechargement en utilise d'autres, ce qui explique pourquoi les deux doivent être vérifiés séparément. Ne configurez l'URL client documentée que lorsque le chemin déployé a réellement besoin d'une valeur différente, et préférez corriger le chemin plutôt que d'apprendre au client un contournement.

Notez l'adresse d'écoute, le nom accepté, la source autorisée et les deux résultats dans les notes du projet. Cette trace survit à la personne suivante qui démarre l'espace de travail et se demande pourquoi la page se charge mais ne s'actualise jamais.

Articles similaires