So binden Sie einen webpack-Dev-Server an eine VPN-Adresse

Ein Entwicklungsserver, der auf dem Laptop antwortet und sonst nirgends, ist meist an die falsche Adresse gebunden. Ein Server, der die Verbindung annimmt, aber die Seite verweigert, scheitert meist an einer Hostnamen-Prüfung. Das sind verschiedene Fehler mit verschiedenen Korrekturen, und die Wahl der richtigen Konfiguration hängt davon ab, wer den Arbeitsbereich erreichen muss und wie er ankommt.

Drei Fragen entscheiden die Antwort: wer verbindet, welche Adresse er erreichen kann und ob Live-Reload für ihn funktionieren muss.

Beginnen Sie mit dem Socket, nicht mit der Konfigurationsdatei

Lesen Sie nach, an was der laufende Prozess tatsächlich gebunden ist, und zwar im selben Netzwerkkontext, der ihn gestartet hat, denn ein Container oder ein Namespace kann einen Socket besitzen, den die Host-Shell nicht sieht. Die Listen-Spalte beantwortet die erste Frage: nur lokaler Pfad, eine bestimmte Schnittstelle oder alle Schnittstellen.

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

Eine Loopback-Adresse ist die sichere Voreinstellung und für einen entfernten Client nutzlos. Eine Wildcard-Bindung ist bequem und legt den Port auf jeder Schnittstelle mit einer Route offen, was weiter ist, als die meisten auf einer Maschine beabsichtigen, die auch einen Tunnel trägt. Eine bestimmte Adresse ist die mittlere Option, und sie funktioniert nur, wenn die Schnittstelle diese Adresse im Moment der Socket-Erstellung besitzt. Der Unterschied ist wichtig, weil zwei dieser drei Bindungen im Browser gleich aussehen und sich völlig anders verhalten, sobald eine zweite Schnittstelle existiert.

Richten Sie sich nach dieser Beobachtung, bevor Sie Routen oder Firewall-Regeln anfassen. Lauscht der Prozess auf der falschen Adresse, bringt kein Policy-Routing den Client dorthin.

Wählen Sie die Bind-Adresse danach, wer sie erreichen muss

Wenn nur Sie auf dieser Maschine die Seite brauchen, behalten Sie die Loopback-Bindung und hören auf. Wenn ein Kollege im selben Tunnel sie braucht, binden Sie die Adresse der Tunnel-Schnittstelle und lassen Sie die Firewall nur diese Quelle zulassen. Einen Entwicklungsserver über den Kreis der aktiv Testenden hinaus zu veröffentlichen ist eine Angewohnheit, die den Arbeitsbereich irgendwann dem Internet aussetzt.

Wenn ein Browser in einem Container den Server erreichen muss, muss die Bind-Adresse eine sein, zu der das Netzwerk des Containers routen kann, und das ist oft nicht die Adresse, die der Host für sich selbst auflöst. Entscheiden Sie den Fall, bevor Sie die Konfiguration bearbeiten, denn die drei Fälle ergeben drei verschiedene Werte, und nur einer ist richtig. Raten kostet hier mehr Zeit als jeder andere Teil der Einrichtung.

Setzen Sie die Adresse dann in der Form, die Ihr Launcher tatsächlich liest. Eine Konfigurationsdatei und ein Skript, das den Server programmatisch aufbaut, verwenden nicht dieselben Optionen:

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

Die Adresse in diesem Ausschnitt ist illustrativ und steht für die VPN-Adresse, die der Host besitzt. Wenn das Projekt den Server mit new WebpackDevServer(options, compiler) baut, übergeben Sie die Optionen stattdessen über das Konstruktorargument, denn die separate devServer -Eigenschaft in der webpack-Konfiguration wird auf diesem Weg nicht berücksichtigt. Dieser Unterschied zwischen Konfigurationsdatei und Node-API erwischt Leute, die einen Ausschnitt in ein Projekt kopieren, das ihn nie liest. Die dev-server-Dokumentation trennt die beiden Startwege und ist die Referenz, gegen die die verwendete Version geprüft werden sollte.

Passen Sie die Hostnamen-Prüfung an die Namen an, die Sie zulassen

Die Hostnamen-Prüfung existiert, um zu verhindern, dass eine von einem angreiferkontrollierten Namen ausgelieferte Seite über den Browser mit Ihrem Entwicklungsserver spricht. Sie mit allowedHosts: "all" abzuschalten entfernt diesen Schutz, und die Bequemlichkeit ist auf einer Maschine, die interne Dienste erreicht, selten den Preis wert. Die Prüfung ist billig korrekt zu erfüllen, sobald man weiß, welche Namen der Browser sendet.

Listen Sie die genauen Namen auf, die Sie verwenden werden, einschließlich des privaten Namens, der zur Tunneladresse auflöst. Löst der Client einen Namen auf eine andere Adresse als die gebundene auf, haben Sie ein Namensauflösungsproblem und kein Serverkonfigurationsproblem, und das Hinzufügen zur Allowlist behebt es nicht. Bestätigen Sie die Auflösung vom Client aus, nicht vom Server.

Halten Sie die drei Kontrollen im Kopf getrennt: Die Bind-Adresse entscheidet, welche Schnittstellen die Verbindung annehmen, die Allowlist entscheidet, welche Host-Header akzeptiert werden, und die Authentifizierung entscheidet, wer hereinkommt. Nur die dritte ist eine Zugriffskontrolle, und ein Entwicklungsserver hat normalerweise keine. Eine Tunneladresse ist auch kein Authentifizierungsmechanismus, denn wer dorthin routen kann, ist bereits innerhalb der Grenze, auf die Sie sich verlassen haben.

Prüfen Sie Seite und Live-Reload-Socket gemeinsam

Laden Sie eine frische Anfrage vom vorgesehenen Client mit dem konfigurierten Schema und lesen Sie das Ergebnis statt des Caches. Bei HTTPS behalten Sie den erwarteten Hostnamen und die Zertifikatsprüfung bei, denn eine Browserwarnung ist kein bestandener Abnahmetest. Eine Seite, die rendert, während Live-Reload still scheitert, ist der häufigste Teilerfolg hier, und er ist bei einer schnellen Prüfung leicht zu übersehen.

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

Öffnen Sie dann die Netzwerkdiagnose des Browsers und beobachten Sie die WebSocket-Verbindung. Eine Seite kann über einen Hostnamen, Port und ein Schema laden, während der Reload-Socket einen anderen verwendet, deshalb müssen beide getrennt geprüft werden. Konfigurieren Sie die dokumentierte Client-URL nur, wenn der ausgerollte Pfad wirklich einen anderen Wert braucht, und beheben Sie lieber den Pfad, als dem Client einen Workaround beizubringen.

Notieren Sie die Listener-Adresse, den akzeptierten Namen, die erlaubte Quelle und beide Ergebnisse in den Projektnotizen. Diese Aufzeichnung überlebt die nächste Person, die den Arbeitsbereich startet und sich wundert, warum die Seite lädt, aber nie neu lädt.