콘텐츠로 이동
OmniRoute source

MITM TPROXY Transparent Decrypt (한국어)

다른 네 가지 캡처 모드에는 각각 다음과 같은 제한 사항이 있습니다.

모드 트래픽 전달 방식 제한 사항
AgentBridge 고정된 호스트 집합에 대한 /etc/hosts DNS 스푸핑 등록된 IDE 에이전트 호스트만 지원
사용자 지정 호스트 호스트별 /etc/hosts DNS 스푸핑 호스트마다 하나의 항목 필요, hosts 편집에 sudo 필요
HTTP_PROXY HTTP_PROXY/HTTPS_PROXY 환경 변수 환경 변수를 따르는 앱만 지원
시스템 전역 프록시 OS 프록시 설정 전역 상태를 변경하며 되돌리기 필요

TPROXY 투명 복호화는 대신 커널 계층에서 트래픽을 전달합니다. mangle OUTPUT 체인에서 대상 포트(기본값 443)로 향하는 새로운 로컬 아웃바운드 TCP 연결을 마킹하고, ip rule이 마킹된 패킷을 로컬 전달로 재라우팅합니다. 다시 진입할 때 mangle PREROUTING의 TPROXY 대상이 해당 패킷을 IP_TRANSPARENT 리스너로 전달하며, 이 리스너가 TLS를 종료하고 평문을 캡처합니다.

다음과 같은 프로세스의 트래픽을 캡처하고 복호화하려는 경우 사용하세요.

  • AgentBridge에 등록되지 않은 호스트와 통신하고,
  • HTTP_PROXY를 따르지 않으며,
  • 시스템 전역 프록시 변경으로 인해 영향을 주고 싶지 않은 경우.

가로채기는 커널에서 이루어지므로 원본 프로세스에는 구성 변경이 필요하지 않습니다. 단, 해당 프로세스가 OmniRoute에서 설치한 동적 CA를 신뢰해야 합니다 (§4 참조).


요구 사항 세부 정보
OS Linux 전용 — IP_TRANSPARENT는 Linux에서만 지원되는 소켓 옵션입니다. 로더는 다른 모든 플랫폼에서 “unavailable”을 반환합니다.
권한 투명 소켓을 생성하고 iptables/ip 규칙을 적용하려면 CAP_NET_ADMIN capability가 필요합니다. 실제 환경에서는 root로 실행하세요.
네이티브 애드온 작은 N-API 애드온(src/mitm/tproxy/native/transparent.c)을 빌드하거나 사전 빌드 형태로 제공해야 합니다. §3을 참조하세요.
커널 모듈 TPROXY, mangle, mark 매치 지원이 포함된 iptables가 필요합니다(kernel 6.8.0에서 검증됨).

정상적인 기능 저하: 요구 사항 중 하나라도 충족되지 않으면(Linux가 아님, 툴체인이 없음, 애드온이 빌드되지 않음) 애드온 로더(src/mitm/tproxy/transparentSocket.ts::loadTransparentAddon)는 예외를 발생시키는 대신 null을 반환합니다. 그러면 캡처 모드 상태에 available: false가 표시되고, 대시보드 토글은 “TPROXY 복호화에는 Linux + root + 네이티브 애드온이 필요합니다”라는 툴팁과 함께 비활성화되며, OmniRoute의 나머지 기능은 계속 작동합니다.


Node의 net 모듈은 bind() 전에 setsockopt(IP_TRANSPARENT)를 호출할 수 없지만, TPROXY에는 이 작업이 필요합니다(그렇지 않으면 커널이 리디렉션된 패킷을 폐기합니다). 이 애드온은 (src/mitm/tproxy/native/transparent.c, binding.gyp를 통해 빌드됨) 세 가지 함수를 노출하는 작은 N-API 모듈이며, transparentSocket.ts를 통해 사용됩니다.

