MITM TPROXY Transparent Decrypt (Deutsch)

§1 Was es ist und wann es verwendet werden sollte

Die anderen vier Erfassungsmodi haben jeweils eine Einschränkung:

Modus	Wie der Datenverkehr umgeleitet wird	Einschränkung
AgentBridge	`/etc/hosts`-DNS-Spoofing einer festen Host-Gruppe	nur die registrierten IDE-Agent-Hosts
Benutzerdefinierte Hosts	`/etc/hosts`-DNS-Spoofing pro Host	ein Eintrag pro Host; sudo zum Bearbeiten der Hosts-Datei
HTTP_PROXY	`HTTP_PROXY`/`HTTPS_PROXY`-Umgebungsvariablen	nur Apps, die die Umgebungsvariable berücksichtigen
Systemweiter Proxy	Proxy-Einstellungen des Betriebssystems	verändert globalen Zustand; muss rückgängig gemacht werden

Die transparente TPROXY-Entschlüsselung leitet den Datenverkehr stattdessen auf der Kernel-Ebene um. Sie markiert neue lokale ausgehende TCP-Verbindungen zu einem Zielport (standardmäßig 443) in der mangle OUTPUT-Kette, eine ip rule leitet die markierten Pakete zur lokalen Zustellung um, und beim erneuten Eintritt übergibt das TPROXY-Ziel von mangle PREROUTING sie an einen IP_TRANSPARENT-Listener — der anschließend TLS terminiert und den Klartext erfasst.

Verwenden Sie diesen Modus, wenn Sie Datenverkehr eines Prozesses erfassen und entschlüsseln möchten, der:

mit einem Host kommuniziert, den AgentBridge nicht registriert,
HTTP_PROXY nicht berücksichtigt und
nicht durch eine systemweite Proxy-Änderung beeinträchtigt werden soll.

Da das Abfangen im Kernel erfolgt, benötigt der ursprüngliche Prozess keine Konfigurationsänderung — der Prozess muss jedoch der dynamischen CA vertrauen, die OmniRoute installiert (siehe §4).

§2 Anforderungen

Anforderung	Details
Betriebssystem	Nur Linux — IP_TRANSPARENT ist eine ausschließlich unter Linux verfügbare Socket-Option. Der Loader gibt auf jeder anderen Plattform „unavailable“ zurück.
Berechtigung	Die Fähigkeit CAP_NET_ADMIN, um den transparenten Socket zu erstellen und `iptables`-/`ip`-Regeln anzuwenden — in der Praxis als root ausführen.
Natives Add-on	Ein kleines N-API-Add-on (`src/mitm/tproxy/native/transparent.c`) muss erstellt oder als Prebuild bereitgestellt werden. Siehe §3.
Kernelmodule	`iptables` mit Unterstützung für `TPROXY`, `mangle` und den `mark`-Match (validiert mit Kernel 6.8.0).

Kontrollierte Degradierung: Wenn eine Anforderung nicht erfüllt ist (kein Linux, keine Toolchain, Add-on nicht erstellt), gibt der Add-on-Loader (src/mitm/tproxy/transparentSocket.ts::loadTransparentAddon) null zurück, anstatt eine Ausnahme auszulösen. Der Status des Erfassungsmodus meldet dann available: false, der Umschalter im Dashboard ist deaktiviert und zeigt den Tooltip „TPROXY-Entschlüsselung erfordert Linux + root + das native Add-on“ an, während der Rest von OmniRoute weiterhin funktioniert.

§3 Das native IP_TRANSPARENT-Add-on

Nodes net-Modul kann setsockopt(IP_TRANSPARENT) nicht vor bind() aufrufen, was TPROXY jedoch voraussetzt (andernfalls verwirft der Kernel die umgeleiteten Pakete). Das Add-on (src/mitm/tproxy/native/transparent.c, erstellt über binding.gyp) ist ein kleines N-API-Modul, das drei Funktionen bereitstellt, die über transparentSocket.ts verwendet werden:

