Istio中的透明代理问题

Istio的Sidecar作为一个网络代理，它拦截入站、出站的网络流量。拦截入站流量后，会使用127.0.0.1作为源地址，将流量转发给本地服务进程。本地服务进程看不到真实源IP地址。

很多应用场景下，真实源IP地址是必须的，可能原因包括：

1. IP地址作为标识的一部分。以ZooKeeper为例，它通过成员的IP地址来验证集群成员身份
2. IP地址用于网络策略，或者用于审计目的

本文将设置这样的场景：一个启用了Istio Sidecar的Nginx Pod，需要被当前命名空间的另外一个Pod访问。我们将尝试解决Nginx不能看到真实的客户端IP地址的问题。

 

目前Envoy已经能够很好的支持IP Transparency了。 它提供了多种机制把真实源地址提供给上游服务。

真实源地址可以通过 x-forwarded-for这样的请求头获取，很多应用都能识别这种请求头。

Envoy还提供了 envoy.filters.http.original_src，此过滤器能够从请求头读取真实源地址，并修改底层TCP连接的源地址。此过滤器还能处理单一下游连接携带来自多个源的HTTP请求的情况。此过滤器的缺点包括：

1. 下游连接必须正确设置了x-forwarded-for头
2. 由于连接池方面的限制，会导致些许性能影响
3. 配置较为复杂，可能需要路由的配合，即使在Sidecar场景（Envoy和上游在同一网络命名空间）下，也需要配置好iptables规则

HAProxy代理协议提供了交换连接元数据的机制，这些元数据就包括真实源IP。Envoy通过监听器过滤器 envoy.filters.listener.proxy_protocol支持代理协议。此过滤器的缺点包括：

1. 上游主机需要支持代理协议
2. 仅仅支持TCP

该监听器过滤器可以和envoy.filters.listener.original_src联用。

在受控部署环境下，通过监听器过滤器 envoy.filters.listener.original_src可以把下游连接源地址复制为上游连接的源地址。

这需要使用透明代理，让Envoy直接以下游地址向上游服务发起连接。对于上游服务，没有任何要求。此过滤器的缺点包括：

1. Envoy要能够获得真实的下游地址
2. 由于路由方面的限制，可能无法实现
3. 由于连接池方面的限制，会导致些许性能影响

这个过滤器是让Istio能够解决透明代理问题的途径，回答一下对它的缺点的规避：

1. Envoy获取真实下游IP地址，也就是入站连接的真实源地址：这可以通过TPROXY拦截模式让Envoy看到真实下游地址
2. 路由方面的限制：不存在，因为Envoy和上游服务（入站连接需要访问的服务）在一个网络命名空间中，可以软件控制路由

在两年前就有了关于此问题的Issue：https://github.com/istio/istio/issues/5679。到目前为止，Istio官方没有提供支持透明代理的方案。

Istio支持两种拦截模式：

1. REDIRECT：使用iptables的REDIRECT目标来拦截入站请求，转给Envoy
2. TPROXY：使用iptables的TPROXY目标来拦截入站请求，转给Envoy

你可以全局的设置默认拦截模式，也可以通过注解 sidecar.istio.io/interceptionMode: TPROXY给某个工作负载单独设置。

需要注意的是TPROXY模式解决的仅仅是Envoy看到的入站连接源IP地址的问题，被代理本地服务看到的地址仍然是127.0.0.1。

下面对比一下两种拦截模式下生成的iptables规则的差异：

mangle表的内容如下：

可以看到，拦截的逻辑比较简单，仅仅改了 PREROUTING （关注进入的封包）链，增加以下逻辑：

1. 对于一些特殊端口，不做拦截
2. 对于已经建立了连接的封包，直接打标记1337并允许通过
3. 对于目的地址不是127.0.0.1的封包，进行透明代理，发送给Envoy的15001监听器，给封包打标记1337

istio-init在启动工作负载之前会设置策略路由：

