用 LD_PRELOAD 写魔法程序

我和我的同事们排查网路问题非常喜欢 MTR，它是 traceroute 和 ping 的结合，可以快速告诉我们一个网络包的路径。是哪一跳丢包，或者延迟太高。

这些路径使用 IP 地址的形式表示的。没有人能记住这么多 IP 地址，所以我们需要有意义的名字。我在公司里写了一个平台，集成了其他的二十多个系统，给一个 IP，能查询出来这个 IP 对应的网络设备，容器，物理机，虚拟机等等。

复制 IP 到这个系统中查看结果，还是有些不方便，于是就想能不能让 MTR 直接展示设备的名字。

MTR 支持 DNS PTR 反查，如果查到记录，会优先展示名字。这些名字在公网上通常没有什么意义。我们的内网 DNS 没有支持 PTR，所以这个 PTR 记录在默认的情况下也没有什么用。如果通过 DNS 系统来支持 PTR 记录的话，成本就有些大了，得对 DNS 做一些改造，DNS 又是一个比较重要的系统。那能不能有一个影响比较小的旁路系统来做到这个 feature 呢？

看了下 MTR 的代码，MTR 对 DNS PTR 的支持是通过 libc 的函数 getnameinfo(3) 来实现的。那么我就可以用 LD_PRELOAD 这个 hack，自己写一个 getnameinfo(3) 编译成 so，告诉 MTR 在寻找 getnameinfo(3) 的时候，先寻找我的 so 文件。这样，我就可以自己定义 getnameinfo(3) 的行为了。（就像魔法一样）

其实，proxychains¹ 程序也是用这种方式工作的，你只要在运行的命令前面添加 proxychains，proxychains 就会对后面运行的命令注入 LD_PRELOAD 环境变量，从而让程序调用的 socket API 是 proxychains 定义的，然后 proxychains 就会对 socket 做一些代理转发。

POC

可以写一个最简单的程序验证这样是否可行。

我们写一个最简单的函数，声明和 getnameinfo(3) 一模一样。

不过，这个函数无论对于什么 ip，都会返回 kawabangga.com. 然后编译，运行 traceroute 程序。

编译命令：gcc -shared -fPIC -o libmylib.so mylib.c -ldl

可以看到，traceroute 显示每一跳的名字都是 kawabangga.com 了。

用 Go 语言 POC

我比较倾向于用 Go 语言来实现逻辑，而不是用 C 语言。

Go 语言也是支持编译到 shared lib 的²。hello world 代码如下：

编译命令是：go build -o libmylib.so -buildmode=c-shared mylib.go

程序运行的命令一样，也可以看到 getnameinfo(3) 被成功 hook 了。

剩下的只需要在程序里面写逻辑代码就可以了，应该很简单（实际发现不简单）。

遇到问题 1: log 不打印

因为 traceroute 和 mtr 这种程序都是往 stdout 打印的，我开发代码又需要用 print 来调试，所以为了不干扰正常输出，就把日志打印到一个文件，通过 ENV 来控制日志是否需要打印，以及打印的日志路径。

结果就遇到了问题：日志打印在 traceroute 中是正常的，但是在 mtr 中看不到日志。

因为程序是「寄生」在 mtr 的代码中的，而且在 traceroute 中没有问题，所以应该和 mtr 的代码有关。

去看了一下代码，发现 mtr 和 traceroute 不一样的地方是：mtr 是用了异步的方式来执行 getnameinfo 函数，因为这个函数可能使用 DNS PTR 记录，涉及到网络请求，耗时可能很长。所以在调用的时候，mtr 会 fork 一个进程，专门执行这个函数。fork 出来的进程使用 PIPE 和主进程通信，并且 fork 之后就把除了 stdin, stdout, stderr 和 PIPE 之外的 fd 都关闭了。跟着关闭的，也包括我们的日志文件 fd。

解决办法就是修改了一下程序，不写日志到文件了，而是写到 stderr。在 debug 的时候，就 mtr 2>/tmp/stderr.log 这样，就可以了。

问题2: Golang 程序卡住

之前的 POC 代码运行正常，我把它改成通过 HTTP 请求 IP 信息服务的时候，居然就出问题了。mtr 显示的是 IP 而不是名字。从现象看，是函数执行失败了。

但是失败在哪里呢？

经过一段时间的排查，发现了这么几个现象：

1. 每次程序运行之后，都有一些 mtr 进程残留在系统中没有结束；
2. traceroute 还是正常的，但是 mtr 每次都会出问题；
3. 不断加 print 来 debug，发现程序的问题出现在发送 HTTP 请求的地方，但是把这个地方的代码改成直接返回固定字符串，程序就正常了；

使用 gdb 去 debug，backtrace 如下，也看不出什么信息。

看起来这个线程好像没有什么事情可以做。

花了一天排查无果，问了朋友，最后发现这个问题：Goroutines cause deadlocks after fork() when run in shared library #15538³，而且开发人员的回复是：This is to be expected. It’s almost impossible for multithreaded Go runtime to handle arbitrary forks.

而 mtr 正好执行了 fork，所以这算是一个 Golang 的 runtime 问题——如果以 shared-lib 的方式运行，那么主程序是不能 fork 的，如果 fork，Go runtime 中的 goroutine 管理与多线程模型，fork 后线程状态的不一致可能会导致无法正常恢复，从而触发死锁。

最后，我把程序的逻辑用 C 语言实现了一下，就没有问题了。把它打包成 deb 包发布到了内网中。打包推荐用 nfpm⁴，非常方便，传统的用 apt 工具链打包太复杂了。

1. Proxychains 项目：https://github.com/rofl0r/proxychains-ng，我的博客：编译安装proxychains4 ↩︎
2. Fun building shared libraries in Go, https://medium.com/@walkert/fun-building-shared-libraries-in-go-639500a6a669 ↩︎
3. https://github.com/golang/go/issues/15538 ↩︎
4. https://github.com/goreleaser/nfpm ↩︎

---