Com servir un servidor de desenvolupament webpack en una adreça VPN

Un servidor de desenvolupament que respon a l'ordinador portàtil i enlloc més normalment està lligat a l'adreça equivocada. Un servidor que accepta la connexió però rebutja la pàgina normalment falla una comprovació del nom d'amfitrió. Són fallades diferents amb solucions diferents, i triar la configuració correcta depèn de qui ha d'arribar a l'espai de treball i de com hi arriba.

Tres preguntes decideixen la resposta: qui es connecta, quina adreça pot assolir i si la recàrrega en directe ha de funcionar per a ells.

Comença pel sòcol, no pel fitxer de configuració

Llegeix a què s'ha lligat realment el procés en execució dins del mateix context de xarxa que el va iniciar, perquè un contenidor o un espai de noms pot posseir un sòcol que l'intèrpret d'ordres de l'amfitrió no pot veure. La columna d'escolta respon la primera pregunta: només camí local, una interfície concreta o totes les interfícies.

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

Una adreça de bucle local és el valor predeterminat segur i inútil per a un client remot. Una vinculació comodí és convenient i exposa el port a qualsevol interfície que tingui una ruta, cosa més àmplia del que la majoria de la gent pretén en una màquina que també porta un túnel. Una adreça específica és l'opció intermèdia, i només funciona si la interfície posseeix aquesta adreça en el moment de crear el sòcol. La distinció importa perquè dues d'aquestes tres vinculacions semblen idèntiques al navegador i es comporten de manera completament diferent quan existeix una segona interfície.

Feu cas d'aquesta observació abans de tocar rutes o regles de tallafocs. Si el procés escolta a l'adreça equivocada, cap quantitat d'encaminament per política farà que el client hi arribi.

Trieu l'adreça de vinculació segons qui hi ha d'arribar

Si només vosaltres en aquesta màquina necessiteu la pàgina, manteniu la vinculació de bucle local i atureu-vos. Si un company al mateix túnel la necessita, vinculau l'adreça de la interfície del túnel i deixeu que el tallafocs només permeti aquesta font. Publicar un servidor de desenvolupament més enllà de les persones que el proven activament és un costum que acaba exposant un espai de treball a internet.

Si un navegador dins d'un contenidor ha d'arribar al servidor, l'adreça de vinculació ha de ser una a la qual la xarxa del contenidor pugui encaminar, i sovint no és l'adreça que l'amfitrió resol per a si mateix. Decidiu el cas abans d'editar la configuració, perquè els tres casos produeixen tres valors diferents i només un és correcte. Endevinar aquí fa perdre més temps que qualsevol altra part de la configuració.

Després establiu l'adreça en la forma que el vostre llançador llegeix realment. Un fitxer de configuració i un script que construeix el servidor programàticament no consumeixen les mateixes opcions:

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

L'adreça d'aquest fragment és il·lustrativa i representa l'adreça VPN que posseeix l'amfitrió. Si el projecte construeix el servidor amb new WebpackDevServer(options, compiler), passeu les opcions a través de l'argument del constructor en lloc d'això, perquè la propietat separada devServer de la configuració de webpack no es consulta en aquest camí. Aquesta diferència entre el fitxer de configuració i l'API de Node enganxa qui copia un fragment en un projecte que mai no el llegeix. La documentació del dev-server separa els dos estils de llançament i és la referència amb què cal contrastar la versió en ús.

Ajusteu la comprovació del nom d'amfitrió als noms que aproveu

La comprovació del nom d'amfitrió existeix per impedir que una pàgina servida des d'un nom controlat per un atacant parli amb el vostre servidor de desenvolupament a través del navegador. Desactivar-la amb allowedHosts: "all" elimina aquesta protecció, i la comoditat poques vegades val la pena en una màquina que pot arribar a serveis interns. La comprovació és barata de satisfer correctament un cop sabeu quins noms enviarà el navegador.

Llista els noms exactes que utilitzareu, inclòs el nom privat que resol a l'adreça del túnel. Si el client resol un nom a una adreça diferent de la que heu vinculat, teniu un problema de resolució de noms, no de configuració del servidor, i afegir el nom a la llista d'autoritzats no ho arreglarà. Confirmeu la resolució des del client, no des del servidor.

Tingueu els tres controls separats al cap: l'adreça de vinculació decideix quines interfícies accepten la connexió, la llista d'autoritzats decideix quines capçaleres Host s'accepten, i l'autenticació decideix qui hi pot entrar. Només el tercer és control d'accés, i un servidor de desenvolupament normalment no en té cap. Una adreça de túnel tampoc no és un mecanisme d'autenticació, ja que qui pot encaminar-hi ja és dins del límit en què confiàveu.

Verifiqueu la pàgina i el sòcol de recàrrega en directe alhora

Carregueu una sol·licitud nova des del client previst amb l'esquema configurat, i llegiu el resultat en lloc de la memòria cau. Per a HTTPS, manteniu el nom d'amfitrió esperat i la validació del certificat, perquè un avís del navegador no és una prova d'acceptació satisfactòria. Una pàgina que es mostra mentre la recàrrega en directe falla silenciosament és l'èxit parcial més habitual aquí, i és fàcil de passar per alt durant una comprovació 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

Després obriu els diagnòstics de xarxa del navegador i observeu la connexió WebSocket. Una pàgina pot carregar-se per un nom d'amfitrió, port i esquema mentre el sòcol de recàrrega en fa servir un altre, i per això cal comprovar-los per separat. Configureu l'URL documentat del client només quan el camí desplegat necessiti realment un valor diferent, i preferiu arreglar el camí abans que ensenyar al client una solució alternativa.

Anoteu l'adreça de l'oient, el nom acceptat, la font permesa i els dos resultats a les notes del projecte. Aquest registre sobreviu a la propera persona que engegui l'espai de treball i es pregunti per què la pàgina es carrega però mai no s'actualitza.