SCGIS-Wales/ebpf-tls-tracer
GitHub: SCGIS-Wales/ebpf-tls-tracer
基于 eBPF 的 Linux TLS 明文捕获工具，通过 uprobes 挂钩 OpenSSL 实现无需修改应用的实时加密流量可见性。
Stars: 0 | Forks: 0
# TLS Tracer
一个基于 eBPF 的 CLI 工具，用于在 Linux 上实时拦截和检查 TLS/SSL 流量。它将 uprobes 附加到 OpenSSL 的 `SSL_read` 和 `SSL_write` 函数，以捕获流经 TLS 连接的明文数据——无需修改应用程序或终止 TLS 会话。
每个捕获的事件包括连接的**远程 IP 地址**（IPv4 或 IPv6）和**端口**，通过内核级别的 kprobes 对 `connect()` syscall 进行关联获取。
## 功能特性
- **追踪 TLS 连接**并从 `SSL_read`/`SSL_write` 捕获明文数据
- **捕获远程 IP 地址**（IPv4 和 IPv6），通过 connect() kprobe 关联获取主机名背后的 IP
- **过滤**捕获的数据，支持按 PID、UID 或其他条件
- **输出**支持人类可读的文本或结构化的 JSON 格式
- **十六进制转储**模式，用于二进制协议检查
- **自动检测**系统的 OpenSSL 库路径
- **低开销**——使用 eBPF perf buffers 实现高效的内核到用户数据传输
- **优雅关闭**，支持 Ctrl+C / SIGTERM 时的正确资源清理
## 快速开始
**选项 1 —— 预编译二进制文件** (x86_64 Linux):
从 [GitHub Releases](https://github.com/SCGIS-Wales/ebpf-tls-tracer/releases) 下载，然后：
```
tar xzf tls_tracer-linux-x86_64.tar.gz
sudo ./tls_tracer -v
```
**选项 2 —— Docker** (任何内核 5.5+ 的 Linux):
```
docker pull ghcr.io/scgis-wales/ebpf-tls-tracer:latest
sudo docker run --rm --privileged --pid=host ghcr.io/scgis-wales/ebpf-tls-tracer:latest -v
```
**选项 3 —— 从源码构建** (见下方 [从源码构建](#building-from-source))。
## 运行环境要求 (CLI)
这些是**目标机器**上运行该工具所需的条件：
| 需求 | 详情 |
|---|---|
| **操作系统** | Linux (x86_64) |
| **内核** | 最低 5.5，**推荐 6.1+** |
| **权限** | Root，或 `CAP_BPF` + `CAP_PERFMON` + `CAP_SYS_ADMIN` |
| **OpenSSL** | 必须安装 `libssl.so` (自动检测) |
| **运行时库** | `libbpf`, `libelf`, `zlib` |
| **文件系统** | 挂载 debugfs/tracefs (现代发行版标配) |
必须启用以下内核配置选项（Ubuntu, Debian, AL2023, Fedora, RHEL 9+ 默认已启用）：
| 配置选项 | 用途 |
|---|---|
| `CONFIG_BPF=y` | 核心 BPF 子系统 |
| `CONFIG_BPF_SYSCALL=y` | `bpf()` 系统调用 |
| `CONFIG_BPF_JIT=y` | BPF 程序的 JIT 编译器 |
| `CONFIG_KPROBE_EVENTS=y` | 基于 kprobe 的追踪 (用于 IP 捕获) |
| `CONFIG_UPROBE_EVENTS=y` | 基于 uprobe 的追踪 (用于 SSL 挂钩) |
| `CONFIG_DEBUG_INFO_BTF=y` | BTF 类型信息 |
**验证系统：**
```
uname -r # Kernel version (need 5.5+)
ls /sys/kernel/btf/vmlinux # BTF support
cat /proc/sys/net/core/bpf_jit_enable # BPF JIT (should be 1 or 2)
```
**安装运行时依赖：**
```
# Debian/Ubuntu
sudo apt-get install libbpf1 libelf1 zlib1g libssl3
# AL2023/RHEL/Fedora
sudo dnf install libbpf elfutils-libelf zlib openssl-libs
```
## 从源码构建
这些是**构建机器**上所需的条件（可以与目标机器不同）：
| 软件包 (Debian/Ubuntu) | 软件包 (RHEL/AL2023/Fedora) | 用途 |
|---|---|---|
| `clang` | `clang` | BPF 程序编译器 |
| `llvm` | `llvm` | BPF 目标支持 |
| `gcc` | `gcc` | 用户空间编译器 |
| `make` | `make` | 构建系统 |
| `libbpf-dev` | `libbpf-devel` | BPF 用户空间库 (头文件 + .so) |
| `libelf-dev` | `elfutils-libelf-devel` | ELF 解析 |
| `zlib1g-dev` | `zlib-devel` | 压缩 |
| `linux-libc-dev` | `kernel-headers` | BPF 编译所需的内核头文件 |
```
# Debian/Ubuntu
sudo apt-get install clang llvm gcc make libbpf-dev libelf-dev zlib1g-dev linux-libc-dev
# RHEL/AL2023/Fedora
sudo dnf install clang llvm gcc make libbpf-devel elfutils-libelf-devel zlib-devel kernel-devel kernel-headers
# 构建
make
# 运行测试
make test
# 安装到全局 (可选)
sudo make install
```
## 使用方法
```
# 追踪所有 TLS 流量 (需要 root)
sudo ./bin/tls_tracer
# 按进程 ID 过滤
sudo ./bin/tls_tracer -p 1234
# 以 JSON 格式输出
sudo ./bin/tls_tracer -f json
# 捕获数据的十六进制转储
sudo ./bin/tls_tracer -x
# 按 UID 过滤并显示详细输出
sudo ./bin/tls_tracer -u 1000 -v
# 指定自定义 OpenSSL 库路径
sudo ./bin/tls_tracer -l /path/to/libssl.so
```
### 选项
| 短选项 | 长选项 | 描述 |
|------|-----------|-------------|
| `-p` | `--pid PID` | 按进程 ID 过滤 |
| `-u` | `--uid UID` | 按用户 ID 过滤 |
| `-l` | `--lib PATH` | libssl.so 的路径 (默认自动检测) |
| `-f` | `--format FMT` | 输出格式：`text` (默认) 或 `json` |
| `-x` | `--hex` | 显示捕获数据的十六进制转储 |
| `-d` | `--data-only` | 仅打印捕获的数据 (无标题头) |
| `-s` | `--sanitize REGEX` | 过滤匹配 REGEX 的 URL (不区分大小写，可重复) |
| `-v` | `--verbose` | 详细输出 (显示库路径、探针状态) |
| `-h` | `--help` | 显示帮助信息 |
### 输出示例
**文本模式 (默认):**
```
12:34:56 REQUEST PID=1234 TID=1234 UID=1000 COMM=curl ADDR=93.184.216.34:443 LEN=78
GET /api/v1/status HTTP/1.1
Host: example.com
12:34:56 RESPONSE PID=1234 TID=1234 UID=1000 COMM=curl ADDR=93.184.216.34:443 LEN=256
HTTP/1.1 200 OK
Content-Type: application/json
```
**JSON 模式 (`-f json`):**
```
{"timestamp":"2026-03-15T10:30:00.123456Z","timestamp_ns":123456789,"pid":1234,"tid":1234,"uid":1000,"comm":"curl","direction":"REQUEST","src_ip":"10.0.5.23","src_port":54321,"dst_ip":"93.184.216.34","dst_port":443,"data_len":78,"transport":"tls","protocol":"https","http_method":"GET","http_path":"/api/v1/status","http_host":"example.com"}
```
## Docker
每次推送到 `main` 分支时，容器镜像都会发布到 GitHub Container Registry。
```
# 从 GHCR 拉取
docker pull ghcr.io/scgis-wales/ebpf-tls-tracer:latest
# 或本地构建
docker build -t tls_tracer .
# 运行 (eBPF 访问需要 --privileged)
docker run --rm --privileged \
-v /sys/kernel/debug:/sys/kernel/debug:ro \
-v /sys/kernel/tracing:/sys/kernel/tracing:ro \
-v /sys/fs/bpf:/sys/fs/bpf \
--pid=host \
ghcr.io/scgis-wales/ebpf-tls-tracer:latest -v -f json
```
## Amazon Linux 2023 (AL2023)
AL2023 附带内核 6.1+，并且**开箱即完全支持 eBPF**——无需内核重编译或功能标志。BTF、uprobes、kprobes 和 BPF JIT 在原版内核中均已启用。
### 在 AL2023 上安装
```
sudo dnf install -y \
clang llvm gcc make \
libbpf-devel elfutils-libelf-devel zlib-devel \
kernel-devel-$(uname -r) kernel-headers-$(uname -r) \
openssl-devel bpftool
git clone https://github.com/SCGIS-Wales/ebpf-tls-tracer.git
cd ebpf-tls-tracer
make && make test
sudo ./bin/tls_tracer -v
```
### EC2 用户数据 (自动设置)
使用此用户数据脚本在 AL2023 EC2 实例上自动安装并启动 TLS Tracer：
```
#!/bin/bash
set -euo pipefail
# 安装构建依赖
dnf install -y \
clang llvm gcc make \
libbpf-devel elfutils-libelf-devel zlib-devel \
kernel-devel-$(uname -r) kernel-headers-$(uname -r) \
openssl-devel bpftool git
# 克隆并构建
cd /opt
git clone https://github.com/SCGIS-Wales/ebpf-tls-tracer.git
cd ebpf-tls-tracer
make && make test
make install
# 验证 eBPF 支持
echo "=== Kernel: $(uname -r) ==="
ls -la /sys/kernel/btf/vmlinux && echo "BTF: OK"
cat /proc/sys/net/core/bpf_jit_enable && echo "BPF JIT: OK"
bpftool feature probe kernel 2>/dev/null | head -20 || true
```
### AL2023 内核配置 (预启用)
以下配置在 AL2023 的原版内核中**已启用**——无需任何操作：
```
CONFIG_BPF=y
CONFIG_BPF_SYSCALL=y
CONFIG_BPF_JIT=y
CONFIG_BPF_JIT_ALWAYS_ON=y
CONFIG_HAVE_EBPF_JIT=y
CONFIG_DEBUG_INFO_BTF=y
CONFIG_BPF_EVENTS=y
CONFIG_KPROBE_EVENTS=y
CONFIG_UPROBE_EVENTS=y
```
## Kubernetes 部署 (v1.34+)
TLS Tracer 作为 **DaemonSet** 运行，用于监控每个节点上所有进程的出站 TLS 流量。它在内核级别使用 eBPF，这意味着它可以捕获节点上**所有 Pod 和容器**的 TLS 流量——包括任何命名空间（例如 `apigee`、`default` 等）中的 Pod——而无需 sidecar 或更改应用程序。
### 在 Kubernetes 上的工作原理
- 作为 **DaemonSet** 部署（每个节点一个 Pod），配置 `hostPID: true` 和 `privileged: true`
- eBPF 挂钩进入**主机内核的** `SSL_read`/`SSL_write` 和 `connect()` syscall
- 捕获节点上**所有 Pod/容器**的出站 TLS 流量，跨所有命名空间（例如 `apigee`、`default`）
- 通过 Downward API 环境变量自动为事件注入 **K8s 元数据**（Pod 名称、命名空间、容器 ID）
- 从 TLS 明文中解析 **HTTP Layer 7** 详情（方法、路径、Host 头）
- 捕获每个连接的**源和目的 IP:端口**
- 日志以 **JSON 格式**输出到 stdout，每行一个独立事件
### Kubernetes 前置条件
| 需求 | 详情 |
|---|---|
| **Kubernetes 版本** | 1.34+ |
| **节点操作系统** | 内核 6.1+ 的 Linux (推荐 AL2023 —— EKS 1.34 附带内核 6.12) |
| **节点内核配置** | eBPF、kprobes、uprobes 已启用 (见上方前置条件) |
| **容器运行时** | 支持特权容器的 containerd 或 CRI-O |
| **RBAC** | 创建特权 DaemonSets 的集群管理员权限 |
| **节点上的 OpenSSL** | 每个节点上必须存在 `libssl.so` |
### 最低容器权限
TLS Tracer 容器运行**需要**以下权限：
| 权限 | 原因 |
|---|---|
| `privileged: true` | eBPF 程序加载需要完全内核访问权限 |
| `hostPID: true` | 必须查看节点上的所有进程以捕获 TLS 流量 |
| `hostNetwork: true` | connect() kprobe 关联所需 |
| 卷：`/sys/kernel/debug` | uprobe/kprobe 事件的 debugfs 访问 |
| 卷：`/sys/kernel/tracing` | 追踪基础设施的 tracefs 访问 |
| 卷：`/sys/fs/bpf` | 用于 map pinning 的 BPF 文件系统 |
| 卷：`/usr/lib64` (主机) | 访问主机的 `libssl.so` 以进行 uprobe 附加 |
| PSA：`privileged` | 命名空间必须允许特权 Pod |
### 使用 Helm 部署 (推荐)
```
# 创建带有 AL2023 节点的 EKS 集群
eksctl create cluster \
--name my-cluster \
--version 1.34 \
--nodegroup-name al2023-nodes \
--node-type m5.large \
--node-ami-family AmazonLinux2023
# 部署 TLS Tracer (默认 JSON 输出)
helm install tls-tracer helm/tls-tracer \
--namespace tls-tracer --create-namespace
# 检查状态
kubectl -n tls-tracer get pods -o wide
# 查看 JSON 日志 (节点上所有出站 TLS 流量)
kubectl -n tls-tracer logs -l app.kubernetes.io/name=tls-tracer --tail=50 -f
```
#### Helm 值
| 值 | 默认值 | 描述 |
|---|---|---|
| `outputFormat` | `json` | 输出格式：`json` 或 `text` |
| `verbose` | `true` | 启用详细日志记录 |
| `filterPid` | `0` | 按 PID 过滤 (0 = 全部) |
| `filterUid` | `0` | 按 UID 过滤 (0 = 全部) |
| `sslLibPath` | `""` | 自定义 libssl.so 路径 (空 = 自动检测) |
| `sanitizePatterns` | `["apikey=[^&]*"]` | URL 过滤正则模式 (不区分大小写) |
| `companyPrefix` | `""` | 所有资源名称的前缀 (例如 `acme-`) |
| `metadata.awsAccountId` | `""` | AWS 账户 ID (用于 S3/Kinesis 路径) |
| `metadata.awsRegion` | `eu-west-1` | AWS 区域 |
| `metadata.clusterName` | `""` | EKS 集群名称 |
| `metadata.targetNamespace` | `""` | 被监控的 K8s 命名空间 |
| `metadata.applicationName` | `""` | 应用程序名称 (例如 `apigee`) |
| `metadata.environment` | `""` | 环境标签 (例如 `production`) |
| `image.repository` | `ghcr.io/scgis-wales/ebpf-tls-tracer` | 容器镜像 |
| `image.tag` | `latest` | 镜像标签 |
#### AWS S3 日志传输
使用 Apache Hive 风格的目录分区将 JSON 日志传输到 S3。使用带 IRSA 认证的 Python (boto3) sidecar。**默认禁用。**
| 值 | 默认值 | 描述 |
|---|---|---|
| `s3.enabled` | `false` | 启用 S3 日志传输 sidecar |
| `s3.bucket` | `""` | S3 存储桶名称 |
| `s3.prefix` | `tls-tracer-logs` | S3 键前缀 |
| `s3.flushIntervalSeconds` | `60` | 刷新间隔 |
| `s3.batchSize` | `1000` | 每次上传的最大记录数 |
S3 路径格式 (Apache Hive 分区)：
```
s3:////account=/region=/cluster=/
namespace=/app=/env=/year=YYYY/month=MM/day=DD/
hour=HH/-.json
```
#### AWS Kinesis Firehose
将 JSON 日志转发到 Kinesis Firehose 传输流。使用带 IRSA 认证的 Python (boto3) sidecar。**默认禁用。**
| 值 | 默认值 | 描述 |
|---|---|---|
| `kinesis.enabled` | `false` | 启用 Kinesis Firehose sidecar |
| `kinesis.deliveryStreamName` | `""` | Firehose 传输流名称 |
| `kinesis.batchSize` | `500` | 每次 PutRecordBatch 调用的记录数 |
| `kinesis.flushIntervalSeconds` | `30` | 刷新间隔 |
#### IRSA (IAM Roles for Service Accounts)
S3 和 Kinesis sidecar 均使用 IRSA 进行 AWS 认证。在 Service Account 注解中配置 IAM 角色 ARN：
```
serviceAccount:
annotations:
eks.amazonaws.com/role-arn: "arn:aws:iam::123456789012:role/tls-tracer-role"
```
所需的 IAM 权限：
- **S3**：`s3:PutObject`, `s3:GetBucketLocation`
- **Kinesis**：`firehose:PutRecord`, `firehose:PutRecordBatch`
#### URL 过滤
HTTP 路径和 Host 头中的敏感数据可以使用正则模式自动编辑。匹配项将被替换为 `[REDACTED]`。模式不区分大小写 (POSIX ERE)。
**CLI 用法：**
```
# 从记录的 URL 中编校 API 密钥和令牌
sudo ./bin/tls_tracer -f json -s 'apikey=[^&]*' -s 'token=[^&]*' -s 'password=[^&]*'
```
**Helm 值：**
```
sanitizePatterns:
- "apikey=[^&]*"
- "secret=[^&]*"
- "password=[^&]*"
- "token=[^&]*"
- "access_key=[^&]*"
```
处理前：`GET /api/v1/data?apikey=sk_live_abc123&format=json`
处理后： `GET /api/v1/data?[REDACTED]&format=json`
### JSON 日志输出
每个捕获的 TLS 事件都是**单独的一行完整 JSON**：
```
{"timestamp":"2026-03-15T10:30:00.123456Z","timestamp_ns":1710500000000000,"pid":12345,"tid":12345,"uid":1000,"comm":"curl","direction":"REQUEST","src_ip":"10.0.5.23","src_port":54321,"dst_ip":"93.184.216.34","dst_port":443,"data_len":78,"transport":"tls","protocol":"https","k8s_pod":"apigee-runtime-7b8f9c6d4-x2k9m","k8s_namespace":"apigee","container_id":"a1b2c3d4e5f6","http_method":"GET","http_path":"/api/v1/status","http_host":"example.com"}
{"timestamp":"2026-03-15T10:30:00.234567Z","timestamp_ns":1710500000100000,"pid":12345,"tid":12345,"uid":1000,"comm":"curl","direction":"RESPONSE","src_ip":"10.0.5.23","src_port":54321,"dst_ip":"93.184.216.34","dst_port":443,"data_len":256,"transport":"tls","protocol":"https","k8s_pod":"apigee-runtime-7b8f9c6d4-x2k9m","k8s_namespace":"apigee","container_id":"a1b2c3d4e5f6"}
{"timestamp":"2026-03-15T10:30:01.000000Z","timestamp_ns":1710500001000000,"pid":23456,"tid":23456,"uid":0,"comm":"java","direction":"REQUEST","src_ip":"10.0.5.24","src_port":38901,"dst_ip":"10.0.1.50","dst_port":8443,"data_len":142,"transport":"tls","protocol":"https","k8s_pod":"apigee-cassandra-0","k8s_namespace":"apigee","container_id":"f6e5d4c3b2a1","http_method":"POST","http_path":"/v1/organizations","http_host":"management.apigee.internal"}
```
| 字段 | 描述 |
|---|---|
| `timestamp` | 带微秒的 ISO8601 挂钟时间戳 |
| `timestamp_ns` | 内核单调时间戳 (纳秒) |
| `pid`/`tid` | 进程和线程 ID |
| `comm` | 进程命令名 (例如 `curl`, `java`, `node`, `python3`) |
| `direction` | `REQUEST` (发送到服务器的出站请求) 或 `RESPONSE` (来自服务器的入站响应) |
| `src_ip`/`src_port` | 源 (本地) IP 地址和端口 |
| `dst_ip`/`dst_port` | 目的 (远程) IP 地址和端口 |
| `transport` | 传输层：`tls` (所有捕获的流量都经过 SSL) |
| `protocol` | 应用层协议：`https` (检测到 HTTP) 或 `unknown` |
| `k8s_pod` | Kubernetes Pod 名称 (来自 downward API `POD_NAME` 或 `HOSTNAME`) |
| `k8s_namespace` | Kubernetes 命名空间 (来自 downward API `POD_NAMESPACE`) |
| `container_id` | 短容器 ID (来自 cgroup) |
| `http_method` | HTTP 方法：GET, POST, PUT, DELETE, PATCH 等 |
| `http_path` | HTTP 请求路径 (例如 `/api/v1/status`) |
| `http_host` | HTTP Host 头值 (DNS 主机名) |
| `data_len` | 捕获的明文数据长度 |
K8s 和 HTTP 字段仅在检测到时存在。要在受监控的 Pod 上启用 K8s 元数据，请配置 downward API：
```
env:
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
```
### 使用 kubectl 部署 (替代方案)
```
kubectl apply -f deploy/kubernetes/namespace.yaml
kubectl apply -f deploy/kubernetes/rbac.yaml
kubectl apply -f deploy/kubernetes/daemonset.yaml
kubectl -n tls-tracer get pods -o wide
kubectl -n tls-tracer logs -l app=tls-tracer --tail=50
```
### 通过 EKS Userdata 配置节点
如果节点需要运行时库（通常 AL2023 上已预装）：
```
#!/bin/bash
dnf install -y libbpf openssl-libs bpftool
```
### 需要配置的内容
对于 Linux 内核 6.x 上的 Kubernetes 1.34+，每个节点必须满足以下条件。
**EKS 1.34 with AL2023**：EKS 优化的 AL2023 AMI 附带**内核 6.12**（例如 `6.12.73-95.123.amzn2023`）。所有 eBPF 功能——BTF、uprobes、kprobes、BPF JIT、debugfs、tracefs 和 BPF 文件系统——均**完全启用并开箱自动挂载**。无需内核配置、模块加载或文件系统挂载。直接部署 Helm chart 即可。
对于非 AL2023 或自定义 AMI，请验证：
1. **内核模块已加载**（AL2023 上通常自动加载）：
lsmod | grep -E 'bpf|uprobe|kprobe'
2. **BPF 文件系统已挂载**（AL2023 上自动挂载）：
mount -t bpf bpf /sys/fs/bpf
3. **debugfs / tracefs 已挂载**（AL2023 上自动挂载）：
mount -t debugfs debugfs /sys/kernel/debug
mount -t tracefs tracefs /sys/kernel/tracing
4. **Pod Security Admission 中允许特权容器**：
apiVersion: v1
kind: Namespace
metadata:
name: tls-tracer
labels:
pod-security.kubernetes.io/enforce: privileged
### 移除
```
# Helm
helm uninstall tls-tracer -n tls-tracer
# 或 kubectl
kubectl delete -f deploy/kubernetes/daemonset.yaml
kubectl delete -f deploy/kubernetes/rbac.yaml
kubectl delete -f deploy/kubernetes/namespace.yaml
```
## 架构
```
┌──────────────────────────────────────────────────────────┐
│ User Space │
│ │
│ tls_tracer (CLI) │
│ ├── Argument parsing (getopt_long) │
│ ├── BPF object loading (libbpf) │
│ ├── Kprobe attach → connect() for IP capture │
│ ├── Uprobe attach → SSL_read/SSL_write │
│ ├── Perf buffer polling │
│ └── Event formatting (text/json) with IP:port │
│ │
├───────────────── perf buffer ────────────────────────────┤
│ │
│ Kernel Space │
│ │
│ bpf_program.o (eBPF probes) │
│ ├── kprobe/__sys_connect → save sockaddr │
│ ├── kretprobe/__sys_connect → store IP:port in map │
│ ├── uprobe/SSL_read → save buffer ptr │
│ ├── uretprobe/SSL_read → capture data + IP │
│ ├── uprobe/SSL_write → save buffer ptr │
│ └── uretprobe/SSL_write → capture data + IP │
│ │
│ BPF Maps: │
│ ├── ssl_args_map (HASH) → per-thread SSL args │
│ ├── conn_info_map (HASH) → pid_tgid → remote addr │
│ ├── connect_args_map (HASH) → connect() args │
│ └── tls_events (PERF_EVENT_ARRAY) → user-space │
│ │
└──────────────────────────────────────────────────────────┘
```
### IP 捕获工作原理
1. **kprobe on `connect()`** 在 syscall 入口保存 `sockaddr`（包含远程 IP 和端口）
2. **kretprobe on `connect()`** 在成功返回时读取保存的地址，并将 `{pid_tgid} → {remote_ip, remote_port}` 存储在 `conn_info_map` 中
3. 当 **SSL_read/SSL_write** 触发时，uretprobe 通过 `pid_tgid` 在 `conn_info_map` 中查找，以便用连接的远程 IP 地址和端口丰富 TLS 事件
这将捕获连接建立的实际 IP 地址——解析主机名背后的 IP。
## 项目结构
```
ebpf-tls-tracer/
├── include/
│ └── tracer.h # Shared data structures (kernel + user space)
├── src/
│ ├── bpf_program.c # eBPF kernel probes (compiled to BPF bytecode)
│ └── tls_tracer.c # User-space CLI tool
├── tests/
│ └── test_tracer.c # Unit tests
├── deploy/
│ └── kubernetes/
│ ├── namespace.yaml # Namespace definition
│ ├── rbac.yaml # ServiceAccount and RBAC
│ └── daemonset.yaml # DaemonSet for per-node deployment
├── .github/
│ └── workflows/
│ └── build.yml # CI: build, test, functional test, Docker publish
├── helm/
│ └── tls-tracer/ # Helm chart for Kubernetes deployment
│ ├── Chart.yaml
│ ├── values.yaml
│ └── templates/
├── Dockerfile # Multi-stage build (Debian trixie)
├── Makefile # Build system
├── LICENSE # MIT License
└── README.md
```
## 许可证
MIT 许可证。详见 [LICENSE](LICENSE)。
标签：API集成, CLI, DLL注入, Docker镜像, IP 地址批量处理, Kprobe, Linux内核, OpenSSL, TLS/SSL, Uprobe, WiFi技术, 内核态编程, 协议分析, 可观测性, 子域名突变, 客户端加密, 明文抓包, 权限提升, 流量审计, 流量拦截, 网络安全, 请求拦截, 逆向工具, 防御绕过, 隐私保护, 隐私合规检测