Add-on-Funktion	Socket-Verarbeitung	Verwendungszweck
`createTransparentListener(ip, port)`	`socket()` + SO_REUSEADDR + IP_TRANSPARENT + `bind()` + `listen()`, gibt den rohen fd zurück	Der transparente Erfassungs-Listener (Node übernimmt den fd über `server.listen({ fd })`)
`setSocketMark(fd, mark)`	`setsockopt` SO_MARK auf einem vorhandenen fd	Schleifenvermeidung (markiert die eigenen Sockets des Proxys)
`connectMarked(ip, port, mark)`	`socket()` + SO_MARK vor einem nicht blockierenden `connect()`, gibt fd zurück	Die erneut verschlüsselte Weiterleitung zum Upstream (das SYN trägt die Markierung)

Das ursprüngliche Ziel wird aus socket.localAddress/localPort gelesen — TPROXY behält es bei, sodass keine SO_ORIGINAL_DST-/NAT-Abfrage erforderlich ist.

Erstellen des Add-ons

npm run build:native:tproxy      # cd src/mitm/tproxy/native && node-gyp rebuild
                                 # -> native/build/Release/transparent.node

Während npm run build führt scripts/build/build-tproxy-native.mjs node-gyp rebuild aus. Dieser Vorgang ist nur für Linux vorgesehen und nicht fatal — eine fehlende Toolchain führt lediglich dazu, dass der Erfassungsmodus nicht verfügbar ist.
assembleStandalone.mjs kopiert build/Release/transparent.node in das Standalone-Bundle; transparentSocket.ts löst den Pfad sowohl relativ zum Modul als auch relativ zum aktuellen Arbeitsverzeichnis auf (<cwd>/src/mitm/tproxy/native/...).
build/ und prebuilds/ werden von Git ignoriert — die Binärdatei wird erstellt, aber niemals committet.

Der Loader prüft in dieser Prioritätsreihenfolge: native/build/Release/transparent.node, dann native/prebuilds/transparent.node (sowohl relativ zum Modul als auch unter <cwd>/src/mitm/tproxy/).

§4 Die dynamische CA pro SNI und der Trust-Store-Installer

#6684-Update: Der statische AgentBridge-Server (src/mitm/server.cjs) verwendet nun dasselbe CA-/Leaf-Architekturmuster statt eines einzelnen statischen selbstsignierten Leaf-Zertifikats. Er verwendet eine separate CA-Instanz (src/mitm/cert/rootCa.ts, dauerhaft gespeichert unter <DATA_DIR>/mitm/ca.key/ca.crt) und installiert sie im bereits vorhandenen Trust-Store-Slot omniroute-mitm.crt (wodurch das alte einzelne Leaf-Zertifikat dort ersetzt wird — keine Bereinigung zweier Vertrauenseinträge erforderlich); sie bleibt vollständig vom unten beschriebenen TPROXY-eigenen Slot omniroute-tproxy-ca.crt getrennt. Bei neuen AgentBridge-Installationen wird das CA-Modell automatisch verwendet; eine Installation, die dem alten statischen Leaf-Zertifikat bereits vertraut, verwendet es weiterhin, bis der Betreiber sich über MITM_ROOT_CA_ENABLED=true dafür entscheidet (siehe src/mitm/cert/migration.ts) — eine vertrauenswürdige MITM-CA, die ein Leaf-Zertifikat für jeden Host signieren kann, ist wesentlich mächtiger als das alte Leaf-Zertifikat mit festen SANs, daher erfolgt die Umstellung bei einer bereits vertrauenden Installation niemals unbemerkt.

