Een webpack-ontwikkelserver op een VPN-adres aanbieden

Een ontwikkelserver die op de laptop antwoordt en nergens anders, is meestal aan het verkeerde adres gebonden. Een server die de verbinding accepteert maar de pagina weigert, faalt meestal op een hostnaamcontrole. Dat zijn verschillende fouten met verschillende oplossingen, en de juiste configuratie kiezen hangt ervan af wie de werkruimte moet bereiken en hoe die aankomt.

Drie vragen bepalen het antwoord: wie verbindt, welk adres diegene kan bereiken, en of live reload daarvoor moet werken.

Begin bij de socket, niet bij het configuratiebestand

Lees waaraan het draaiende proces echt gebonden is binnen dezelfde netwerkcontext die het startte, want een container of naamruimte kan een socket bezitten die de host-shell niet ziet. De luisterkolom beantwoordt de eerste vraag: alleen lokaal pad, één specifieke interface of elke interface.

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

Een loopbackadres is de veilige standaard en nutteloos voor een externe client. Een wildcardbinding is handig en stelt de poort open op elke interface met een route, wat breder is dan de meeste mensen bedoelen op een machine die ook een tunnel draagt. Een specifiek adres is de middenoptie, en het werkt alleen als de interface dat adres bezit op het moment dat de socket wordt gemaakt. Het onderscheid is belangrijk omdat twee van die drie bindingen er in de browser identiek uitzien en zich volstrekt anders gedragen zodra er een tweede interface bestaat.

Pas je aan die waarneming aan voordat je routes of firewallregels aanraakt. Als het proces op het verkeerde adres luistert, krijgt geen enkele beleidsroutering de client daar.

Kies het bindadres op basis van wie het moet bereiken

Als alleen jij op deze machine de pagina nodig hebt, houd de loopbackbinding en stop. Als één collega op dezelfde tunnel hem nodig heeft, bind dan het adres van de tunnelinterface en laat de firewall alleen die bron toe. Een ontwikkelserver publiceren buiten de mensen die hem actief testen is een gewoonte die de werkruimte uiteindelijk aan het internet blootstelt.

Als een browser in een container de server moet bereiken, moet het bindadres er een zijn waar het netwerk van de container naartoe kan routeren, en dat is vaak niet het adres dat de host voor zichzelf oplost. Beslis het geval voordat je de configuratie aanpast, want de drie gevallen leveren drie verschillende waarden op en slechts één is juist. Gissen kost hier meer tijd dan welk ander deel van de installatie ook.

Stel daarna het adres in de vorm die je launcher echt leest. Een configuratiebestand en een script dat de server programmatisch bouwt, gebruiken niet dezelfde opties:

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

Het adres in dat fragment is illustratief en staat voor het VPN-adres dat de host bezit. Als het project de server bouwt met new WebpackDevServer(options, compiler) geef de opties dan door via het constructorargument, want de afzonderlijke devServer -eigenschap in de webpack-configuratie wordt op dat pad niet geraadpleegd. Dat verschil tussen het configuratiebestand en de Node-API vangt mensen die een fragment kopiëren naar een project dat het nooit leest. De dev-server-documentatie scheidt de twee startstijlen en is de referentie waarmee de gebruikte versie moet worden vergeleken.

Stem de hostnaamcontrole af op de namen die je goedkeurt

De hostnaamcontrole bestaat om te voorkomen dat een pagina die vanaf een door een aanvaller beheerde naam wordt aangeboden, via de browser met je ontwikkelserver praat. Die uitschakelen met allowedHosts: "all" haalt die bescherming weg, en het gemak is zelden de moeite waard op een machine die interne diensten kan bereiken. De controle is goedkoop correct te vervullen zodra je weet welke namen de browser stuurt.

Noem de exacte namen die je gaat gebruiken, inclusief de privénaam die naar het tunneladres resolvet. Als de client een naam naar een ander adres resolvet dan het adres waaraan je hebt gebonden, heb je een naamresolutieprobleem en geen serverconfiguratieprobleem, en de naam aan de allowlist toevoegen lost het niet op. Bevestig de resolutie vanaf de client, niet vanaf de server.

Houd de drie controles gescheiden in je hoofd: het bindadres bepaalt welke interfaces de verbinding accepteren, de allowlist bepaalt welke Host-headers worden geaccepteerd, en authenticatie bepaalt wie binnen mag. Alleen de derde is toegangscontrole, en een ontwikkelserver heeft er meestal geen. Een tunneladres is ook geen authenticatiemechanisme, want iedereen die erheen kan routeren zit al binnen de grens waarop je vertrouwde.

Controleer de pagina en de live-reloadsocket samen

Laad een vers verzoek van de bedoelde client met het geconfigureerde schema, en lees het resultaat in plaats van de cache. Bij HTTPS houd je de verwachte hostnaam en certificaatvalidatie, want een browserwaarschuwing is geen geslaagde acceptatietest. Een pagina die rendert terwijl live reload stil faalt, is hier het meest voorkomende gedeeltelijke succes, en het is makkelijk te missen bij een snelle controle.

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

Open daarna de netwerkdiagnose van de browser en kijk naar de WebSocket-verbinding. Een pagina kan via één hostnaam, poort en schema laden terwijl de reloadsocket een andere gebruikt, daarom moeten beide apart worden gecontroleerd. Configureer de gedocumenteerde client-URL alleen wanneer het uitgerolde pad echt een andere waarde nodig heeft, en repareer liever het pad dan de client een omweg te leren.

Noteer het luisteradres, de geaccepteerde naam, de toegestane bron en beide resultaten in de projectnotities. Die aantekening overleeft de volgende persoon die de werkruimte start en zich afvraagt waarom de pagina laadt maar nooit ververst.