本文详细介绍了Envoy作为Istio服务网格中的核心组件，如何通过边车模式进行流量劫持。重点讲解了iptables的REDIRECT和TPROXY两种拦截模式，以及它们在网络流量处理中的应用场景。文中还提到了iptables的配置示例，展示了如何通过iptables规则实现入站和出站流量的劫持，并讨论了iptables的conntrack模块在高并发场景下的问题。此外，文章探讨了Envoy流量劫持对于服务端的影响和解决办法，以及Istio对DNS流量的特殊处理。最后，简要提到了Envoy在网关模式下的不同工作方式。
前言
Envoy 是一款面向 Service Mesh 的高性能网络代理服务。它与应用程序并行运行，通过以平台无关的方式提供通用功能来抽象网络。当基础架构中的所有服务流量都通过 Envoy 网格时，通过一致的可观测性，很容易地查看问题区域，调整整体性能。
Envoy也是istio的核心组件之一，以sidecar的方式与服务运行在一起，对服务的流量进行拦截转发，具有路由，流量控制等等强大特性。本系列文章，我们将不局限于istio，envoy的官方文档，从源码级别切入，分享Envoy启动、流量劫持、http请求处理流程的进阶应用实例，深度分析Envoy架构。
本篇将是Envoy请求流程源码解析的第一篇，主要分享Envoy的流量劫持。
边车模式
在Istio当中, envoy运行有两种模式，分别为边车模式和代理模式。
其中边车模式为通过 iptable 进行流量劫持
拦截模式
Istio 支持两种拦截模式：
-
REDIRECT：使用iptables的REDIRECT目标来拦截入站请求，转给Envoy，从Linux2.6.15的内核版本后，iptables开始支持状态跟踪(conntrack)，该功能依赖于netfilter的内核模块nf_conntrack。此后，iptables可以根据包的状态进行二次的过滤拦截和状态跟踪。它也是state/ctstate和nat的主要依赖模块。
-
TPROXY：使用iptables的TPROXY目标来拦截入站请求，tproxy 可以用于 inbound 流量的重定向，且无需改变报文中的目的 IP/端口，不需要执行连接跟踪，不会出现 conntrack 模块创建大量连接的问题。受限于内核版本，tproxy 应用于 outbound 存在一定缺陷。目前 Istio 支持通过 tproxy 处理 inbound 流量。
可以全局的设置默认拦截模式，也可以通过sidecar.istio.io/interceptionMode(http://sidecar.istio.io/interceptionMode): TPROXY 给某个工作负载单独设置。
无论采用哪种透明劫持方案，均需要解决获取真实目的 IP / 端口的问题，使用 iptables 方案通过 getsockopt 方式获取，tproxy 可以直接读取目的地址。
关于trpoxy
https://github.com/istio/istio/issues/5679
关于netfilter和conntrack
https://serverfault.com/questions/1030236/when-does-iptables-conntrack-module-track-states-of-packets
关于为什么istio考虑inbound支持tproxy模式
如果我们是服务端，那么 SYN 包到达的时候，在 POSTROUTING 链的 NAT 表执行过之后（可能做 DNAT 或者 REDIRECT），路由表将决定是 FORWARD 还是
最低0.47元/天 解锁文章
扫一扫
658
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