Historisch funktionierte das statische AgentBridge-MITM-Zertifikat nur, weil AgentBridge DNS-Spoofing für eine feste Host-Menge durchführt (die nun mit dem unten beschriebenen Modell vereinheitlicht ist). TPROXY fängt beliebige Hosts ab, daher muss sein Listener für jede vom Client angeforderte SNI ein gültiges Leaf-Zertifikat bereitstellen — dieselbe Anforderung gilt nun auch für AgentBridge und die vollständige MITM_TOOL_HOSTS-Menge (9 Tool-Einträge) statt nur für die 4 Antigravity-Hosts.

Dynamische CA (`src/mitm/tproxy/dynamicCert.ts`)

DynamicCertStore betreibt eine lokale CA (basierend auf der Abhängigkeit selfsigned), die:

über generateMitmCa() eine langlebige CA erzeugt (CN "OmniRoute MITM CA", 10 Jahre Gültigkeit, basicConstraints CA=true + keyUsage keyCertSign,cRLSign, 2048-Bit-RSA / SHA-256).
über issueLeafCert() bei Bedarf ein Leaf-Zertifikat pro SNI-Hostname ausstellt (1 Jahr Gültigkeit, subjectAltName = der SNI-Host) und einen tls.SecureContext pro Hostname zwischenspeichert.
createSNICallback() für den TLS-terminierenden Server bereitstellt (siehe §5).
mit einer existingCa erstellt werden kann, um die CA über Neustarts hinweg stabil zu halten (damit der Trust Store nicht erneut eingerichtet werden muss).

Der private Schlüssel der CA verlässt niemals die Maschine.

Trust-Store-Installer (`src/mitm/tproxy/caTrust.ts`)

Der abgefangene Client muss der dynamischen CA vertrauen. Daher wird beim Start des Erfassungsmodus das CA-Zertifikat in einem dedizierten Slot des Trust Stores des Betriebssystems installiert — omniroute-tproxy-ca.crt (Konstante TPROXY_CA_CERT_NAME) —, der vom Slot des statischen MITM-Zertifikats (omniroute-mitm.crt) getrennt bleibt, sodass sich beide niemals gegenseitig überschreiben.

installTproxyCa(caPem, sudoPassword?) erkennt das Anchor-Verzeichnis der Distribution (in dieser Reihenfolge, zuerst im Debian-Stil) und führt den passenden Aktualisierungsbefehl aus:

Anchor-Verzeichnis	Aktualisierungsbefehl
`/usr/local/share/ca-certificates`	`update-ca-certificates`
`/etc/ca-certificates/trust-source/anchors`	`update-ca-trust`
`/etc/pki/ca-trust/source/anchors`	`update-ca-trust`
`/etc/pki/trust/anchors`	`update-ca-certificates`

Bei der Installation wird die PEM-Datei zunächst in einer temporären Datei bereitgestellt. Anschließend wird das Anchor-Verzeichnis mit erhöhten Rechten mittels mkdir -p erstellt, die bereitgestellte Datei mit cp dorthin kopiert und der Aktualisierungsbefehl ausgeführt. uninstallTproxyCa() entfernt nur den dedizierten Slot (das statische MITM-Zertifikat bleibt unverändert) und aktualisiert den Trust Store — unter anderen Betriebssystemen als Linux ist dies eine wirkungslose Operation.

Alle privilegierten Befehle werden über execFileWithPassword (src/mitm/systemCommands.ts) ausgeführt — spawn mit Argument-Arrays, ohne Shell, ohne String-Interpolation (Feste Regel Nr. 13). Wenn der Prozess als root ausgeführt wird (z. B. auf dem VPS), wird das Ziel direkt ausgeführt und es ist kein Passwort erforderlich; auf einem Nicht-root-Desktop wird sudoPassword über sudo -S an stdin übergeben.

Das sudoPassword des Desktops wird im POST-Body übermittelt, um die Installation im Trust Store zu autorisieren; wenn der Prozess als root ausgeführt wird, wird es vollständig ignoriert.

§5 Funktionsweise von Entschlüsselung und Erfassung

Die Pipeline (vollständig unter src/mitm/tproxy/):

