Comments on: Istio中的透明代理问题

By: qg

qg — Wed, 31 May 2023 07:38:39 +0000

我有一个问题是这里面的envoy是要注入到POD内部的，假设不允许注入POD内部，那么有没有办法实现这种透明代理模式呢？

point — Tue, 26 Jul 2022 06:27:21 +0000

redirect才需要conntrack表，tproxy不需要

Tue, 08 Feb 2022 03:30:45 +0000

透传 src ip 基于 connmark，还是会有 ct table full 的场景吧

point — Tue, 11 Jan 2022 12:50:17 +0000

tproxy一个比较大的好处就是不用nat表，不会出现contrack over了

Alex — Thu, 06 May 2021 03:23:14 +0000

先前的版本，不管是REDIRECT还是TPROXY模式，Envoy向上游（当前Pod）转发请求的时候，都不是使用原始请求的源IP，而是用127.0.0.1。这是因为上游和Envoy在同一个网络命名空间内，使用127.0.0.1是默认行为。

不管是REDIRECT还是TPROXY模式，Envoy都有能力得到原始请求的源IP，并且使用此IP作为source ip向上游发起请求（IP_TRANSPARENT）。

根据大家对TPROXY（透明代理）的行为的一般性期望，它应当让C/S端都感觉不到Proxy的存在。因此有了相关的Issue和PR

will — Fri, 30 Apr 2021 08:20:22 +0000

will — Fri, 30 Apr 2021 08:19:32 +0000

您好，请问什么时候redirect也会改变source ip? 我的理解包括自己的测试都是只改destination的port. 但是这个issue中却说有可能会改ip。谢谢！

Alex — Mon, 28 Sep 2020 02:01:40 +0000

TPROXY模式最近几个版本一直有问题，我也提了Issue，不过没人响应:(

Yann — Sun, 27 Sep 2020 13:58:10 +0000

您好，我是从Github找到您的Blog，非常详细的文章，谢谢。我在做基本测试中，发现了一个问题，已经开了一个issue，https://github.com/istio/istio/issues/27565，是关于service to service call的。

Alex — Mon, 27 Apr 2020 14:24:12 +0000

值得注意的一点，1.6版本的监听器结构有很大变化，它将所有入站监听器都聚合到单个virtualInbound中，作为它的过滤器链，现在virtualInbound是唯一的INBOUND监听器。