Cómo servir un servidor de desarrollo webpack en una dirección VPN

Un servidor de desarrollo que responde en el portátil y en ningún otro sitio suele estar vinculado a la dirección equivocada. Un servidor que acepta la conexión pero rechaza la página normalmente falla una comprobación del nombre de host. Son fallos distintos con soluciones distintas, y elegir la configuración correcta depende de quién debe llegar al espacio de trabajo y de cómo llega.

Tres preguntas deciden la respuesta: quién se conecta, qué dirección puede alcanzar y si la recarga en vivo tiene que funcionar para esa persona.

Empiece por el socket, no por el archivo de configuración

Lea a qué se ha vinculado realmente el proceso en ejecución dentro del mismo contexto de red que lo inició, porque un contenedor o un espacio de nombres pueden poseer un socket que el intérprete del host no ve. La columna de escucha responde a la primera pregunta: solo ruta local, una interfaz concreta o todas las interfaces.

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

Una dirección de bucle local es el valor predeterminado seguro e inútil para un cliente remoto. Una vinculación comodín es cómoda y expone el puerto en cualquier interfaz que tenga una ruta, lo que es más amplio de lo que la mayoría pretende en una máquina que también lleva un túnel. Una dirección concreta es la opción intermedia, y solo funciona si la interfaz posee esa dirección en el momento de crear el socket. La distinción importa porque dos de esas tres vinculaciones se ven idénticas en el navegador y se comportan de forma totalmente distinta cuando existe una segunda interfaz.

Ajuste esa observación antes de tocar rutas o reglas de cortafuegos. Si el proceso escucha en la dirección equivocada, ningún enrutamiento por políticas hará que el cliente llegue a ella.

Elija la dirección de vinculación según quién deba llegar a ella

Si solo usted en esta máquina necesita la página, mantenga la vinculación de bucle local y deténgase. Si la necesita un compañero en el mismo túnel, vincule la dirección de la interfaz del túnel y deje que el cortafuegos permita solo esa fuente. Publicar un servidor de desarrollo más allá de las personas que lo están probando activamente es una costumbre que acaba exponiendo un espacio de trabajo a internet.

Si un navegador dentro de un contenedor necesita llegar al servidor, la dirección de vinculación tiene que ser una a la que la red del contenedor pueda enrutar, y a menudo no es la dirección que el host resuelve para sí mismo. Decida el caso antes de editar la configuración, porque los tres casos producen tres valores distintos y solo uno es correcto. Adivinar aquí desperdicia más tiempo que cualquier otra parte de la puesta en marcha.

Después fije la dirección en la forma que su lanzador lee realmente. Un archivo de configuración y un script que construye el servidor programáticamente no consumen las mismas opciones:

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

La dirección de ese fragmento es ilustrativa y representa la dirección VPN que posee el host. Si el proyecto construye el servidor con new WebpackDevServer(options, compiler), pase las opciones por el argumento del constructor en su lugar, porque la propiedad separada devServer de la configuración de webpack no se consulta por esa vía. Esa diferencia entre el archivo de configuración y la API de Node atrapa a quien copia un fragmento en un proyecto que nunca lo lee. La documentación del dev-server separa los dos estilos de lanzamiento y es la referencia con la que hay que contrastar la versión en uso.

Ajuste la comprobación del nombre de host a los nombres que apruebe

La comprobación del nombre de host existe para impedir que una página servida desde un nombre controlado por un atacante hable con su servidor de desarrollo a través del navegador. Desactivarla con allowedHosts: "all" elimina esa protección, y la comodidad rara vez vale la pena en una máquina que puede alcanzar servicios internos. La comprobación es barata de satisfacer correctamente una vez que sabe qué nombres enviará el navegador.

Enumere los nombres exactos que va a usar, incluido el nombre privado que resuelve a la dirección del túnel. Si el cliente resuelve un nombre a una dirección distinta de la que usted vinculó, tiene un problema de resolución de nombres y no de configuración del servidor, y añadir el nombre a la lista de permitidos no lo arreglará. Confirme la resolución desde el cliente, no desde el servidor.

Mantenga los tres controles separados en la cabeza: la dirección de vinculación decide qué interfaces aceptan la conexión, la lista de permitidos decide qué cabeceras Host se aceptan y la autenticación decide quién puede entrar. Solo el tercero es control de acceso, y un servidor de desarrollo normalmente no tiene ninguno. Una dirección de túnel tampoco es un mecanismo de autenticación, ya que quien puede enrutar hacia ella ya está dentro del límite en el que confiaba.

Verifique la página y el socket de recarga en vivo a la vez

Cargue una petición nueva desde el cliente previsto con el esquema configurado y lea el resultado en lugar de la caché. Para HTTPS, mantenga el nombre de host esperado y la validación del certificado, porque un aviso del navegador no es una prueba de aceptación superada. Una página que se muestra mientras la recarga en vivo falla en silencio es el éxito parcial más habitual aquí, y es fácil pasarlo por alto en una comprobación rápida.

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

Luego abra los diagnósticos de red del navegador y observe la conexión WebSocket. Una página puede cargarse por un nombre de host, puerto y esquema mientras el socket de recarga usa otro, y por eso hay que comprobar los dos por separado. Configure la URL documentada del cliente solo cuando la ruta desplegada necesite de verdad un valor distinto, y prefiera arreglar la ruta antes que enseñar al cliente un rodeo.

Anote la dirección del oyente, el nombre aceptado, la fuente permitida y ambos resultados en las notas del proyecto. Ese registro sobrevive a la siguiente persona que arranque el espacio de trabajo y se pregunte por qué la página carga pero nunca se actualiza.