애드온 함수 소켓 작업 용도
createTransparentListener(ip, port) socket() + SO_REUSEADDR + IP_TRANSPARENT + bind() + listen(), 원시 fd 반환 투명 캡처 리스너(Node가 server.listen({ fd })를 통해 fd를 인계받음)
setSocketMark(fd, mark) 기존 fd에 setsockopt SO_MARK 적용 루프 방지(프록시 자체 소켓에 마크 지정)
connectMarked(ip, port, mark) 논블로킹 connect() 전에 socket() + SO_MARK 적용, fd 반환 재암호화된 업스트림 전달(SYN에 마크가 포함됨)

원래 대상 주소는 socket.localAddress/localPort에서 읽습니다. TPROXY가 이를 보존하므로 SO_ORIGINAL_DST/NAT 조회는 필요하지 않습니다.

터미널 창
npm run build:native:tproxy # src/mitm/tproxy/native로 이동한 후 node-gyp rebuild 실행
# -> native/build/Release/transparent.node
  • npm run build 중에 scripts/build/build-tproxy-native.mjs가 node-gyp rebuild를 실행합니다. 이 과정은 Linux 전용이며 실패해도 치명적이지 않습니다. 툴체인이 없으면 캡처 모드를 사용할 수 없는 상태로 남습니다.
  • assembleStandalone.mjs는 build/Release/transparent.node를 독립 실행형 번들로 복사합니다. transparentSocket.ts는 모듈 기준 상대 경로와 cwd 기준 상대 경로(<cwd>/src/mitm/tproxy/native/...) 모두에서 이를 찾습니다.
  • build/와 prebuilds/는 git에서 무시됩니다. 바이너리는 빌드되며 커밋되지 않습니다.

로더는 다음 우선순위로 탐색합니다. native/build/Release/transparent.node, 그다음 native/prebuilds/transparent.node (둘 다 모듈 기준 상대 경로 및 <cwd>/src/mitm/tproxy/ 아래에서 탐색).


§4 SNI별 동적 CA 및 신뢰 저장소 설치 프로그램

섹션 제목: “§4 SNI별 동적 CA 및 신뢰 저장소 설치 프로그램”

#6684 업데이트: 이제 AgentBridge 정적 서버(src/mitm/server.cjs)도 단일 정적 자체 서명 리프 대신 이와 동일한 CA/리프 아키텍처 패턴을 공유합니다. 이 서버는 별도의 CA 인스턴스 (src/mitm/cert/rootCa.ts, <DATA_DIR>/mitm/ca.key/ca.crt에 영구 저장)를 사용하며, 기존 omniroute-mitm.crt 신뢰 저장소 슬롯에 설치됩니다(해당 슬롯의 이전 단일 리프를 대체하므로 이중 신뢰 정리는 필요하지 않음). 이 슬롯은 아래에 설명된 TPROXY 자체의 omniroute-tproxy-ca.crt 슬롯과 완전히 분리되어 있습니다. 새 AgentBridge 설치에는 CA 모델이 자동으로 적용됩니다. 이미 이전 정적 리프를 신뢰하는 설치는 운영자가 MITM_ROOT_CA_ENABLED=true를 통해 명시적으로 전환할 때까지 계속 해당 리프를 사용합니다(src/mitm/cert/migration.ts 참조). 어떤 호스트에 대해서도 리프를 서명할 수 있는 신뢰된 MITM CA는 이전의 고정 SAN 리프보다 실질적으로 훨씬 강력하므로, 이미 신뢰가 설정된 설치에서는 절대로 자동 전환되지 않습니다.

기존에는 AgentBridge가 고정된 호스트 집합을 DNS 스푸핑했기 때문에 정적 AgentBridge MITM 인증서가 작동했습니다(이제 아래 모델과 통합됨). TPROXY는 임의의 호스트를 가로채므로, 해당 리스너는 클라이언트가 요청하는 SNI에 관계없이 유효한 리프를 제시해야 합니다. 이제 AgentBridge에도 4개의 antigravity 호스트뿐만 아니라 전체 MITM_TOOL_HOSTS 집합(도구 항목 9개)에 대해 동일한 요구 사항이 적용됩니다.

