2 Punkte von zxsi2003 12 일 전 | 4 Kommentare | Auf WhatsApp teilen

Hallo,
ich habe dieses Tool gebaut, weil ich immer wieder in die Situation kam, nur den Traffic bestimmter Ports, der an einen externen Server geht, kurzzeitig
an einen lokal gestarteten Mock-Server
umleiten zu wollen. (mit Unterstützung von Claude Code)

Die hosts-Datei unterstützt kein portbasiertes Mapping, und Proxys
funktionieren nur, wenn die Anwendung den Proxy
erkennt. Da detour die Pakete eine Ebene tiefer (im Kernel)
abfängt,
arbeitet die Anwendung ganz normal weiter und geht davon aus, dass sie die ursprüngliche Adresse gewählt hat.

Funktionsweise

  • Mit dem WinDivert-Treiber werden ausgehende Pakete im Kernel abgefangen und im
    Userspace
    Destination NAT durchgeführt → dst wird auf TO umgeschrieben, die Prüfsumme
    neu berechnet und das Paket erneut injiziert
  • Antwortpakete werden zurückgesendet, nachdem src wieder auf FROM umgeschrieben wurde,
    sodass
    die Anwendung es so wahrnimmt, als hätte die von ihr gewählte Adresse geantwortet
  • Gilt systemweit (keine PID-Filterung)

Aufbau

  • detour.exe (CLI): Regel in einer Zeile anwenden mit --from 1.2.3.4:5000 --to 127.0.0.1:5001,
    Aufhebung mit Ctrl+C
  • detour-gui.exe: Tray-Icon + Multi-Regel-Tabelle.
    Speichert Regeln automatisch in %APPDATA%\detour\rules.json und stellt sie beim nächsten
    Start wieder her.
    Für jede Regel läuft ein unabhängiges WinDivert-Handle-Paar, sodass mehrere Umleitungen
    gleichzeitig betrieben werden können
  • Eingebettetes UAC-Manifest — Doppelklick zeigt automatisch den Prompt zur Rechteerhöhung
  • WinDivert.dll / WinDivert64.sys ebenfalls in die Binärdatei eingebettet —
    keine separate Treiberinstallation nötig,
    alles in einer einzelnen exe

Stack

  • Go 1.23+
  • GUI mit lxn/walk (direkte Win32-Aufrufe, keine cgo-Abhängigkeit, daher
    Cross-Compile von macOS möglich)
  • Releases als einzelne ZIP mit GoReleaser (CLI + GUI zusammen enthalten)

Einschränkungen (v1)

  • Nur IPv4 (kein IPv6-Support)
  • Lokal ↔ lokal-Traffic (127.0.0.1) kann sich inkonsistent verhalten, da der Windows-Netzwerk-Stack
    diesen
    besonders behandelt
  • TCP MSS Clamping nicht implementiert — bei kleinerer MTU auf dem Umleitungsweg
    ist Fragmentierung möglich

Die Lizenz ist GPLv3 (WinDivert hängt von LGPLv3 ab).
Feedback / Einsatzfälle / Bug-Reports sind willkommen.

4 Kommentare

 
kaydash 11 일 전

Im Grunde ein Proxy ...?

 
zxsi2003 11 일 전

Genau genommen kann man das eher als Destination NAT denn als Proxy bezeichnen. Die Formulierung oben ist etwas lang geraten, daher fasse ich meinen Anwendungsfall unten zusammen.

  1. Ich wollte Anfragen nicht an das Ziel des bereits gebauten Client-Programms (1.2.3.4.:5000), sondern an den Server auf meinem lokalen PC (172.16.100.201:5000) senden.

  2. Da der Anfragepfad fest einkodiert war, musste ich in vielen Fällen den Client-Entwickler um einen Neubuild bitten, wenn ich ihn ändern wollte.

  3. Ich wollte das Problem nicht auf Anwendungsebene, sondern auf OS-Kernel-Ebene lösen, indem ich für Traffic zu einer bestimmten IP und einem bestimmten Port (1.2.3.4.:5000) den Ziel- bzw. Empfänger-Header auf die gewünschte IP und den gewünschten Port (172.16.100.201:5000) ändere.

  4. Entwicklung von detour

 
findnamo 11 일 전

Kann man auch Anfragen per Domain-Adresse weiterleiten?

 
zxsi2003 11 일 전

Bei Anfragen, die als Domain-Adresse eingegeben werden, wurde die Eingabe von vornherein deaktiviert, da die Komplexität bei der Implementierung als zu hoch eingeschätzt wurde ... Da das Tool für interne Tests entwickelt wurde, unterstützt es keine allgemeinen Funktionen.
Es ist möglich, die IP für eine bestimmte Domain per nslookup zu ermitteln und entsprechend zu konfigurieren.

Ich werde versuchen, das in einem späteren Update umzusetzen.