如何访问 NAT 后面的 Web 服务？
我们有一个产品正在部署到一些小型企业。它基本上是一个使用 Tomcat 的基于 SSL 的 RESTful API。它安装在小型企业的服务器上，并通过 iPhone 或其他便携式设备进行访问。因此，连接到服务器的设备可以来自任意数量的 IP 地址。
问题来自于安装。当我们安装这个服务时，在进行端口转发以便外界能够访问tomcat时似乎总是会出现问题。似乎大多数时候所有者都不知道路由器密码等。
我正在尝试研究其他方法来实现这一点。我提出了以下内容，并想听听有关该主题的其他想法。
设置从每个客户端办公室到中央服务器的 SSH 隧道。基本上，远程设备将通过端口连接到该中央服务器，并且该流量将通过隧道传输回办公室中的 Tomcat。先使用 SSH，然后使用 SSL 似乎有点多余，但实际上没有其他方法可以实现它，因为端到端我需要 SSL（从设备到办公室）。不确定这里的性能影响，但我知道它会起作用。需要监控隧道并在完成后将其恢复，需要处理 SSH 密钥交换等。
设置 uPNP 来尝试为我配置该漏洞。大多数情况下可能会有效，但 uPNP 不能保证一定会打开。可能是一个很好的下一步。
提出某种类型的 NAT 穿越方案。我只是不熟悉这些并且不确定它们到底是如何工作的。我们可以访问身份验证所需的集中式服务器（如果这样可以更容易的话）。
为了实现这一目标，我还应该注意什么？
We have a product we are deploying to some small businesses. It is basically a RESTful API over SSL using Tomcat. This is installed on the server in the small business and is accessed via an iPhone or other device portable device. So, the devices connecting to the server could come from any number of IP addresses.
The problem comes with the installation. When we install this service, it seems to always become a problem when doing port forwarding so the outside world can gain access to tomcat. It seems most time the owner doesn't know router password, etc, etc.
I am trying to research other ways we can accomplish this. I've come up with the following and would like to hear other thoughts on the topic.
Setup a SSH tunnel from each client office to a central server. Basically the remote devices would connect to that central server on a port and that traffic would be tunneled back to Tomcat in the office. Seems kind of redundant to have SSH and then SSL, but really no other way to accomplish it since end-to-end I need SSL (from device to office). Not sure of performance implications here, but I know it would work. Would need to monitor the tunnel and bring it back up if it goes done, would need to handle SSH key exchanges, etc.
Setup uPNP to try and configure the hole for me. Would likely work most of the time, but uPNP isn't guaranteed to be turned on. May be a good next step.
Come up with some type of NAT transversal scheme. I'm just not familiar with these and uncertain of how they exactly work. We have access to a centralized server which is required for the authentication if that makes it any easier.
What else should I be looking at to get this accomplished?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
该服务是否无法由您或托管提供商公开托管，而不是由客户托管？
我在开发自助终端时也遇到过类似的情况。我从来不知道下次安装时我必须处理什么类型的网络环境。
我最终创建了一个 PPTP VPN，以允许所有信息亭连接到我公开托管的一台服务器。然后，我们创建了一个控制器 Web 服务，以公开对所有通过 VPN 连接的信息亭的访问。我不确定您对 VPN 有多熟悉，但通过 VPN 连接，我能够通过 VPN 分配的 IP 访问信息亭，从而完全绕过每个信息亭前面的防火墙。
一旦我设置了 VPN 服务器，每个信息亭节点的设置都非常容易。它还带来了我原本没有想到的管理收益和授权收入。有了这个基础设施，我就可以轻松推出通过手机访问的服务。
祝你好运！
Is there no way this service can by hosted publicly by you or a hosting provider rather than with the customer?
I had a similar situation when I was developing kiosks. I never knew what type of network environment I'd have to deal with on the next installation.
I ended up creating a PPTP VPN to allow all the kiosks to connect to one server I hosted publicly. We then created a controller web service to expose access to the kiosks that were all connected via the VPN. I'm not sure how familiar you are with VPN's but with the VPN connection I was able to completely circumvent the firewall in front of each kiosk by accessing the kiosk via the VPN assigned IP.
Each kiosk node was incredibly easy to setup once I had a VPN server setup. It also brought management benefits and licensing revenue I originally didn't think about. with this infrastructure I was easily able to roll out services accessible via mobile phones.
Best of luck!
存在“动态”访问 NAT 后面计算机上的软件的解决方案，但通常主要用于 UDP 通信。
UDP 打洞技术就是其中之一。然而，这并不能保证在所有可能的情况下都有效。如果通信双方都位于“对称锥体 NAT”后面，则不会。
显然，您可以使用 UPnP 作为备份（甚至主要）替代方案来降低客户端无法通信的可能性。
我对 Web 服务了解不够，甚至不知道为您的 Web 服务使用 UDP 是否是一种选择（或者是否可能）。
直接对 TCP 使用相同的技术可能会失败（TCP 连接不是无状态的 - 这会导致很多问题）。
使用相同技术的另一种方法是设置一些基于 UDP 的 VPN（就像 OpenVPN），但作为您说过，您必须管理密钥、证书等。这可以自动化（我做到了），但它仍然不是微不足道的。
===编辑===
如果您确实想使用 TCP，您可以在客户端上创建一个简单的“代理”软件来充当中继。
您将具有以下架构：
另一种选择：您可能会要求代理软件直接连接到请求者以增强性能，但随后您可能会遇到您试图避免的相同 NAT 问题。
Solutions exist to "dynamically" access a software on a computer behind a NAT, but usually mostly for UDP communication.
The UDP hole punching technique is one of them. However, this isn't guranteed to work in every possible situation. If both sides of the communication are behind a "Symmetric Cone NAT" it won't.
You obivously can reduce the probability a client can't communicate using UPnP as a backup (or even primary) alternative.
I don't know Web Services enough and don't even know if using UDP for your webservice is an option (or if it is even possible).
Using the same technique for directly TCP is likely to fail (TCP connections aren't stateless - that causes a lot of problems here).
An alternative using the same technique, would be to set up some VPN based on UDP (just like OpenVPN), but as you stated, you'll have to manage keys, certificates, and so on. This can be automated (I did it) but still, it's not really trivial.
===EDIT===
If you really want to use TCP, you could create a simple "proxy" software on the client boxes which would serve as a relay.
You would have the following schema:
An alternative: you might ask the proxy software to directly connect to the requester to enhance performance, but then you might encounter the same NAT problems you're trying to avoid.
正是这样的事情，就是人们现在通过 http 来传输所有内容的原因，也是某些硬件供应商为第 7 层数据包过滤收取一大笔费用的原因。
当客户至少遇到三个问题时，解决一个问题的工作量是巨大的。除了您确定的密码之外，如果他们不知道自己的密码，那么谁知道呢？不再在那里工作的管理员？这是一个问题。
其次，如果他们不知道密码，这意味着他们几乎肯定在防火墙固件更新方面远远落后。
我认为他们应该认真考虑在防火墙上进行 PROM 重置并从头开始重新配置（并在此时升级固件）。
三只鸟，一块石头。
It's things like this that are the reason people are tunneling everything over http now, and why certain hardware vendors charge a small fortune for Layer 7 packet filtering.
This is a tremendous amount of work to fix one problem when the customer has at least three problems. Besides the one you've identified, if they don't know their own password, then who does? An administrator who doesn't work there anymore? That's a problem.
Second, if they don't know the password, that means they're almost certainly far behind on firmware updates to their firewall.
I think they should seriously consider doing a PROM reset on their firewall and reconfiguring from scratch (and upgrading the firmware while they're at it).
3 birds, one stone.
我过去必须做类似的事情，我相信
最好的选择是您提出的第一个选择。
您可以通过简单的方式进行操作，使用 ssh 及其 -R 选项，使用
公钥身份验证和几个要检查的脚本
连接性。不要忘记各种保活和超时
ssh 的特点。
不用担心表演。使用非特权用户和端口
如果可以的话。不用费心去设置CA，每个远程的公钥
服务器更容易维护，除非您有数千人。
监控非常简单。每个服务器都应该测试其上的服务
中央服务器。如果失败，则隧道已关闭或没有连接。
无论如何，重新启动隧道不会造成任何损害。
或者您可以使用 IPsec (strongswan) 在网络级别执行此操作。
这设置起来可能比较棘手，这是我使用的选项，但我会
下次使用 SSH，这会节省我很多时间。
I had to do something similar in the past and I believe
the best option is the first one you proposed.
You can do in the easy way, using ssh with its -R option, using
publick key auth and a couple of scripts to check for
connectivity. Don't forget the various keep alive and timeout
features of ssh.
Don't worry about the performances. Use unprivileged users and ports
if you can. Don't bother to setup a CA, the public key of each remote
server is easier to maintain unless you are in the thousands.
Monitoring is quite simple. Each server should test the service on the
central server. If it fails either the tunnel is down or there's no connectivity.
Restarting the tunnel will not harm in any case.
Or you can do it at the network level, using IPsec (strongswan).
This can be trickier to setup and it's the option I used but I will
use SSH the next time, it would have saved me a lot of time.
+1 用于使用 SSH 隧道。它众所周知、广泛使用并且配置起来并不难。
但是，正如您所指出的，您已经在运行 SSL，因此 SSH 加密是多余的。除了 SSH，您还可以使用常规的隧道代理，它提供无需加密的隧道。我过去曾使用过这个，而且效果很好，尽管我没有对它进行负载测试 - 它只被少数用户使用。
这是某人使用隧道代理从防火墙外部访问其网络摄像头的博客。
+1 for going with a SSH tunnel. It's well known, widely available and not too hard to configure.
However, as you point out, you are running SSL already, so the SSH encryption is redundant. Instead of SSH you could just use a regular tunneling proxy, that provides the tunnelling without the encryption. I've used this one in the past, and it has worked well, although I didn't load test it - it was used with just a handful of users.
Here's a blog from someone who used the tunnelling proxy to access his webcam from outside his firewall.
在 Tomcat 前面设置一个 Apache。这个 Apache 应该可以从互联网上看到，而 Tomcat 则不应该。
配置 Apache 将所有流量转发到 Tomcat。这可以使用 mod_proxy 轻松完成（查看 ProxyPass 和 ProxyPassReverse指令）。
将 SSL 证书放置在 Apache 中，以便所有客户端都可以与 Apache 服务器进行 HTTPS 通信，而 Apache 服务器又与 Tomcat 进行普通 HTTP 通信。
没有隧道或其他讨厌的东西+你会惊讶地发现配置 Apache 来做到这一点是多么容易。
Set up an Apache in front of your Tomcat. This Apache should be visible from the internet, where the Tomcat should not.
Configure Apache to forward all traffic to the Tomcat. This can easily be accomplished using mod_proxy (check out the ProxyPass and ProxyPassReverse directives).
Have your SSL certificate located in the Apache, so that all clients can talk HTTPS with the Apache server, which in turn talks plain HTTP with Tomcat.
No tunneling or other nastyness + you will be surprised how easy it is to configure Apache to do this.
如果您想要与客户端服务器进行 RESTful 集成，那么作为代理运行的到中央服务器的隧道似乎是最好的方法。
但如果这不是硬性要求，您可以让中央服务器处理RESTfull内容，并将中央服务器和客户端服务器与其他服务器集成中间件。 RMI 或 JMS 是不错的选择。例如，客户端发起的 RMI 连接允许服务器对客户端进行 RMI 调用。
If you want to have a RESTful integration to the client server, a tunnel to the central server that works as a proxy, seems the best approach.
But if this is not a hard requirement, you can let the central server handle the RESTfull stuff and integrate the central server and client server with other middleware. Good candidates would be RMI or JMS. For example, a RMI connection initiated by the client allows the server to do RMI calls to the client.
您可以尝试连接到 PC/服务器并通过 hamachi（免费 VPN 软件）隧道传输所有数据，因为您可以安装此工具，它将创建反向连接（从 nat 内部到外部），以便您可以连接到该
站点: http://hamachi.cc/
You could try to connect to an pc/ server and tunnel all the data via hamachi (Free VPN Software) because this tool you can install and it will create a reverse connection (from inside your nat to outside) so you can connect to it
site: http://hamachi.cc/