동적 CA (src/mitm/tproxy/dynamicCert.ts)

섹션 제목: “동적 CA (src/mitm/tproxy/dynamicCert.ts)”

DynamicCertStore는 selfsigned 의존성을 기반으로 구축된 로컬 CA를 실행하며 다음을 수행합니다.

  • generateMitmCa()를 통해 장기 유효 CA를 생성합니다(CN "OmniRoute MITM CA", 유효 기간 10년, basicConstraints CA=true + keyUsage keyCertSign,cRLSign, 2048비트 RSA / SHA-256).
  • issueLeafCert()를 통해 SNI 호스트 이름별 리프를 요청 시 발급하고(유효 기간 1년, subjectAltName = SNI 호스트), 호스트 이름별로 하나의 tls.SecureContext를 캐시합니다.
  • TLS 종료 서버에 사용할 createSNICallback()을 노출합니다(§5 참조).
  • 재시작 간에도 CA를 안정적으로 유지하도록 existingCa를 사용해 생성할 수 있습니다(따라서 신뢰 저장소를 다시 설치할 필요가 없음).

CA 개인 키는 절대로 머신 외부로 유출되지 않습니다.

신뢰 저장소 설치 프로그램 (src/mitm/tproxy/caTrust.ts)

섹션 제목: “신뢰 저장소 설치 프로그램 (src/mitm/tproxy/caTrust.ts)”

가로채기 대상 클라이언트는 동적 CA를 신뢰해야 하므로, 캡처 모드를 시작하면 CA 인증서가 OS 신뢰 저장소의 전용 슬롯인 omniroute-tproxy-ca.crt (상수 TPROXY_CA_CERT_NAME)에 설치됩니다. 이 슬롯은 정적 MITM 인증서의 슬롯(omniroute-mitm.crt)과 분리되어 있어 두 인증서가 서로를 덮어쓰지 않습니다.

installTproxyCa(caPem, sudoPassword?)는 배포판의 앵커 디렉터리를 감지하고 (Debian 스타일을 우선하여 아래 순서로 확인) 일치하는 갱신 명령을 실행합니다.

앵커 디렉터리 갱신 명령
/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

설치 시 PEM을 임시 파일에 스테이징한 다음, 권한이 필요한 작업으로 앵커 디렉터리에 mkdir -p를 실행하고, 스테이징된 파일을 해당 디렉터리로 cp한 후 갱신 명령을 실행합니다. uninstallTproxyCa()는 전용 슬롯만 제거하고 (정적 MITM 인증서는 그대로 유지) 갱신을 수행합니다. Linux가 아닌 환경에서는 아무 작업도 하지 않습니다.

