Como servir um servidor de desenvolvimento webpack num endereço VPN

Escolha o endereço de ligação em função de quem tem de chegar ao servidor de desenvolvimento, depois restrinja a verificação do nome do anfitrião e confirme que a página e o socket de recarregamento em direto estabelecem ligação.

Um servidor de desenvolvimento que responde no portátil e em mais nenhum lugar está normalmente ligado ao endereço errado. Um servidor que aceita a ligação mas recusa a página falha normalmente uma verificação do nome do anfitrião. São falhas diferentes com correções diferentes, e a escolha da configuração certa depende de quem tem de chegar ao espaço de trabalho e de como chega.

Três perguntas decidem a resposta: quem se liga, que endereço consegue alcançar e se o recarregamento em direto tem de funcionar para essa pessoa.

Comece pelo socket, não pelo ficheiro de configuração

Leia a que o processo em execução está realmente ligado, no mesmo contexto de rede que o arrancou, porque um contentor ou um espaço de nomes pode possuir um socket que a shell do anfitrião não vê. A coluna de escuta responde à primeira pergunta: apenas caminho local, uma interface específica ou todas as interfaces.

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

Um endereço de loopback é o valor predefinido seguro e inútil para um cliente remoto. Uma ligação com caráter universal é prática e expõe a porta em qualquer interface que tenha uma rota, o que é mais amplo do que a maioria das pessoas pretende numa máquina que também transporta um túnel. Um endereço específico é a opção intermédia, e só funciona se a interface possuir esse endereço no momento em que o socket é criado. A distinção importa porque duas dessas três ligações parecem idênticas no navegador e comportam-se de forma totalmente diferente quando existe uma segunda interface.

Alinhe-se com essa observação antes de tocar em rotas ou regras de firewall. Se o processo estiver à escuta no endereço errado, nenhum encaminhamento por políticas fará o cliente chegar lá.

Escolha o endereço de ligação em função de quem tem de o alcançar

Se só você neste computador precisa da página, mantenha a ligação de loopback e pare. Se um colega no mesmo túnel precisar dela, ligue o endereço da interface do túnel e deixe a firewall permitir apenas essa origem. Publicar um servidor de desenvolvimento para além das pessoas que o estão a testar ativamente é um hábito que acaba por expor um espaço de trabalho à internet.

Se um navegador dentro de um contentor precisar de chegar ao servidor, o endereço de ligação tem de ser um para o qual a rede do contentor consiga encaminhar, e muitas vezes não é o endereço que o anfitrião resolve para si próprio. Decida o caso antes de editar a configuração, porque os três casos produzem três valores diferentes e só um está correto. Adivinhar aqui perde mais tempo do que qualquer outra parte da instalação.

Depois defina o endereço na forma que o seu lançador lê realmente. Um ficheiro de configuração e um script que constrói o servidor programaticamente não consomem as mesmas opções:

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

O endereço nesse fragmento é ilustrativo e representa o endereço VPN que o anfitrião possui. Se o projeto construir o servidor com new WebpackDevServer(options, compiler) passe as opções pelo argumento do construtor em vez disso, porque a propriedade separada devServer na configuração do webpack não é consultada nesse caminho. Essa diferença entre o ficheiro de configuração e a API Node apanha quem copia um fragmento para um projeto que nunca o lê. A documentação do dev-server separa os dois estilos de arranque e é a referência com que se deve comparar a versão utilizada.

Faça corresponder a verificação do nome do anfitrião aos nomes que aprova

A verificação do nome do anfitrião existe para impedir que uma página servida a partir de um nome controlado por um atacante fale com o seu servidor de desenvolvimento através do navegador. Desativá-la com allowedHosts: "all" remove essa proteção, e a conveniência raramente compensa numa máquina que consegue alcançar serviços internos. A verificação é barata de satisfazer corretamente assim que souber que nomes o navegador enviará.

Enumere os nomes exatos que vai usar, incluindo o nome privado que resolve para o endereço do túnel. Se o cliente resolver um nome para um endereço diferente daquele a que ligou, tem um problema de resolução de nomes e não de configuração do servidor, e acrescentar o nome à lista de permitidos não o resolve. Confirme a resolução a partir do cliente, não do servidor.

Mantenha os três controlos separados na cabeça: o endereço de ligação decide que interfaces aceitam a ligação, a lista de permitidos decide que cabeçalhos Host são aceites, e a autenticação decide quem pode entrar. Só o terceiro é controlo de acesso, e um servidor de desenvolvimento normalmente não tem nenhum. Um endereço de túnel também não é um mecanismo de autenticação, pois quem consegue encaminhar para ele já está dentro do limite em que confiava.

Verifique a página e o socket de recarregamento em direto em conjunto

Carregue um pedido recente a partir do cliente pretendido com o esquema configurado, e leia o resultado em vez da cache. Para HTTPS, mantenha o nome de anfitrião esperado e a validação do certificado, porque um aviso do navegador não é um teste de aceitação bem-sucedido. Uma página que é apresentada enquanto o recarregamento em direto falha silenciosamente é o sucesso parcial mais comum aqui, e é fácil de deixar passar numa verificação 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

Depois abra o diagnóstico de rede do navegador e observe a ligação WebSocket. Uma página pode carregar através de um nome de anfitrião, porta e esquema enquanto o socket de recarregamento usa outros, e é por isso que os dois têm de ser verificados em separado. Configure o URL de cliente documentado apenas quando o caminho implementado precisar realmente de um valor diferente, e prefira corrigir o caminho a ensinar ao cliente uma solução alternativa.

Registe o endereço de escuta, o nome aceite, a origem permitida e ambos os resultados nas notas do projeto. Esse registo sobrevive à próxima pessoa que arrancar o espaço de trabalho e se perguntar porque é que a página carrega mas nunca atualiza.

Artigos relacionados