lokale App  ──TCP/443──▶  mangle OUTPUT markiert die Verbindung (fwmark)
                           ip rule → lokale Routingtabelle → lo
                           mangle PREROUTING TPROXY → IP_TRANSPARENT-Listener (Port 8443)
                               │  captureMode.ts: liest das ursprüngliche Ziel aus socket.localAddress
                               ▼
                           tlsCapture.ts:
                             1. TLS-Terminierung des CLIENT mit einem SNI-spezifischen Leaf-Zertifikat (dynamicCert)
                             2. interner http.Server analysiert den entschlüsselten Klartext
                             3. Erfassung → globalTrafficBuffer.push() mit source: "tproxy"
                                (sanitizeHeaders + maskSecret angewendet)
                             4. mit erneuter Verschlüsselung an das ursprüngliche Ziel weiterleiten
                                über einen mit Bypass-Markierung versehenen Socket (connectMarked, Anti-Loop)
                               │
                               ▼
                           ursprünglicher Upstream (api.example.com)

TLS-Terminierung (createTlsCaptureServer): Umschließt den abgefangenen Roh-Socket in einem serverseitigen tls.TLSSocket unter Verwendung des SNI-Callbacks der dynamischen CA und übergibt den entschlüsselten Stream anschließend an einen internen http.Server (der übliche Trick zur MITM-Terminierung). Die Socket-Lebensdauer wird durch MITM_IDLE_TIMEOUT_MS begrenzt, damit ein hängender Tunnel nicht alle Dateideskriptoren aufbrauchen kann.
Erfassung (handleDecryptedRequest): Fügt einen InterceptedRequest mit source: "tproxy" und anfänglichem Status "in-flight" hinzu, wobei Header durch sanitizeHeaders() und Bodys durch maskSecret() verarbeitet werden, bevor sie in den Puffer gelangen. Der Eintrag wird anschließend mit der Antwort, den Größen und der Latenz aktualisiert.
Erneut verschlüsselte Weiterleitung (createForward / realForward): Verschlüsselt die Verbindung zum ursprünglichen Ziel erneut. rejectUnauthorized ist standardmäßig true (standardmäßig sicher) — das Upstream-Zertifikat wird anhand des vom Client angeforderten SNI/Host überprüft, sodass der Proxy genau das ablehnt, was auch der ursprüngliche Client ablehnen würde.

Anti-Loop (SO_MARK)

Da die Regeln neue lokale ausgehende Verbindungen markieren, würde die eigene erneut verschlüsselte Weiterleitung des Proxys normalerweise erneut abgefangen werden — eine Endlosschleife. Der Weiterleitungspfad schützt sich davor mit einer Bypass-Socket-Markierung (SO_MARK):

realForward öffnet seinen Upstream-Socket über connectMarked(ip, port, DEFAULT_BYPASS_MARK) — DEFAULT_BYPASS_MARK = 0x539 — wodurch SO_MARK vor connect() gesetzt wird, sodass das SYN-Paket der Weiterleitung die Bypass-Markierung trägt.
Die Regel mangle OUTPUT schließt Verbindungen aus, die bereits die Bypass-Markierung tragen (-m mark ! --mark <bypassMark>), sodass die Weiterleitung des Proxys nicht erneut markiert wird und nicht wieder in TPROXY eintritt.

Implementierungshinweis: Der mit einer Bypass-Markierung versehene Socket muss in createConnection des Agents installiert werden (https.request({ createConnection }) wird stillschweigend ignoriert, wenn ein Agent vorhanden ist), da die Weiterleitung andernfalls einen unmarkierten Socket öffnen und die Schleife erneut auftreten würde. Dies war die durch End-to-End-Tests validierte Anti-Loop-Korrektur.

§6 Sicherheit

