我有一个用2个网卡设置的linux盒子来检查通过端口80的stream量。一个网卡用于上网，另一个网卡连接到networking交换机。 重点在于能够检查连接到该交换机的设备上的所有HTTP和HTTPSstream量，以用于debugging目的。
我已经写了iptables的以下规则：
nat -A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.2.1:1337 -A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 1337 -A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE 在192.168.2.1:1337，我有一个透明的http代理使用Charles（ http://www.charlesproxy.com/ ）进行录制。
一切正常的端口80，但是当我添加端口443（SSL）指向端口1337类似的规则，通过查尔斯我得到关于无效消息的错误。
我之前在Charles使用过SSL代理（ http://www.charlesproxy.com/documentation/proxying/ssl-proxying/ ），但由于某种原因，透明地进行操作并不成功。 我search的一些资源说它不可能 – 如果有人能解释为什么，我愿意接受这个答案。
作为说明，我可以完全访问所描述的设置，包括连接到子网的所有客户端 – 所以我可以接受Charles的自签名证书。 从理论上讲，解决scheme不一定是查尔斯特有的，任何透明的代理都可以。
谢谢！
编辑：玩了一下后，我能够得到它为一个特定的主机工作。 当我将我的iptables修改为以下（并在反向代理的charles中打开1338）时：
nat -A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.2.1:1337 -A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 1337 -A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.2.1:1338 -A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 1338 -A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE
我能够得到答复，但没有目标主机。 在反向代理中，如果我只是指定从1338开始的所有内容到我想要访问的特定主机，它都会正确执行手动操作，并且可以打开SSL代理来检查通信。
设置是不太理想的，因为我不想从1338到所有主机 – 任何想法为什么目标主机被剥离？
再次感谢
您看到的问题与阻止在单个IP地址/端口上使用多个证书（不使用“服务器名称指示”）相同 。
在普通的HTTP中，透明代理可以通过查看Host头来告诉客户端想要连接哪个主机。
当HTTPS MITM透明代理获取请求时，首先无法知道客户端正在请求哪个主机名。 （我甚至不确定它是否可以使用这些规则获取IP地址，这可能至less可以使用反向DNS查找来进行猜测，尽pipe在一般情况下它不太可能工作）。
Host头，这只能在成功的握手之后进行。 因此，MITM代理无法知道在握手之前要生成哪个证书。
这可以与一个不透明的MITM代理一起工作，因为你至less可以通过HTTP CONNECT方法获得预期的主机名。
只是一些关于这个话题的基本信息。
我所知道的只有less数设备可以成功地完成这个动作。 然而，他们并不是普通公众所能得到的。 我自己正在使用带有SSL卸载function的Fortinet Fortigate。
它基本上是做什么的; 它拦截与主机build立的SSL连接，并以硬件解密连接，然后检查你想要去的地方，根据这些信息做出防火墙决定。
之后，它build立自己的连接到该主机以检索数据，并使用用户提供的CA重新签署原始请求给客户端。 为了使这项工作顺利进行，需要在客户端的可信根CA中拥有CA.
这些设置被用于组织来执行公司关于互联网使用的政策。 由于使用Active Directory很容易将您的公司CA安装到客户端，这对大型组织来说不成问题。
这是您可以在不创build手动代理的情况下执行此操作的唯一方法，因为SSLstream量是encryption的。 它基本上是一个MITM，因此有任何法律问题是很重要的。
关于另一个问题，您可能已经看到了一些更多的build议： 透明的SSL代理神话和事实 。 这个链接解释了如何将Squidconfiguration成一个透明的SSL代理。 这不是你正在寻找的东西，但它至less可以让你了解可能出现的问题。
iptables规则似乎没问题，但我不知道你使用的代理软件是否能够做你想做的事情。 文件当然声称是这样的。
为了增加Bruno的解决scheme，我调查了一下，想分享一下如何得到另一个不太理想的快速解决scheme。
设置好这些iptables之后，我可以在1338端口上放置一个反向代理，并通过端口1337将其转发到本地主机。由于端口1337是一个透明的http代理，并且数据已经被解密，所以它将把主机头部作为目的地主办。
主要的缺点是，我已经基本上将https连接转换为http – 并不总是与每个服务器一起工作（更不用说我公开的安全漏洞）。
我正在从我的软件的范围内工作。 我认为根据Bruno的观点，一个更清洁的解决scheme应该是假设所有来自1338的stream量都应该被解密。 解密后，检查目标主机，然后使用SSL代理请求。