在 2008 年的服务上下文中接收 ICMP 数据包
当我们从 udp 端口发送数据包时，如果网络返回 ICMP 主机无法访问，我们就会收到异常。 该异常没有告诉我们任何有用的信息（例如 ICMP 数据包的内容）。
没问题，我们只需侦听 ICMP，这将为我们提供所需的信息，同时忽略 UDP 端口上的异常。 因此，打开一个原始套接字，侦听 ICMP 数据包并从那里开始。
在开发中（Win XP）工作正常，但在服务器 2008 上的生产中，运行 exe 的安全上下文似乎必须具有管理员权限才能打开原始套接字。 这对于服务来说是没有用的。 如果我理解微软的意思，那么我们能做我们想做的事情的唯一方法就是在具有管理员权限的帐户下运行我们的服务。 感觉有点像用大锤打花生，更不用说在管理员帐户下运行面向网络的服务所带来的潜在安全漏洞了。
我真的希望我错了，但我似乎找不到任何与上述相矛盾的内容。
有人有任何意见/提示或同情吗？
When we send a packet from a udp port we receive an exception if the network returns an ICMP host unreachable. The exception doesn't tell us anything useful (like the contents of the ICMP packet).
No problem, we'll just listen for ICMP and that will give us the info we need, while ignoring the exception on the UDP port. So, open a raw socket, listen for ICMP packets and go from there.
Works fine in development (Win XP) but in production on server 2008 it appears the security context the exe is running in must have admin rights to be able to open a raw socket. This is useless for a service. If I understand what Microsoft are saying then the only way we can do what we want is run our service under an account with admin rights. Feels a bit like sledgehammer for a peanut not to mention a potential security hole that goes with having a network facing service running under an admin account.
I really hope I am wrong here but I can't seem to find anything that contradicts the above.
Anyone got any comments / hints or sympathy?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
与其监听 ICMP 对失败的 UDP 发送的响应，为什么不发送一个全新的 ICMP 回显请求呢？
当您收到异常时，您可以调用
IcmpSendEcho()函数（来自 Win32 IP Helper API）来自行生成新的 ICMP 回显请求。 关键是函数返回一个包含回显回复的缓冲区，包括状态代码，例如IP_DEST_HOST_UNREACHABLE。我认为您不需要任何特殊权限来执行此操作，因此它应该比使用原始套接字侦听 ICMP 回复更容易。
您将需要三个函数：
IcmpCreateFile()、IcmpSendEcho()和IcmpCloseHandle()- PInvoke.net 具有必要的互操作详细信息：http://www.pinvoke.net/default.aspx/icmp/IcmpCreateFile.html< /a>
http://www.pinvoke.net/default.aspx/icmp/IcmpSendEcho。 html
http://www.pinvoke.net/default.aspx/icmp/IcmpCloseHandle。 html
Rather than listening for ICMP responses to your failed UDP sends, why not send a brand spanking new ICMP echo request?
When you get the exception, you could PInvoke the
IcmpSendEcho()function (from Win32 IP Helper API) to generate a new ICMP echo request yourself. The key bit is that the function returns a buffer with the echo reply in it, including status codes e.g.IP_DEST_HOST_UNREACHABLE.I don't think you need any special privileges to do this, so it should be easier than listening for ICMP replies with raw sockets.
You will need three functions:
IcmpCreateFile(),IcmpSendEcho()andIcmpCloseHandle()- PInvoke.net has the necessary interop details:http://www.pinvoke.net/default.aspx/icmp/IcmpCreateFile.html
http://www.pinvoke.net/default.aspx/icmp/IcmpSendEcho.html
http://www.pinvoke.net/default.aspx/icmp/IcmpCloseHandle.html
我自己也遇到了完全相同的问题在 C# 中侦听 ICMP 数据包。 实际上看起来您的问题是 Windows 权限，因此该帖子无济于事。
我计划进一步深入研究的一个领域是检查 UdpListener 生成的 SocketException 中是否还有信息。 由于 Windows 使用 ICMP 数据包来生成异常，因此它不会将该数据包中的信息记录在某处，这似乎是不合理的。
和你一样，我无法从 .Net 级别的异常信息中获取 ICMP 信息，但我想看看是否可以使用 Win32 API 获取更多信息，例如 GetLastError 或其他一些信息专门针对 WinSock32 的调用。
Had exactly the same issue myself Listen for ICMP packets in C#. Actually looks like your issue is windows permissions so that post won't help.
One area I was planning on delving into a bit further is to check whether there is anymore information in the SocketException generated by the UdpListener. It just seems unreasonable that as Windows is using the ICMP packet to generate the exception it wouldn't be recording the information in that packet somewhere.
Like you I have not been able to get very far with getting the ICMP info out of the exception information at the .Net level but I want to see if there is anything further that can be obtained with the Win32 API such as GetLastError or some other calls specifically for WinSock32.
来自 MSDN 网站：
为了在我的项目中解决这个问题，我创建了一个 Windows 服务，充当我们的 UI 应用程序的网络代理。 Windows 服务在本地管理员帐户下运行，以绕过限制。 应用程序使用 WCF 连接到服务，告诉它要打开哪种套接字以及要应用什么过滤器。 然后，使用 Protocol Buffers 进行编码，通过回调发送回数据（至少是这样）计划 - 回调部分仍在进行中）。
From the MSDN website:
To get around this problem in my project , I've created a Windows service that serves as a network proxy for our UI application. The Windows serves runs under the local admin account in order to get around the limitations. The application connects to the service using WCF, telling it what kind of socket to open and what filter(s) to apply. The data is then sent back via callback using Protocol Buffers for encoding (at least that's the plan - the callback part is still in progress).