Kontrolle	Details
API nur über Loopback	`/api/tools/agent-bridge/tproxy` wird durch das Präfix `/api/tools/agent-bridge/` in `LOCAL_ONLY_API_PREFIXES` (`src/server/authz/routeGuard.ts`) abgedeckt. Die Loopback-Erzwingung erfolgt vor der Authentifizierung (Harte Regeln Nr. 15 + Nr. 17) — ein über einen Tunnel offengelegtes JWT kann keine TPROXY-Erfassung starten, die `iptables`-Regeln anwendet und über untergeordnete Prozesse eine CA im Vertrauensspeicher installiert.
Dedizierter CA-Speicherplatz	Die dynamische CA wird als `omniroute-tproxy-ca.crt` installiert und überschreibt niemals das statische MITM-Zertifikat.
CA-Schlüssel verlässt den Host nie	`DynamicCertStore` hält den CA-Schlüssel im Arbeitsspeicher; er wird nicht exportiert.
Maskierung von Geheimnissen	`maskSecret()` für Anfrage-/Antworttexte und `sanitizeHeaders()` für Header werden vor `globalTrafficBuffer.push()` ausgeführt.
Keine Shell-Interpolation	Alle `iptables`-/`ip`-/Vertrauensspeicherbefehle werden über `execFile`/`execFileWithPassword` mit Argument-Arrays ausgeführt (Harte Regel Nr. 13).
Überprüfung des Upstream-Zertifikats	Die erneut verschlüsselte Weiterleitung überprüft standardmäßig das Upstream-Zertifikat (`rejectUnauthorized: true`).
Fehlerbereinigung	Die Fehlerantworten der Route werden durch `sanitizeErrorMessage()` verarbeitet (Harte Regel Nr. 12).

Die MITM-CA ist eine äußerst mächtige Funktion. Eine vom Betriebssystem als vertrauenswürdig eingestufte CA, die Zertifikate für jeden beliebigen Host signieren kann, bedeutet, dass alles, was OmniRoute abfängt, entschlüsselt werden kann. Sie ist durch den expliziten, ausschließlich lokalen TPROXY-Erfassungsmodus geschützt, standardmäßig deaktiviert, und der Eintrag im Vertrauensspeicher wird entfernt, wenn Sie den Modus beenden.

§7 Transaktionales Anwenden / Zurücksetzen der Firewall

Ein Absturz darf niemals eine mangle-Regel oder eine veraltete Route hinterlassen. Der Befehls-Builder (src/mitm/tproxy/commands.ts) und der Runner (src/mitm/tproxy/setup.ts) gewährleisten: Das Zurücksetzen ist die exakte Umkehrung des Anwendens, in umgekehrter Reihenfolge.

applyTproxy(cfg) führt die Anwendungsbefehle der Reihe nach aus; bei jedem Fehler führt es ein vollständiges revertTproxy(cfg) nach bestem Bemühen aus und gibt den Fehler erneut aus — dadurch ist die Firewall entweder vollständig angewendet oder vollständig zurückgesetzt, niemals nur teilweise angewendet. revertTproxy(cfg) führt die umgekehrten Befehle in umgekehrter Reihenfolge aus und unterdrückt Fehler (idempotent — kann bedingungslos aufgerufen werden, z. B. bei der AgentBridge-Bereinigung repairMitm()).

validateTproxyConfig(cfg) wird vor jedem Befehl ausgeführt: Ports müssen im Bereich 1–65535 liegen, mark/routeTable/bypassMark müssen positive Ganzzahlen sein und bypassMark muss sich von mark unterscheiden (Schleifenvermeidung).

Anwendungsbefehle (in dieser Reihenfolge)

ip rule add fwmark &lt;mark&gt; lookup &lt;routeTable&gt;
ip route add local 0.0.0.0/0 dev lo table &lt;routeTable&gt;
iptables -t mangle -A OUTPUT -p tcp --dport &lt;dport&gt; -m mark ! --mark &lt;bypassMark&gt; -j MARK --set-mark &lt;mark&gt;
iptables -t mangle -A PREROUTING -p tcp --dport &lt;dport&gt; -m mark --mark &lt;mark&gt; -j TPROXY --on-port &lt;onPort&gt; --tproxy-mark &lt;mark&gt;

