服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 通过VPN提供公共访问本地Web服务器
Intereting Posts
为什么Chrome在这个证书上信任相同的权限，而不是其他的？ 我如何删除旧的日志文件？ 将EC2server映像存储在存储桶“子文件夹”中 select正确的服务器机架宽度 屏幕-R不工作与SSH 从vbox config创build一个kvm / qemu虚拟机…networking适配器configuration？ 根DNS服务器 Exchange Server自动转发电子邮件 2008年2月DC上的Windows 7账户被随机locking 任何版本的ModSecurity都可以与最新版本的Nginx一起使用？ 使托pipe在本地主机上的网站可在networking上使用 我需要DNSSEC吗？ 为什么Linux内核中的OpenVZ默认不是？ 在CentOS中将单独的/ var和交换驱动器合并回驱动器 NGinx重写规则和发布参数

通过VPN提供公共访问本地Web服务器

我有一个build立在两个服务器之间的VPN隧道：VPS-A和VPS-B，虚拟公共IP地址分别为66.55.44.33和77.88.55.66，VPN端点分别为10.0.1.1和10.0.2.1。

在VPS-A上运行Web服务器。 我可以没有问题SSH到VPS-B，并通过curl向10.0.1.1发出HTTP请求时收到响应，例如： 

curl http://10.0.1.1/

我也可以在连接到互联网的任何给定计算机上打开浏览器并成功打开 

 http://66.55.44.33/

…但是我也想通过发送一个请求到VPS-B（即VPS-A）来到达VPS-A的networking服务器 

 http://77.88.55.66/

现在，我在VPS-B上添加了以下规则（ 编辑显示正确的规则 ） 

 iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 10.0.1.1:80

…当我在端口80上做一个tcpdump ，我可以清楚地看到http://77.88.55.66/请求是如何正确地转发到http://10.0.1.1 。 但是，VPS-A上的Web服务器似乎没有确认TCP请求。 以下是tcpdump显示的内容： 

 2013-04-27 03:45:15.001564 IP 45.248.82.171.51377 > 10.0.1.1.80: S 791893048:791 2013-04-27 03:45:15.252571 IP 45.248.82.171.51378 > 10.0.1.1.80: S 670490211:670 2013-04-27 03:45:18.001526 IP 45.248.82.171.51377 > 10.0.1.1.80: S 791893048:791 2013-04-27 03:45:18.258666 IP 45.248.82.171.51378 > 10.0.1.1.80: S 670490211:670

..而对于通过VPN的请求： 

 2013-04-27 04:26:57.464859 IP 10.0.2.1.33258 > 10.0.1.1.80: S 2369100373:2369100373(0) win 5744 <mss 1436,sackOK,timestamp 121795122 0,nop,wscale 7> 2013-04-27 04:26:57.464913 IP 10.0.1.1.80 > 10.0.2.1.33258: S 3524730589:3524730589(0) ack 2369100374 win 5744 <mss 1436,nop,nop,sackOK,nop,wscale 7> 2013-04-27 04:26:57.532428 IP 10.0.2.1.33258 > 10.0.1.1.80: . ack 1 win 45

我对Linux非常陌生，所以我确信我没有做正确的事情，但我不知道究竟是什么。 我试图寻找类似的问题，但我没有find任何东西。 如果有人能指点我一个有用的资源，或给我一个实际的例子 – 这将是伟大的。

感谢您阅读我的文章！

您的描述必须不完整。 INPUT和FORWARD中的规则不会使77.88.55.66的数据包转到10.0.1.1。 只有nat表的PREROUTING链中的DNAT目标才有可能。 显然有这样一个规则。

对于成功的redirect，无论如何都不需要INPUT中的规则，因为这些数据包不会被redirect系统接收到。

与没有SNAT的DNAT的问题（就像你的情况一样）是系统通常不关心它在路由答案时到达了哪个接口。 你的VPS-A看到一个从45.248.82.171开始的连接，如果它愿意与那个客户进行通信，那么它发送一个响应 – 是，45.248.82.171。 客户端发送了一个SYN数据包到77.88.55.66，并从66.55.44.33收到一个SYN ACK，显然只是认为WTF？ 为什么从66.55.44.33？ 因为答复没有通过隧道发送，因为VPS-A的路由configuration告诉它不要通过隧道向这个目的地发送数据包。 如果他们通过隧道返回，那么VPS-B会将源地址重写为自己的地址，一切都会好起来的。

所以你要么使用iptables来标记通过隧道的连接（为什么要通过隧道？），重写连接标记到一个包标记，并使用带有这个包标记的高级路由来通过隧道发送这些包。 或者你做NAT的双方，在通过隧道从VPS-B发送它们之前做SNAT，并从VPS-A中简单地取回它们。 缺点：networking服务器日志显示“错误”的IP地址（总是10.0.2.1）。

BTW：10.0.2.1和10.0.1.1是同一个VPN的奇怪的终点地址，不是吗？