这保证了目的地不是127.0.0.1的封包都会被15001处理，也就是所有外部请求都需要经过Envoy处理，而Envoy向本地被代理服务转发时，会使用目的地址127.0.0.1，不会被拦截。

nat表的内容如下：

基于UID匹配的3条规则，我觉得没有意义。原因是TPROXY模式下，运行Envoy的用户是0，而非1337，这个可以从istio-sidecar-injector这个Configmap中看出来：

对nat表的更改发生在 OUTPUT 链（关注发出的封包）。核心逻辑：

1. Envoy通过lo发出的，目的地址不是127.0.0.1的封包，重定向给入站监听器。根据观察，Envoy代理外部请求后，都是从lo发给127.0.0.1的，因此不会匹配此规则
2. 允许本机的服务访问自身
3. 服务对外发出的访问，必须经过Envoy

我们仔细分析一下重定向到的15001、15006是什么东西。这些端口是istio-iptables设置的，我们看一下它的帮助：

看样子15006是需要将所有入站流量重定向到的端口，而在TPROXY中将入站流量都重定向到15001，这两端口如何分工？

这里Dump一下它们的配置。15001的：

可以看到，这个监听器非常简单，仅仅是做穿透处理。从它的名字virtualOutbound和字段trafficDirection上来看，它是用来处理从Pod向外发起的流量的。但是iptables却把入站流量发给它，似乎有些矛盾？

再看看15006的配置：

可以看到，这个监听器叫virtualInbound，从它的名字和配置trafficDirection上来看，它是用来处理从外面发给Pod的流量的，它明确的定义了处理连接的集群，127.0.0.1:80，即本地Nginx服务。 

此模式下，mangle表没有变动，Istio只修改了nat表。入站、出站流量的处理都在此完成：

可以看到，REDIRECT模式下，处理进入封包的逻辑是完全一样的。 

REDIRECT模式下，将入站流量重定向给15006，这很好理解，因为15006是 virtualInbound监听器嘛。

从Nginx的日志上看，不管是REDIRECT还是TPROXY模式，看到的IP都不是真实IP，没有区别。

Envoy访问日志也没有任何区别，至少可以说，在REDIRECT模式下，Envoy也是可以看到真实源IP的：

TPROXY模式下，Envoy也没有使用真实源IP来请求上游集群。

感觉这TPROXY很鸡肋，从https://github.com/istio/istio/issues/5679上看到的，它的价值是： 

Contrary to REDIRECT, TPROXY doesn't perform NAT, and therefore preserves both source and destination IP addresses and ports of inbound connections. One benefit is that the source.ip attributes reported by Mixer for inbound connections will always be correct, unlike when using REDIRECT.

也就是说，TPROXY模式下允许Mixer获得真实源IP地址。

目前Istio支持一种自定义资源EnvoyFilter，使用它，你可以对生成的Envoy配置进行深度定制。比如添加监听器过滤器：

像上面这个过滤器，它为入站监听器添加了envoy.listener.original_src这个监听器过滤器。生成的配置如下：

关键点：

1. 路由器发现目的地址、源地址是REAL_SERVER:80的，且不是来自透明代理的封包，都会路由给透明代理。而不是路由给服务器、客户端
2. 透明代理能够在非本机IP地址上监听，例如REAL_SERVER:80
3. 透明代理能够以非本机IP地址发起TCP连接，例如以客户端的IP地址

第一条，可能需要硬件支持。

后面两条，可以由透明代理在软件上支持，相关套接字选项：

1. IP_FREEBIND：允许绑定非本地的，或者尚不存在的IP地址
2. IP_TRANSPARENT：在套接字上启用透明代理。该选项运行应用程序绑定非本地地址，并使用这个外部地址来扮演客户端、服务器角色。需要CAP_NET_ADMIN权限才能启用

此外，根据实际需要，“透明度”可以变化：

