Come servire un server di sviluppo webpack su un indirizzo VPN

Scegliete l'indirizzo di associazione in base a chi deve raggiungere il server di sviluppo, poi limitate il controllo del nome host e confermate che sia la pagina sia il socket di ricarica in tempo reale si connettono.

Un server di sviluppo che risponde sul portatile e in nessun altro posto è di solito associato all'indirizzo sbagliato. Un server che accetta la connessione ma rifiuta la pagina di solito non supera un controllo del nome host. Sono guasti diversi con correzioni diverse, e scegliere la configurazione giusta dipende da chi deve raggiungere l'area di lavoro e da come arriva.

Tre domande decidono la risposta: chi si connette, quale indirizzo può raggiungere e se la ricarica in tempo reale deve funzionare per quella persona.

Iniziate dal socket, non dal file di configurazione

Leggete a cosa è realmente associato il processo in esecuzione, nello stesso contesto di rete che lo ha avviato, perché un contenitore o uno spazio dei nomi può possedere un socket che la shell dell'host non vede. La colonna di ascolto risponde alla prima domanda: solo percorso locale, un'interfaccia specifica o tutte le interfacce.

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

Un indirizzo di loopback è il valore predefinito sicuro e inutile per un client remoto. Un'associazione con carattere jolly è comoda ed espone la porta su ogni interfaccia che ha una rotta, il che è più ampio di quanto la maggior parte delle persone intenda su una macchina che porta anche un tunnel. Un indirizzo specifico è l'opzione intermedia, e funziona solo se l'interfaccia possiede quell'indirizzo nel momento in cui viene creato il socket. La distinzione conta perché due di queste tre associazioni sembrano identiche nel browser e si comportano in modo del tutto diverso quando esiste una seconda interfaccia.

Allineatevi a questa osservazione prima di toccare rotte o regole del firewall. Se il processo è in ascolto sull'indirizzo sbagliato, nessun routing basato su criteri farà arrivare il client.

Scegliete l'indirizzo di associazione in base a chi deve raggiungerlo

Se solo voi su questa macchina avete bisogno della pagina, mantenete l'associazione di loopback e fermatevi. Se ne ha bisogno un collega sullo stesso tunnel, associate l'indirizzo dell'interfaccia del tunnel e lasciate che il firewall consenta solo quella sorgente. Pubblicare un server di sviluppo oltre le persone che lo stanno testando attivamente è un'abitudine che finisce per esporre un'area di lavoro a internet.

Se un browser dentro un contenitore deve raggiungere il server, l'indirizzo di associazione deve essere uno verso cui la rete del contenitore può instradare, e spesso non è quello che l'host risolve per sé. Decidete il caso prima di modificare la configurazione, perché i tre casi producono tre valori diversi e solo uno è corretto. Indovinare qui fa perdere più tempo di qualsiasi altra parte dell'installazione.

Poi impostate l'indirizzo nella forma che il vostro launcher legge davvero. Un file di configurazione e uno script che costruisce il server a livello di programmazione non consumano le stesse opzioni:

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

L'indirizzo in quel frammento è illustrativo e rappresenta l'indirizzo VPN posseduto dall'host. Se il progetto costruisce il server con new WebpackDevServer(options, compiler) passate le opzioni tramite l'argomento del costruttore, perché la proprietà separata devServer nella configurazione di webpack non viene consultata su quel percorso. Questa differenza tra il file di configurazione e l'API Node coglie chi copia un frammento in un progetto che non lo legge mai. La documentazione del dev-server separa i due stili di avvio ed è il riferimento con cui confrontare la versione in uso.

Allineate il controllo del nome host ai nomi che approvate

Il controllo del nome host esiste per impedire che una pagina servita da un nome controllato da un attaccante parli con il vostro server di sviluppo tramite il browser. Disattivarlo con allowedHosts: "all" rimuove quella protezione, e la comodità raramente vale la pena su una macchina che può raggiungere servizi interni. Il controllo è economico da soddisfare correttamente una volta che sapete quali nomi invierà il browser.

Elencate i nomi esatti che userete, incluso il nome privato che risolve all'indirizzo del tunnel. Se il client risolve un nome a un indirizzo diverso da quello a cui vi siete associati, avete un problema di risoluzione dei nomi e non di configurazione del server, e aggiungere il nome alla lista consentita non lo risolverà. Confermate la risoluzione dal client, non dal server.

Tenete i tre controlli separati in testa: l'indirizzo di associazione decide quali interfacce accettano la connessione, la lista consentita decide quali intestazioni Host sono accettate, e l'autenticazione decide chi può entrare. Solo il terzo è un controllo di accesso, e un server di sviluppo di solito non ne ha. Nemmeno un indirizzo di tunnel è un meccanismo di autenticazione, dato che chiunque possa instradare verso di esso è già dentro il confine su cui contavate.

Verificate la pagina e il socket di ricarica in tempo reale insieme

Caricate una richiesta nuova dal client previsto con lo schema configurato, e leggete il risultato invece della cache. Per HTTPS mantenete il nome host atteso e la validazione del certificato, perché un avviso del browser non è un test di accettazione riuscito. Una pagina che viene visualizzata mentre la ricarica in tempo reale fallisce silenziosamente è il successo parziale più comune qui, ed è facile trascurarlo durante un controllo rapido.

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

Poi aprite la diagnostica di rete del browser e osservate la connessione WebSocket. Una pagina può caricarsi tramite un nome host, una porta e uno schema mentre il socket di ricarica ne usa altri, ed è per questo che i due vanno verificati separatamente. Configurate l'URL client documentato solo quando il percorso distribuito ha davvero bisogno di un valore diverso, e preferite correggere il percorso invece di insegnare al client una soluzione alternativa.

Annotate l'indirizzo in ascolto, il nome accettato, la sorgente consentita e entrambi i risultati nelle note del progetto. Quella registrazione sopravvive alla prossima persona che avvia l'area di lavoro e si chiede perché la pagina si carica ma non si aggiorna mai.

Articoli correlati