Beim Zurücksetzen werden sie in umgekehrter Reihenfolge gelöscht: PREROUTING -D, OUTPUT -D, ip route del, ip rule del.

Diese Vorgehensweise basiert auf OUTPUT, da der MITM-Anwendungsfall lokalen ausgehenden Datenverkehr betrifft (Apps auf demselben Host), den TPROXY allein in PREROUTING nicht erfasst — PREROUTING erfasst nur weitergeleiteten Datenverkehr. Die OUTPUT-Kette markiert neue lokale Verbindungen, die ip rule leitet sie zur lokalen Zustellung (lo) um und PREROUTING weist sie anschließend dem transparenten Listener zu.

§8 Konfiguration

Die Startanforderung (POST /api/tools/agent-bridge/tproxy) akzeptiert die folgenden Felder, die von StartTproxyBodySchema (tproxy/route.ts) validiert werden. Alle sind optional und greifen auf ihre Standardwerte zurück:

Feld	Typ	Standard	Hinweise
dport	int (1–65535)	`443`	TCP-Zielport, der transparent abgefangen werden soll
mark	int (≥1)	`0x2333`	Firewall-Markierung, die in `OUTPUT` gesetzt und von der `ip rule` sowie `PREROUTING` abgeglichen wird
onPort	int (1–65535)	`8443`	Port, an den sich der transparente (IP_TRANSPARENT) Listener bindet
routeTable	int (≥1)	`233`	ID der Policy-Routing-Tabelle, welche die Route `local 0.0.0.0/0` enthält
bypassMark	int (≥1, ≠ `mark`)	`0x539`	Socket-Markierung zur Umgehung (SO_MARK), die der Proxy für seine eigenen Upstream-Verbindungen setzt; in `OUTPUT` ausgeschlossen (Schleifenvermeidung)
sudoPassword	string	—	Nur für Nicht-Root-Desktops: autorisiert die Installation im Vertrauensspeicher; wird bei Root-Ausführung ignoriert

Für TPROXY gibt es keine Umgebungsvariablen — die gesamte Konfiguration erfolgt über den POST-Body oder die oben genannten Standardwerte.

§9 Aktivierung über den Traffic Inspector

Öffnen Sie den Traffic Inspector (/dashboard/tools/traffic-inspector).
Suchen Sie in der Symbolleiste für Erfassungsmodi die Schaltfläche „TPROXY-Entschlüsselung“ ⚠ (src/app/(dashboard)/dashboard/tools/traffic-inspector/components/CaptureModesToolbar.tsx).
- Wenn sie deaktiviert ist und der Tooltip „TPROXY-Entschlüsselung erfordert Linux + root + das native Add-on“ angezeigt wird, ist das native Add-on auf diesem Host nicht verfügbar (kein Linux, keine Toolchain oder das Add-on wurde nicht gebaut). Siehe §2 und §3.
Klicken Sie auf die Schaltfläche. Dadurch wird über startTproxyCaptureMode() (src/lib/inspector/tproxyCaptureApi.ts) POST /api/tools/agent-bridge/tproxy aufgerufen. Dies: erstellt die dynamische CA, öffnet den transparenten Listener, wendet die Firewall-Regeln an und installiert die CA im Vertrauensspeicher des Betriebssystems.
Während der Ausführung wird der Umschalter gelb dargestellt und zeigt die aktuelle Anzahl der abgefangenen Verbindungen (· <interceptCount>). Abgefangene Anfragen werden in der Anfrageliste mit source: "tproxy" angezeigt.
Klicken Sie erneut, um den Vorgang zu beenden — DELETE /api/tools/agent-bridge/tproxy über stopTproxyCaptureMode() schließt den Listener, deinstalliert die CA und macht die Firewall-Regeln rückgängig.