권한이 필요한 모든 명령은 execFileWithPassword(src/mitm/systemCommands.ts)를 통해 실행됩니다. 즉, 인수 배열을 사용하는 spawn이며 셸이나 문자열 보간은 사용하지 않습니다(강제 규칙 #13). 프로세스가 root인 경우(예: VPS) 대상 명령이 직접 실행되므로 비밀번호가 필요하지 않습니다. root가 아닌 데스크톱에서는 sudoPassword가 stdin을 통해 sudo -S에 전달됩니다.

데스크톱의 sudoPassword는 신뢰 저장소 설치를 승인하기 위해 POST 본문으로 제공됩니다. 프로세스가 root인 경우에는 완전히 무시됩니다.


파이프라인(모두 src/mitm/tproxy/ 아래에 위치):

로컬 앱 ──TCP/443──▶ mangle OUTPUT이 연결을 마킹함(fwmark)
ip rule → 로컬 라우팅 테이블 → lo
mangle PREROUTING TPROXY → IP_TRANSPARENT 리스너(포트 8443)
│ captureMode.ts: socket.localAddress에서 원래 목적지를 읽음
▼
tlsCapture.ts:
1. SNI별 리프 인증서(dynamicCert)로 클라이언트 TLS 종료
2. 내부 http.Server가 복호화된 평문을 파싱
3. 캡처 → source: "tproxy"로 globalTrafficBuffer.push()
(sanitizeHeaders + maskSecret 적용)
4. 바이패스 마킹된 소켓을 통해 원래 목적지로
다시 암호화하여 전달(connectMarked, 루프 방지)
│
▼
원래 업스트림(api.example.com)
  • TLS 종료 (createTlsCaptureServer): 동적 CA의 SNI 콜백을 사용하여 서버 측 tls.TLSSocket으로 인터셉트된 원시 소켓을 래핑한 다음, 복호화된 스트림을 내부 http.Server에 전달합니다(표준 MITM 종료 기법). 중단된 터널이 파일 디스크립터를 고갈시키지 않도록 소켓 수명은 MITM_IDLE_TIMEOUT_MS로 제한됩니다.
  • 캡처 (handleDecryptedRequest): source: "tproxy", "in-flight"로 시작하는 상태, sanitizeHeaders()를 거친 헤더, maskSecret()을 거친 본문을 포함하는 InterceptedRequest를 버퍼에 추가합니다. 이후 응답, 크기 및 지연 시간으로 항목을 업데이트합니다.
  • 다시 암호화하여 전달 (createForward / realForward): 원래 목적지로 다시 암호화하여 전달합니다. rejectUnauthorized의 기본값은 true(기본적으로 안전함)입니다. 업스트림 인증서는 클라이언트가 요청한 SNI/Host를 기준으로 검증되므로, 프록시는 원래 클라이언트가 거부했을 대상을 정확히 동일하게 거부합니다.

규칙이 새로운 로컬 아웃바운드 연결을 마킹하므로, 프록시 자체의 다시 암호화된 전달도 일반적으로 다시 인터셉트되어 무한 루프가 발생합니다. 전달 경로는 바이패스 소켓 마크(SO_MARK)를 사용하여 이를 방지합니다.

  • realForward는 connectMarked(ip, port, DEFAULT_BYPASS_MARK)를 통해 업스트림 소켓을 엽니다. DEFAULT_BYPASS_MARK = 0x539이며, connect() 이전에 SO_MARK를 설정하므로 전달 연결의 SYN에 바이패스 마크가 포함됩니다.
  • mangle OUTPUT 규칙은 이미 바이패스 마크가 있는 연결을 제외하므로(-m mark ! --mark &lt;bypassMark&gt;), 프록시의 전달 연결은 다시 마킹되지 않으며 TPROXY에 재진입하지 않습니다.

구현 참고: 바이패스 마킹된 소켓은 에이전트의 createConnection에 설치해야 합니다(에이전트가 있을 때 https.request({ createConnection })는 아무런 알림 없이 무시됨). 그렇지 않으면 전달 과정에서 마킹되지 않은 소켓이 열려 루프가 다시 발생합니다. 이는 e2e 검증을 거친 루프 방지 수정 사항입니다.


제어 항목 세부 정보
루프백 전용 API /api/tools/agent-bridge/tproxy는 LOCAL_ONLY_API_PREFIXES의 /api/tools/agent-bridge/ 접두사에 포함됩니다(src/server/authz/routeGuard.ts). 루프백 강제 적용은 인증 이전에 실행됩니다(엄격한 규칙 #15 + #17). 따라서 터널을 통해 JWT가 유출되더라도 iptables 규칙을 적용하고 자식 프로세스를 통해 신뢰 저장소 CA를 설치하는 TPROXY 캡처를 시작할 수 없습니다.
전용 CA 슬롯 동적 CA는 omniroute-tproxy-ca.crt에 설치되므로 정적 MITM 인증서를 덮어쓰지 않습니다.
CA 키의 호스트 외부 유출 방지 DynamicCertStore는 CA 키를 메모리에 보관하며 내보내지 않습니다.
비밀 정보 마스킹 요청/응답 본문에는 maskSecret()이, 헤더에는 sanitizeHeaders()가 globalTrafficBuffer.push() 이전에 실행됩니다.
셸 보간 미사용 모든 iptables/ip/신뢰 저장소 명령은 인수 배열과 함께 execFile/execFileWithPassword를 통해 실행됩니다(엄격한 규칙 #13).
업스트림 인증서 검증 재암호화된 전달은 기본적으로 업스트림 인증서를 검증합니다(rejectUnauthorized: true).
오류 정제 라우트의 오류 응답은 sanitizeErrorMessage()를 거칩니다(엄격한 규칙 #12).

MITM CA는 강력한 권한을 제공합니다. 모든 호스트에 서명할 수 있으며 OS에서 신뢰하는 CA를 사용하면 OmniRoute가 가로채는 모든 내용을 복호화할 수 있습니다. 이 기능은 명시적인 로컬 전용 TPROXY 캡처 모드로 제한되고 기본적으로 비활성화되어 있으며, 해당 모드를 중지하면 신뢰 저장소 항목이 제거됩니다.


§7 트랜잭션 방식의 방화벽 적용 / 되돌리기

섹션 제목: “§7 트랜잭션 방식의 방화벽 적용 / 되돌리기”

충돌이 발생하더라도 mangle 규칙이나 오래된 라우트가 남아서는 안 됩니다. 명령 빌더 (src/mitm/tproxy/commands.ts)와 실행기(src/mitm/tproxy/setup.ts)는 되돌리기가 적용의 정확한 역연산이며, 역순으로 실행됨을 보장합니다.

applyTproxy(cfg)는 적용 명령을 순서대로 실행합니다. 어떤 실패가 발생하더라도 최선의 방식으로 전체 revertTproxy(cfg)를 실행한 다음 오류를 다시 던집니다. 따라서 방화벽은 완전히 적용되거나 완전히 되돌려지며, 부분적으로 적용된 상태로 남지 않습니다. revertTproxy(cfg)는 역연산 명령을 역순으로 실행하고 실패를 무시합니다(멱등적이므로 AgentBridge의 repairMitm() 정리 작업 등에서 조건 없이 호출해도 안전합니다).

validateTproxyConfig(cfg)는 모든 명령보다 먼저 실행됩니다. 포트는 1–65535 범위여야 하고, mark/routeTable/bypassMark는 양의 정수여야 하며, bypassMark는 mark와 달라야 합니다(루프 방지).

터미널 창
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;

되돌리기는 이들을 역순으로 삭제합니다: PREROUTING -D, OUTPUT -D, ip route del, ip rule del.

이 절차는 OUTPUT 기반입니다. MITM 사용 사례가 동일한 호스트의 앱에서 발생하는 로컬 아웃바운드 트래픽을 대상으로 하며, PREROUTING의 TPROXY만으로는 이를 확인할 수 없기 때문입니다. PREROUTING은 포워딩되는 트래픽만 확인합니다. OUTPUT 체인은 새로운 로컬 연결을 마킹하고, ip rule은 해당 연결을 로컬 전달(lo)로 다시 라우팅하며, 이후 PREROUTING이 해당 연결을 투명 리스너에 할당합니다.


시작 요청(POST /api/tools/agent-bridge/tproxy)은 StartTproxyBodySchema (tproxy/route.ts)로 검증되는 다음 필드를 허용합니다. 모든 필드는 선택 사항이며, 생략하면 기본값이 사용됩니다.

필드 타입 기본값 참고
dport int (1–65535) 443 투명하게 가로챌 대상 TCP 포트
mark int (≥1) 0x2333 OUTPUT에서 설정되고 ip rule + PREROUTING으로 일치 여부를 확인하는 방화벽 마크
onPort int (1–65535) 8443 투명(IP_TRANSPARENT) 리스너가 바인딩하는 포트
routeTable int (≥1) 233 local 0.0.0.0/0 라우트를 보유하는 정책 라우팅 테이블 ID
bypassMark int (≥1, ≠ mark) 0x539 프록시가 자체 업스트림 연결에 설정하는 우회 소켓 마크(SO_MARK). OUTPUT에서 제외되어 루프를 방지함
sudoPassword string — 루트가 아닌 데스크톱에서만 사용: 신뢰 저장소 설치를 승인하며, 루트로 실행할 때는 무시됨

TPROXY용 환경 변수는 없습니다. 모든 구성은 POST 본문 또는 위의 기본값을 통해 지정됩니다.


§9 트래픽 인스펙터에서 활성화하기

섹션 제목: “§9 트래픽 인스펙터에서 활성화하기”
  1. 트래픽 인스펙터(/dashboard/tools/traffic-inspector)를 엽니다.
  2. 캡처 모드 도구 모음에서 “TPROXY 복호화” ⚠ 버튼을 찾습니다 (src/app/(dashboard)/dashboard/tools/traffic-inspector/components/CaptureModesToolbar.tsx).
    • “TPROXY 복호화에는 Linux + root + 네이티브 애드온이 필요합니다”라는 툴팁과 함께 비활성화되어 있다면 이 호스트에서 네이티브 애드온을 사용할 수 없는 것입니다 (Linux가 아니거나, 툴체인이 없거나, 애드온이 빌드되지 않음). §2 및 §3을 참조하세요.
  3. 버튼을 클릭합니다. 그러면 startTproxyCaptureMode() (src/lib/inspector/tproxyCaptureApi.ts)를 통해 POST /api/tools/agent-bridge/tproxy를 호출하며, 이 호출은 동적 CA를 빌드하고, 투명 리스너를 열고, 방화벽 규칙을 적용하고, OS 신뢰 저장소에 CA를 설치합니다.
  4. 실행 중에는 토글이 황색으로 바뀌고 실시간 가로채기 횟수 (· &lt;interceptCount&gt;)가 표시됩니다. 가로챈 요청은 요청 목록에 source: "tproxy"로 나타납니다.
  5. 중지하려면 다시 클릭합니다. stopTproxyCaptureMode()를 통한 DELETE /api/tools/agent-bridge/tproxy가 리스너를 닫고, CA를 제거하며, 방화벽 규칙을 되돌립니다.

캡처 모드 상태(실행 여부 / 사용 가능 여부 / 가로채기 횟수 / 리스너 포트)는 GET /api/tools/agent-bridge/tproxy(src/mitm/tproxy/captureManager.ts의 getCaptureStatus())에서 가져옵니다. 한 번에 하나의 TPROXY 세션만 실행됩니다. 두 번째 세션을 시작하려 하면 “TPROXY 캡처 모드가 이미 실행 중입니다”라는 메시지와 함께 거부됩니다.


네이티브 애드온을 로드할 수 없습니다. Linux를 사용 중인지, 애드온을 빌드했는지(npm run build:native:tproxy), 프로세스가 transparent.node를 로드할 수 있는지 확인하세요. isTransparentSocketAvailable()이 토글의 활성화 여부를 결정하며, 애드온이 없으면 GET /api/tools/agent-bridge/tproxy가 available: false를 반환합니다.

  • 가로채기 대상 프로세스가 실제로 구성된 dport(기본값 443)에 연결하는지 확인하세요.
  • 프로세스가 동적 CA를 신뢰하는지 확인하세요. CA는 omniroute-tproxy-ca.crt로 설치됩니다. 자체 신뢰 저장소를 사용하는 앱 (Firefox/Chrome NSS)의 경우 해당 저장소에도 인증서를 추가해야 할 수 있습니다.
  • 인증서 신뢰 여부 / 서버 상태 검사를 위해 AgentBridge 진단 자체 테스트를 실행하세요(AGENTBRIDGE.md 참조).

충돌 후에도 방화벽 규칙이 남아 있음

섹션 제목: “충돌 후에도 방화벽 규칙이 남아 있음”

revertTproxy()는 적용 작업의 정확한 역연산이며 멱등성을 보장합니다. 모드를 중지하면 규칙이 되돌려집니다. 세션 도중 OmniRoute가 강제 종료된 경우 AgentBridge 복구 작업(POST /api/tools/agent-bridge/repair)을 사용하여 남겨진 시스템 상태(DNS 스푸핑, 루트 CA, 시스템 프록시)를 되돌리세요. TPROXY mangle 규칙과 경로도 재부팅 시 자동으로 초기화됩니다.

무한 루프 / 프록시가 자체 전달을 가로챔

섹션 제목: “무한 루프 / 프록시가 자체 전달을 가로챔”

이는 루프 방지와 관련된 경우입니다. bypassMark가 mark와 다른지 확인하세요 (유효성 검사에서 이를 강제함). 또한 전달 시 connectMarked를 사용하는지 확인하세요(realForward에서 사용함). §5 루프 방지를 참조하세요.


파일 역할
src/mitm/tproxy/commands.ts 순수 iptables/ip 적용 + 되돌리기 명령 빌더, validateTproxyConfig
src/mitm/tproxy/setup.ts 트랜잭션 방식의 applyTproxy / revertTproxy 실행기(실패 시 롤백)
src/mitm/tproxy/transparentSocket.ts 네이티브 애드온 로더(loadTransparentAddon), createTransparentListenerFd, connectMarked, setSocketMark, isTransparentSocketAvailable
src/mitm/tproxy/native/transparent.c N-API 애드온: createTransparentListener(IP_TRANSPARENT), setSocketMark, connectMarked
src/mitm/tproxy/native/binding.gyp node-gyp 빌드 매니페스트
src/mitm/tproxy/dynamicCert.ts DynamicCertStore — SNI별 동적 CA + 리프 인증서 캐시
src/mitm/tproxy/caTrust.ts OS 신뢰 저장소 설치/제거(installTproxyCa / uninstallTproxyCa, 전용 슬롯)
src/mitm/tproxy/tlsCapture.ts TLS 종료형 복호화 엔진 + 재암호화된 루프 방지 전달
src/mitm/tproxy/captureMode.ts 투명 리스너 오케스트레이션, socket.localAddress에서 원래 대상 주소 읽기
src/mitm/tproxy/captureManager.ts 싱글턴 수명 주기: startCaptureMode / stopCaptureMode / getCaptureStatus
src/app/api/tools/agent-bridge/tproxy/route.ts GET / POST / DELETE 라우트(LOCAL_ONLY)
src/lib/inspector/tproxyCaptureApi.ts 클라이언트 fetch 헬퍼(fetchTproxyStatus / startTproxyCaptureMode / stopTproxyCaptureMode)

OmniRoute 소스 코드 (a58000c7685f)

HagiCode

HagiCode는 구조화된 워크플로, 다중 에이전트 실행, Hero Dungeon 뷰를 갖춘 에이전트 코딩 작업 공간입니다.

더 스마트하고 빠르며 즐거운 에이전트 워크플로로 유용한 소프트웨어를 만드세요.

HagiCode 라이트 테마 메인 화면
  • Smart구조화된 워크플로는 의도를 아이디어부터 배포까지 실행 가능한 경로로 바꿉니다.
  • Efficient다중 에이전트 워크플로로 조사, 구현, 검토를 병렬로 진행합니다.
  • FunHero Dungeon은 긴 코딩 세션을 시각적이고 협업적인 경험으로 만듭니다.
HagiCode 방문