UDP打洞
我有一些关于 UDP 打洞的问题。基于wiki http://en.wikipedia.org/wiki/UDP_hole_punching
1) 设置在两方（位于 NAT 后面的客户端，位于非 NAT 的服务器）之间建立 UDP 会话，客户端是否只需向服务器发送一个数据包，然后通过以下方式允许双向（发送和接收）会话：防火墙？这意味着客户端也可以从服务器接收。
2) UDP 打洞：两个客户端首先连接到服务器，然后服务器将客户端端口/IP 提供给其他客户端，以便客户端在这些端口上相互发送数据包。这是正确的吗？
3) 如果#2 为真，为什么防火墙允许从另一个 IP 接收数据，而不是在该端口上建立连接所使用的 IP？听起来像是一个应该很容易过滤的大安全漏洞？我知道源 IP 欺骗会欺骗它，但是这个呢？
提前致谢， 约翰
I've got some questions regarding hole punching with UDP. Based on the wiki http://en.wikipedia.org/wiki/UDP_hole_punching
1) To set up a UDP session between two parties (the client which is behind NAT, server which is non-NAT) does the client simply have to send a packet to the server and then the session is allowed both ways (send & receieve) through the firewall? Meaning the client can receive too from the server.
2) UDP Hole punching: Two clients first conenct to the server, then the server gives a client port / ip on to other clients, so the clients send packets to each other on those ports. Is this coorrect?
3) if #2 is true, Why would firewalls allow data to be received from another IP than the one used in making the connection on that very port? Sounds like a big security hole that should easly be filtered? I understand that source IP spoofing would trick it, but this?
Thanks in advance,
Johan
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
1）是的，使用最合理的防火墙，除非您以极其偏执的模式配置它。
2）不完全是。 这篇文章更详细地解释了这一点，但其想法是，其中一个客户端首先向对方的公共IP发送数据报。然后这个数据报被丢弃，但另一个客户端知道它已被发送，因为第一个客户端通过服务器告诉它。然后，另一个客户端将数据报发送回第一个客户端，该端口与第一个数据报源自的端口相同。由于第一个客户端的 NAT 会记住有来自该端口的数据包，因此它认为传入的数据报是对第一个数据报的回复。这里的问题是弄清楚 NAT 将选择哪个公共端口发送第一个数据报，但大多数 NAT 以可预测的方式执行此操作，因此它几乎总是工作正常，有时只是不是从第一次尝试开始。
1) Yes, with most reasonable firewalls, unless you configure it in extremely paranoid mode.
2) Not exactly. This article explains it in more detail, but the idea is that one of the clients first sends a datagram to the other's public IP. Then this datagram is discarded, but the other client knows that it was sent because the first one told it through the server. Then the other client sends a datagram back to the first one to the same port from which the first datagram originated. Since NAT at the first client remembers that there was a packet from that port, it considers the incoming datagram to be a reply to the first one. The problem here is to figure out which public port NAT will choose to send the first datagram, but most NATs do it in a predictable way so it almost always works fine, sometimes just not from the first try.
1）是的。但是，如果您要联系非 NAT 的服务器，则不需要打洞。您的客户端应用程序运行正常。
2）是的。
3) 某些 NAT 确实将公共端口限制为仅一对发送者-接收者。如果您需要在这种情况下打洞，您唯一的机会就是猜测 NAT 将选择用于直接连接的公共端口。
但是，NAT 不是一项安全功能。因此，接受任何到公共端口的数据包并不是安全漏洞，因为与客户端直接连接到互联网的简单情况没有区别。
1) Yes. However, you don't need hole punching if you're contacting a non-NATted server. Your client application just behaves normally.
2) Yes.
3) Some NATs do indeed restrict a public port to just one sender-receiver pair. If you need to hole-punch in such a scenario, your only chance is to guess the public port the NAT will choose for the direct connection.
However, NAT is not a security feature. Therefore, accepting any packets to the public port is not a security hole as there is no difference to the simple case of a client directly connected to the internet.