SOCAT 重定向 UDP 不起作用！
我正在尝试将 UDP 数据报中的数据传输到外部位置的客户端到本地 LAN 中的 PC。 但我的网络是通过 ADSL 调制解调器发送到带有 Slackware 的电脑，该电脑将包重定向到其他电脑。 我正在使用 socat 重定向 UDP：
socat -v udp-listen:1935,fork,reuseaddr udp:192.168.0.40:37000
在 LAN 中连接正常，但外部 IP 不起作用。 有人帮忙吗？
I'm trying to transmit data in UDP datagrams into a client in external location to a pc in my local lan.
But my network is over a ADSL modem sending to a pc with Slackware, this pc redirect packages into other pcs.
I'm using socat to redirect UDP:
socat -v udp-listen:1935,fork,reuseaddr udp:192.168.0.40:37000
In LAN the conection is fine, but external IPs don't work.
Somebody help?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不认为
socat是罪魁祸首，但是请考虑使用stone而不是socat，因为使用fork()< /code> 对于每个收到的数据包都有点奇怪。 Stone 在您的情况下被称为这样（我认为）：stone -n -d -d -d -d 192.168.0.40:37000/udp 1935/udp现在为什么外部 IP 可能不起作用。遗憾的是，您的文本没有透露太多有关您的设置的信息，所以我不得不猜测：
如果能够转发 UDP 数据包，这取决于您的防火墙/调制解调器/路由器。通常，如果您从内部发起 UDP 请求，路由器将打开 NAT 连接，这通常意味着不仅数据包的源 IP 发生变化，而且源端口也会发生变化。由于 UDP 是无连接的，因此如果没有数据传输，UDP NAT 连接通常会很快超时，例如 5 分钟后。
如果必须在相反方向（从 Internet 到 Intranet）打开 UDP，则路由器通常会丢弃所有从 Internet 传入的 UDP 数据包，因为它不知道将它们转发到哪里。路由器不能只选择某个任意机器，这将是一个安全漏洞。所以在“Internet连接到路由器后面的机器”中你必须打开路由器上的UDP端口并让它转发到正确的机器。在这种情况下，从内部机器发送的数据包将被重写其源 IP 和源端口，互联网上的机器始终会将数据包视为来自您的路由器。因此，除了路由器中的附加规则之外，此情况与传出情况相同。
请注意，有几种不同的方法可以实现 NAT（对称等），并且有多种方法可以在路由器上打开端口（配置、UPnP 等），因此如何在其中插入漏洞始终取决于您的情况。硬件能力。这一切都无法在这里得到解答。
其他一些可能出错的想法：
一些 UDP 协议在有效负载中对 IP 地址进行编码。在这种情况下，仅转发数据包是不够的，您还必须更改有效负载以更正交换的 IP 地址，以使所有计算机能够一起通信。不管怎样，这样的 UDP 协议设计得很糟糕，因为你永远不应该假设两台任意机器可以直接相互通信，所以所有好的协议都应该支持简单的代理。
某些 ISP 出于任意原因过滤某些 UDP 端口。如果您在从 Internet 与 DSL 通信时遇到问题，请尝试使用直接连接到不同 ISP 的两台外部计算机。如果这些可以通过 UDP 进行通信，请检查您是否可以从 Intranet 与其中一台外部计算机进行通信。如果这仍然有效，这意味着您也可以向后通信，因为通常 UDP 不是定向协议，但如果涉及某些 NAT，您必须以某种方式确保通信端口保持开放。
移动互联网套餐通常不支持 P2P。这可能意味着，这些计划根本不支持互联网，因为IP，根据定义，是P2P。 ISP 真正想说的“禁止 P2P”是（我的猜测），即不支持从互联网到移动设备的连接。在这种情况下，您始终必须从移动设备发起连接，因此您无法使用推送方法（互联网到移动设备），移动设备始终必须拉取（来自互联网的数据）。一些宽带/有线电视提供商可能也会这样做。通常，如果您的 ISP 向您提供 10.xyz 范围内的 IP，您就会看到这一点。
可能还有另一个技巧可以让连接正常工作：
请您的 ISP 获取一些 IPv6。也许使用 6to4。使用 IPv6，您可以完全消除 NAT，然后您的本地 LAN 可以直接互连到 IPv6 上的互联网。请务必在 IPv6 接口上激活 Intranet 主机上的防火墙/iptables，否则您可能很快就会发现入侵者。
华泰
I don't think
socatis the culprit, however consider to usestoneinstead ofsocat, because using afork()for each received packet is a bit weird. Stone is called in your case like this (I think):stone -n -d -d -d -d 192.168.0.40:37000/udp 1935/udpNow why external IPs perhaps do not work. Sadly your text does not tell much about your setup, so I have to guess:
It depends on your firewall/modem/router if it is able to forward UDP packets. Usually, if you initiate the UDP requests from the inside, the router will open a NAT connection, which often means, that not only the source IP of the packets change, but the source port as well. As UDP is connectionless, UDP NAT connections usually time out very quickly, say after 5 minutes, if no data is transferred on them.
If the UDP must be opened in the opposite direction (from Internet to Intranet), the router usually discards all the UDP packets coming in from Internet, because it does not know where to forward them to. A router cannot just choose some arbitrary machine, this would be a security hole. So in the "Internet connecting to a machine behind the router" you must open the UDP port on the router and let it forward to the right machine. In that case packets sent from your internal machine will get their source IP and the source port rewritten, the machine on the Internet always will see the packets as coming from your router. So except for the additional rule in the router this case is the same as the outgoing case.
Note that there are several different ways how to make NAT (symmetric, etc.) and several methods on how to open a port on the router (Config, UPnP, etc.) so the ways to poke some holes into it always depends on your hardware capabilities. This all cannot be answered here.
Some other ideas what might go wrong as well:
Some UDP protocols encode IP addresses within the payload. In that case it is not enough just to forward the packets, you must change the payload as well to correct the IP addresses exchanged to enable all machines to talk together. Such UDP protocols are badly designed, anyway, because you never should assume that two arbitrary machines can directly talk with each other, so all good protocols should support easy proxying.
Some ISPs filter certain UDP ports, for arbitrary reason. If you have problems talking from Internet to your DSL, try with two external machines directly connected to different ISPs. If these can talk via UDP check if you can talk from your Intranet to one of the external machines. If this still works, this means, that you can talk backwards as well, as usually UDP is not a directed protocol, but if there is some NAT involved you somehow must make sure that the communication ports stay open.
Mobile Internet plans often do not support P2P. This probably means, those plans do not support Internet at all, as IP, by definition, is P2P. What the ISPs really want to say with "no P2P" is (my guess), that connections from Internet to the mobile device are not supported. In that case you always must initiate a connection from the mobile device, so you cannot use push methods (Internet to Mobile), the mobile device always must pull (data from Internet). Some broadband/cable providers might do the same. Usually you can see this if your ISP hands out an IP in the 10.x.y.z range to you.
There might be another trick how to get the connection working:
Ask your ISP to get some IPv6. Perhaps use 6to4. With IPv6 you eliminate NAT completely, your local LAN then directly interconnects to the Internet on IPv6. Be sure to activate your firewall/iptables on your Intranet host on the IPv6 interface, else you might see Intruders very quickly.
HTH