1. 如果仅仅想让客户端觉得透明，那么代理可以直接使用自己的IP地址请求服务器。这样服务器看不到客户端真实IP
2. 如果服务器仅仅需要知道客户端真实IP，不关心真实端口，那么代理可以用客户端地址+任意端口发起请求
3. 如果需要绝对透明，则代理必须以客户端地址+客户端端口发起请求

在Envoy Sidecar部署场景下，情况变的简单，透明代理和服务器位于同一台主机内部，这意味着：

1. 不需要路由器/网关的配合
2. 代理请求的目的地址可以从真实服务器地址换为127.0.0.1

可以实现透明代理的通信模型如下：

在Istio的TPROXY拦截模式下，实际的通信模型如下：

 

差别似乎仅仅是Envoy用127.0.0.1作为源地址，而非客户端真实IP，向服务器发送请求。

使用EnvoyFilter，为virtualOutbound所引用的，80监听器配置一个EnvoyFilter，配置envoy.listener.original_src，可以让Envoy访问服务器时使用真实客户端IP，解决我们的问题吗？

我们参考3.2节配置好EnvoyFilter，然后从外部访问Pod的Nginx服务，很遗憾，并不能正常工作，curl给出的错误是：

从Envoy访问日志上看：

存在如下异常：

1. 访问上游时使用的源地址为空了
2. 响应标记UF，耗时999，提示连接不到上游服务器 

为什么连接不到上游服务器？我们尝试通过iptables日志诊断一下。在Nginx的例子里，数据报的特点是，源或目的端口为80，因此增加以下规则：

拦截到的日志：

可以看到：

1. 客户端向Pod发请求，被TPROXY给Envoy 15001
2. Envoy 15001是透明套接字，因此它虽然客户端请求的DPT=80，它也接收并处理了
3. Envoy执行代理，通过lo向127.0.0.1:80发送请求，注意这里它使用的源地址是客户端地址，这意味着我们的EnvoyFilter起作用了
4. Envoy代理的请求，通过lo入站，由于目的地址是127.0.0.1，因此不被TPROXY，通过PREROUTING - mangle链

此外，在OUTPUT链中nat表里，好像根据SPT=80无法匹配，所以看不到任何f-开头的日志。此链对于nat表来说，应该是用于做DNAT，Istio生成的规则遵循了这一点，REDIRECT可以看作是一种DNAT。Istio的规则有基于源IP进行匹配的，我基于源端口为何不行，目前不清楚。

换个位置来诊断吧，目前我们已经明确，Envoy接收到请求后，会冒充客户端源IP向localhost:80发请求，此请求已经通过PREROUTING-mangle。它有没有被Nginx接收到？

我们可以在INPUT-mangle上做日志，如果能监控到发往127.0.0.1:80的封包，就可以认定Nginx接收到了，因为整个Iptables中没有设置INPUT链的任何拦截规则。

日志如下：

nat表仍然没有日志，看样子是在DNAT时，不能使用源端口匹配，SNAT时，不能使用目的端口匹配。

不过从日志上，从lo端口进入的、Envoy仿冒客户端身份发往127.0.0.1:80的封包，的确是通过iptables了。

那么，应该是Nginx没有给出应答。我们需要监控一下源是Nginx，目的是客户端真实IP地址的出站封包的流向： 

日志如下：

相似的日志会连续出现很多条。我们可以看到Nginx收到首次握手SYN后，尝试ACK+SYN，但是一致没有收到第三次握手信息…… 原因很明显，出口网卡是eth0，封包发走了，没有返回给Envoy代理。

到这里，问题就算定位完毕了。 

我们需要保证，对于Envoy以客户端IP发起的，给Nginx的请求，它的响应能够原路返回。响应的封包具有以下特点：

1. 源地址（请求封包的目的地址）是 127.0.0.1，因为Envoy总是向127.0.0.1发请求
2. 目的地址（请求封包的源地址）不是本机地址，因为Envoy发请求时，FREEBIND源地址为客户端IP

