Como servir un servidor de desenvolvemento webpack nun enderezo VPN

Un servidor de desenvolvemento que responde no portátil e en ningún outro sitio adoita estar vinculado ao enderezo incorrecto. Un servidor que acepta a conexión pero rexeita a páxina normalmente falla unha comprobación do nome de host. Son fallos distintos con solucións distintas, e escoller a configuración correcta depende de quen debe chegar ao espazo de traballo e de como chega.

Tres preguntas deciden a resposta: quen se conecta, que enderezo pode alcanzar e se a recarga en vivo ten que funcionar para esa persoa.

Empece polo socket, non polo ficheiro de configuración

Lea a que se vinculou realmente o proceso en execución dentro do mesmo contexto de rede que o iniciou, porque un contedor ou un espazo de nomes pode posuír un socket que o intérprete do host non ve. A columna de escoita responde á primeira pregunta: só ruta local, unha interface concreta ou todas as interfaces.

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

Un enderezo de bucle local é o valor predeterminado seguro e inútil para un cliente remoto. Unha vinculación comodín é cómoda e expón o porto en calquera interface que teña unha ruta, o que é máis amplo do que a maioría pretende nunha máquina que tamén leva un túnel. Un enderezo concreto é a opción intermedia, e só funciona se a interface posúe ese enderezo no momento de crear o socket. A distinción importa porque dúas desas tres vinculacións vense idénticas no navegador e compórtanse de forma totalmente distinta cando existe unha segunda interface.

Axústese a esa observación antes de tocar rutas ou regras de devasas. Se o proceso escoita no enderezo incorrecto, ningún encamiñamento por políticas fará que o cliente chegue a el.

Escolla o enderezo de vinculación segundo quen deba chegar a el

Se só vostede nesta máquina necesita a páxina, manteña a vinculación de bucle local e detéñase. Se a necesita un compañeiro no mesmo túnel, vincule o enderezo da interface do túnel e deixe que a devasa permita só esa fonte. Publicar un servidor de desenvolvemento máis alá das persoas que o están probando activamente é un costume que acaba expoñendo un espazo de traballo a internet.

Se un navegador dentro dun contedor necesita chegar ao servidor, o enderezo de vinculación ten que ser un ao que a rede do contedor poida encamiñar, e a miúdo non é o enderezo que o host resolve para si mesmo. Decida o caso antes de editar a configuración, porque os tres casos producen tres valores distintos e só un é correcto. Adiviñar aquí perde máis tempo que calquera outra parte da posta en marcha.

Despois fixe o enderezo na forma que o seu lanzador le realmente. Un ficheiro de configuración e un script que constrúe o servidor programaticamente non consomen as mesmas opcións:

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

O enderezo dese fragmento é ilustrativo e representa o enderezo VPN que posúe o host. Se o proxecto constrúe o servidor con new WebpackDevServer(options, compiler) pase as opcións polo argumento do construtor no seu lugar, porque a propiedade separada devServer da configuración de webpack non se consulta por esa vía. Esa diferenza entre o ficheiro de configuración e a API de Node atrapa a quen copia un fragmento nun proxecto que nunca o le. A documentación do dev-server separa os dous estilos de lanzamento e é a referencia coa que hai que contrastar a versión en uso.

Axuste a comprobación do nome de host aos nomes que aprobe

A comprobación do nome de host existe para impedir que unha páxina servida desde un nome controlado por un atacante fale co seu servidor de desenvolvemento a través do navegador. Desactivala con allowedHosts: "all" elimina esa protección, e a comodidade raramente paga a pena nunha máquina que pode alcanzar servizos internos. A comprobación é barata de satisfacer correctamente unha vez que sabe que nomes enviará o navegador.

Enumere os nomes exactos que vai usar, incluído o nome privado que resolve ao enderezo do túnel. Se o cliente resolve un nome a un enderezo distinto do que vostede vinculou, ten un problema de resolución de nomes e non de configuración do servidor, e engadir o nome á lista de permitidos non o arranxará. Confirme a resolución desde o cliente, non desde o servidor.

Manteña os tres controis separados na cabeza: o enderezo de vinculación decide que interfaces aceptan a conexión, a lista de permitidos decide que cabeceiras Host se aceptan e a autenticación decide quen pode entrar. Só o terceiro é control de acceso, e un servidor de desenvolvemento normalmente non ten ningún. Un enderezo de túnel tampouco é un mecanismo de autenticación, xa que quen pode encamiñar cara a el xa está dentro do límite no que confiaba.

Verifique a páxina e o socket de recarga en vivo á vez

Cargue unha petición nova desde o cliente previsto co esquema configurado e lea o resultado en lugar da caché. Para HTTPS, manteña o nome de host esperado e a validación do certificado, porque un aviso do navegador non é unha proba de aceptación superada. Unha páxina que se mostra mentres a recarga en vivo falla silenciosamente é o éxito parcial máis habitual aquí, e é fácil pasalo por alto nunha 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

Despois abra os diagnósticos de rede do navegador e observe a conexión WebSocket. Unha páxina pode cargarse por un nome de host, porto e esquema mentres o socket de recarga usa outro, e por iso hai que comprobar os dous por separado. Configure a URL documentada do cliente só cando a ruta despregada necesite de verdade un valor distinto, e prefira arranxar a ruta antes que ensinar ao cliente unha solución alternativa.

Anote o enderezo do oínte, o nome aceptado, a fonte permitida e ambos os resultados nas notas do proxecto. Ese rexistro sobrevive á seguinte persoa que arranque o espazo de traballo e se pregunte por que a páxina carga pero nunca se actualiza.