Der Status des Erfassungsmodus (wird ausgeführt / verfügbar / Anzahl abgefangener Verbindungen / Listener-Port) stammt von GET /api/tools/agent-bridge/tproxy (getCaptureStatus() in src/mitm/tproxy/captureManager.ts). Es wird jeweils nur eine TPROXY-Sitzung ausgeführt — der Versuch, eine zweite zu starten, wird mit „TPROXY-Erfassungsmodus wird bereits ausgeführt“ abgelehnt.

§10 Fehlerbehebung

Umschalter ist deaktiviert

Das native Add-on kann nicht geladen werden. Vergewissern Sie sich, dass Sie Linux verwenden, das Add-on gebaut haben (npm run build:native:tproxy) und der Prozess transparent.node laden kann. isTransparentSocketAvailable() steuert den Umschalter; GET /api/tools/agent-bridge/tproxy gibt available: false zurück, wenn das Add-on fehlt.

Nichts wird erfasst

Vergewissern Sie sich, dass der abgefangene Prozess tatsächlich eine Verbindung zum konfigurierten dport herstellt (Standardwert: 443).
Vergewissern Sie sich, dass der Prozess der dynamischen CA vertraut. Die CA wird unter omniroute-tproxy-ca.crt installiert; bei Apps mit eigenem Vertrauensspeicher (Firefox/Chrome NSS) muss das Zertifikat möglicherweise auch dort hinzugefügt werden.
Führen Sie den Diagnose-Selbsttest von AgentBridge aus (siehe AGENTBRIDGE.md), um zu prüfen, ob das Zertifikat als vertrauenswürdig gilt und der Server ordnungsgemäß funktioniert.

Veraltete Firewall-Regeln nach einem Absturz

revertTproxy() ist die exakte Umkehrung der Anwendung und idempotent. Beim Beenden des Modus werden die Regeln rückgängig gemacht. Falls OmniRoute während einer Sitzung beendet wurde, verwenden Sie die AgentBridge-Aktion Repair (POST /api/tools/agent-bridge/repair), um verwaiste Systemzustände (DNS-Spoofing, Root-CA, System-Proxy) rückgängig zu machen. Die TPROXY-mangle-Regeln und die Route werden außerdem bei einem Neustart automatisch entfernt.

Endlosschleife / der Proxy fängt seine eigene Weiterleitung ab

Dies ist der Anti-Loop-Fall. Vergewissern Sie sich, dass sich bypassMark von mark unterscheidet (dies wird durch die Validierung erzwungen) und dass die Weiterleitung connectMarked verwendet (dies ist in realForward der Fall). Siehe §5 Anti-Loop.

§11 Quellcodeübersicht

Datei	Zuständigkeit
`src/mitm/tproxy/commands.ts`	Reiner Befehls-Builder zum Anwenden und Rückgängigmachen von `iptables`/`ip`; `validateTproxyConfig`
`src/mitm/tproxy/setup.ts`	Transaktionaler Runner für `applyTproxy` / `revertTproxy` (Rollback bei Fehlern)
`src/mitm/tproxy/transparentSocket.ts`	Loader für das native Add-on (`loadTransparentAddon`), `createTransparentListenerFd`, `connectMarked`, `setSocketMark`, `isTransparentSocketAvailable`
`src/mitm/tproxy/native/transparent.c`	N-API-Add-on: `createTransparentListener` (IP_TRANSPARENT), `setSocketMark`, `connectMarked`
`src/mitm/tproxy/native/binding.gyp`	node-gyp-Build-Manifest
`src/mitm/tproxy/dynamicCert.ts`	`DynamicCertStore` — dynamische CA pro SNI + Leaf-Zertifikat-Cache
`src/mitm/tproxy/caTrust.ts`	Installation/Deinstallation im Vertrauensspeicher des Betriebssystems (`installTproxyCa` / `uninstallTproxyCa`, dedizierter Slot)
`src/mitm/tproxy/tlsCapture.ts`	TLS-terminierende Entschlüsselungs-Engine + erneut verschlüsselte Anti-Loop-Weiterleitung
`src/mitm/tproxy/captureMode.ts`	Orchestrierung des transparenten Listeners; liest das ursprüngliche Ziel aus `socket.localAddress`
`src/mitm/tproxy/captureManager.ts`	Singleton-Lebenszyklus: `startCaptureMode` / `stopCaptureMode` / `getCaptureStatus`
`src/app/api/tools/agent-bridge/tproxy/route.ts`	`GET`- / `POST`- / `DELETE`-Route (LOCAL_ONLY)
`src/lib/inspector/tproxyCaptureApi.ts`	Clientseitige Fetch-Hilfsfunktionen (`fetchTproxyStatus` / `startTproxyCaptureMode` / `stopTproxyCaptureMode`)