我们需要将这种封包，从lo网卡，而非eth0路由出去。 可以使用下面的iptables规则：

再次访问服务，Nginx可以看到真实客户端IP地址了：

到此为止，问题解决。初步测试，没有发现负面效果，已经将此方案提交社区讨论。

此方案已经通过PR https://github.com/istio/istio/pull/23275 合并到上游Istio仓库的master分支（1.7dev），并将自动Cherry Pick到1.6版本。

1.5版本的逻辑稍有不同，仅仅在我Fork的Istio中实现：https://github.com/gmemcc/istio/tree/release-1.5.1-patch，不准备提交到上游Istio仓库。

在此版本中验证时，发现TPROXY模式损坏，无限循环自我请求。我已经提起Issue：23369。

解决无限循环的方法是把TPROXY目标从15001改为15006。我一直就怀疑为什么要把入站流量重定向给出站监听器15001，现在想想，最初只有一个“虚拟监听器”15001，最近版本的Istio才拆分为virtualInbound（15006）、virtualOutbound（15001）两个，在这个变更过程中，TPROXY相关代码没有跟着改动。

解决透明代理源IP的PR 23275并没有达到预期效果，问题原因参考ISSUE 23369。

即使按照上节的方法，将TPROXY目标从15001改为15006，也仅仅能解决无限自我请求的问题。新得到的错误信息是：upstream connect error or disconnect/reset before headers. reset reason: local reset

我们从10.0.0.1发起针对启用了Sidecar的、IP地址为172.27.0.10的请求。可以在Nginx Pod的网络命名空间中看到如下连接信息：

源地址为10.0.0.1:50829套接字，应该是Envoy发起上游请求时创建的，因为我们配置了监听器过滤器original_src。

但是，这个套接字的状态一直是SYN_SENT，这提示它没有收到答复。结合抓包结果：

可以看到，新版本的Istio，向上游发请求时，使用的目的地址是原始Dest地址，而不是127.0.0.1，因此， PR 23275也就失效了。

在当前的场景下，Envoy以客户端真实IP、通过lo向Nginx进程发起TCP连接，这个是OK的。但是回程报文从容器eth0发走了。回程报文到达宿主机后，被丢弃。

我们需要识别，哪些请求是Envoy代表客户端转发的，并把这些请求的响应封包发回给Envoy，而不是通过eth0发送出去。

早前版本可以根据目的地址识别，现在直接来自客户端的、Envoy代表客户端转发的请求（以及响应），连接5元组完全一样，这意味着无法从IP地址上进行区分了。

幸运的是，iptables支持的CONNMARK目标可以在连接级别上打标记，这意味着往返报文可以共享信息。此外，original_src支持为封包设置标记，我们可以利用这一特性识别Envoy代表客户端发出的封包。结合这两点，我们可以得到23369的解决方案。

首先，我们需要为监听器过滤器original_src增加一个参数：

这样，Envoy请求上游（Nginx）时，发出的封包具有标记 1337。

然后，我们增加如下iptables规则：

结合现有的策略路由，Nginx的回程封包就会从lo发出，并被Envoy接收到了。

到这一步，会出现先前的无限自我请求问题，这是由于规则：

该规则要求，只要目的地址不是127.0.0.1的请求，都会重定向到15006。在前面我们已经发现，TPROXY模式下访问上游Nginx不像先前版本那样使用127.0.0.1作为目的地址，因此这个规则必须要处理。

我的做法是，在它的前面做个判断，如果具有标记1337（意味着这是Envoy和上游Nginx之间的通信），就不走ISTIO_TPROXY：

修改后mangle表的整体内容如下：

从Nginx Pod外部访问、从Nginx Pod内部访问localhost以及Pod IP，一切行为正常，解决方案有效。 

此方案将通过PR 28363提交社区讨论。