Remote-Browser-Debugging-Zugang unter Windows einrichten

Dieser Artikel erklärt, wie man Chrome auf einem Windows-Host ausführt und über CDP einen Remote-Debugging-Zugang bereitstellt, der von Linux-Clients oder MCP im lokalen Netzwerk genutzt werden kann. Der Kern der Lösung besteht darin, dass Chrome nur auf 127.0.0.1 lauscht, portproxy dies auf eine LAN-Adresse abbildet und die Firewall die Quellen aus der Ferne einschränkt.

Topologie und Datenfluss

Die folgende Abbildung zeigt den Fluss der Ports innerhalb des Windows-Hosts sowie wie Clients über die LAN-Adresse zugreifen.

flowchart TB
    subgraph Windows
        A[Chrome DevTools 127.0.0.1:9222] --> B[portproxy 192.168.31.2:9222]
        B --> C[Windows Firewall]
    end
    D[Linux Client] -->|CDP| B

    classDef local fill:#2c3e50,stroke:#ecf0f1,stroke-width:2px,color:#ecf0f1
    classDef proxy fill:#3498db,stroke:#2980b9,stroke-width:2px,color:#fff
    classDef firewall fill:#f39c12,stroke:#d35400,stroke-width:2px,color:#fff
    classDef client fill:#27ae60,stroke:#229954,stroke-width:2px,color:#fff

    class A local
    class B proxy
    class C firewall
    class D client

Chrome starten

Es wird empfohlen, ein eigenständiges Benutzerverzeichnis zu verwenden und die Remote-Debugging-Adresse explizit anzugeben, damit Chrome den Debugging-Port nur für den lokalen Computer öffnet. Das folgende Beispiel verwendet Port 9222; passen Sie ihn bitte an Ihre tatsächliche Umgebung an.

& "C:\Program Files\Google\Chrome\Application\chrome.exe" `
  --remote-debugging-address=127.0.0.1 `
  --remote-debugging-port=9222 `
  --user-data-dir="$env:TEMP\chrome-profile-mcp"

Port-Forwarding konfigurieren

Verwenden Sie portproxy, um den lokalen 127.0.0.1:9222 auf die LAN-Adresse 192.168.31.2:9222 von Windows abzubilden, damit LAN-Clients darauf zugreifen können.

netsh interface portproxy add v4tov4 `
  listenaddress=192.168.31.2 listenport=9222 `
  connectaddress=127.0.0.1 connectport=9222 `
  protocol=tcp

Um sicherzustellen, dass die Regel wirksam ist, können Sie die aktuelle Weiterleitungskonfiguration anzeigen.

netsh interface portproxy show v4tov4

Firewall konfigurieren

Um die Angriffsfläche zu begrenzen, wird empfohlen, nur den Zugriff von bestimmten Client-IPs auf diesen Port zu erlauben. Das folgende Beispiel erlaubt Verbindungen von 192.168.31.162.

New-NetFirewallRule `
  -DisplayName "Allow CDP 9222 from Linux" `
  -Direction Inbound `
  -Action Allow `
  -Protocol TCP `
  -LocalPort 9222 `
  -RemoteAddress 192.168.31.162

Verbindung überprüfen

Wenn sowohl die lokale als auch die LAN-Adresse /json/version zurückgeben, ist die Verbindung funktionsfähig. Dieser Schritt hilft auch bei der schnellen Fehlerlokalisierung, ob das Problem bei Chrome, portproxy oder der Firewall liegt.

curl http://127.0.0.1:9222/json/version
curl http://192.168.31.2:9222/json/version

Die folgende Abbildung zeigt den Weiterleitungsprozess der Verifikationsanfrage zwischen den einzelnen Komponenten.

sequenceDiagram
    participant Client as Client
    participant Proxy as Portproxy
    participant Chrome as Chrome
    Client->>Proxy: HTTP /json/version
    Proxy->>Chrome: 127.0.0.1:9222
    Chrome-->>Proxy: JSON
    Proxy-->>Client: JSON

Mit MCP verbinden

Nachdem der Port freigegeben wurde, muss MCP nur noch auf die LAN-Adresse verweisen. Das folgende Beispiel verwendet chrome-devtools-mcp direkt, um eine Verbindung zu 192.168.31.2:9222 herzustellen.

{
  "chrome-devtools": {
    "command": "npx",
    "args": [
      "-y",
      "chrome-devtools-mcp@latest",
      "--browser-url=http://192.168.31.2:9222"
    ]
  }
}

Bereinigung und Wiederherstellung

portproxy-Regeln sind persistent. Wenn sie nicht mehr benötigt werden, sollten Sie die Zuordnung umgehend löschen und die Firewall-Regeln entfernen, um eine versehentliche Offenlegung des Debugging-Ports zu vermeiden.

netsh interface portproxy delete v4tov4 listenaddress=192.168.31.2 listenport=9222 protocol=tcp

Wenn Sie den Port oder die IP ändern, müssen Sie die Chrome-Parameter, portproxy-Regeln, Firewall-Regeln und die MCP-Konfiguration gleichzeitig anpassen, sonst treten Verbindungsinkonsistenzen auf.

Remote-Debugging-Ports verfügen über vollständige Browsersteuerungsfähigkeiten und sollten nicht öffentlich zugänglich gemacht werden. Es wird auch nicht empfohlen, sie langfristig in Produktionsumgebungen aktiv zu lassen. Wenn eine Nutzung über Netzwerke hinweg erforderlich ist, sollten Sie priorisiert VPN oder Zero-Trust-Tunnel in Betracht ziehen und das Prinzip der geringsten Privilegien und der geringsten Angriffsfläche beibehalten.

• ←Zurück
• Weiter→