OmniRoute-Quellcode (a58000c7685f)

HagiCode

HagiCode ist ein agentischer Coding-Arbeitsplatz mit strukturierten Workflows, Multi-Agent-Ausführung und Hero-Dungeon-Ansichten.

Mit einem intelligenteren, schnelleren und unterhaltsameren agentischen Workflow wird aus Ideen nutzbare Software.

HagiCode-Hauptoberfläche im hellen Design

SmartStrukturierte Workflows machen aus Absichten einen umsetzbaren Weg von der Idee bis zur Auslieferung.
EfficientMulti-Agent-Workflows führen Recherche, Umsetzung und Prüfung parallel aus.
FunHero Dungeon macht lange Coding-Sitzungen anschaulich und gemeinschaftlich.

HagiCode besuchen

Sprache auswählen

Sprache auswählen

MITM TPROXY Transparent Decrypt (Deutsch)

§1 Was es ist und wann es verwendet werden sollte

§2 Anforderungen

§3 Das native IP_TRANSPARENT-Add-on

Erstellen des Add-ons

§4 Die dynamische CA pro SNI und der Trust-Store-Installer

Dynamische CA (`src/mitm/tproxy/dynamicCert.ts`)

Trust-Store-Installer (`src/mitm/tproxy/caTrust.ts`)

§5 Funktionsweise von Entschlüsselung und Erfassung

Anti-Loop (SO_MARK)

§6 Sicherheit

§7 Transaktionales Anwenden / Zurücksetzen der Firewall

Anwendungsbefehle (in dieser Reihenfolge)

§8 Konfiguration

§9 Aktivierung über den Traffic Inspector

§10 Fehlerbehebung

Umschalter ist deaktiviert

Nichts wird erfasst

Veraltete Firewall-Regeln nach einem Absturz

Endlosschleife / der Proxy fängt seine eigene Weiterleitung ab

§11 Quellcodeübersicht

HagiCode

MITM TPROXY Transparent Decrypt (Deutsch)

§1 Was es ist und wann es verwendet werden sollte

§2 Anforderungen

§3 Das native IP_TRANSPARENT-Add-on

Erstellen des Add-ons

§4 Die dynamische CA pro SNI und der Trust-Store-Installer

Dynamische CA (src/mitm/tproxy/dynamicCert.ts)

Trust-Store-Installer (src/mitm/tproxy/caTrust.ts)

§5 Funktionsweise von Entschlüsselung und Erfassung

Anti-Loop (SO_MARK)

§6 Sicherheit

§7 Transaktionales Anwenden / Zurücksetzen der Firewall

Anwendungsbefehle (in dieser Reihenfolge)

§8 Konfiguration

§9 Aktivierung über den Traffic Inspector

§10 Fehlerbehebung

Umschalter ist deaktiviert

Nichts wird erfasst

Veraltete Firewall-Regeln nach einem Absturz

Endlosschleife / der Proxy fängt seine eigene Weiterleitung ab

§11 Quellcodeübersicht

HagiCode

Dynamische CA (`src/mitm/tproxy/dynamicCert.ts`)

Trust-Store-Installer (`src/mitm/tproxy/caTrust.ts`)