Где в сетевом стеке Windows перехватывает / фильтрует WinPcap / Npcap «Слушать» пакеты?
Я исследую проблему с процессом, который выполняет IPC через сокет. Сокет обслуживается на IP-адресе сетевого адаптера локального компьютера, и соединение с IP-адресом сетевого адаптера локального компьютера осуществляется другим процессом на локальном компьютере.
Я ожидал, что это опустит сетевой стек Windows, по крайней мере, достаточно далеко, чтобы Wireshark могли видеть пакеты. Однако, похоже, это не так. Таким образом, я могу заключить, что IPC сокета занимает более высокое место в стеке [было бы интересно посмотреть, будут ли какие-либо средства трассировки событий Windows (ETW) видеть трафик как IP-кадр]. Это не важно для этого вопроса (поскольку это не stackoverflow).
Где WinPcap / Npcap «живет» в сетевом стеке, чтобы прослушивать и передавать пакеты в wirehark?
Я сосредоточен на современных Версии ОС Windows (клиент: 7+, 10+; сервер: 2008+, 2012+, 2016+). В частности, этим клиентом является Windows 10.
Я действительно хочу знать, где в сетевом стеке принимается решение «возвращать» пакеты к хосту, а не отправлять их вниз по стеку.
Спасибо
Он находится на IP-уровне, если не включен Fast Loopback, то на TCP-уровне. Такие приложения, как Network Monitor или Wireshark не работают из-за того, что сетевой стек Microsoft не приспособлен для перехвата трафика обратного шлейфа.
"Поведение интерфейса обратного шлейфа TCP по умолчанию заключается в перемещении локального TCP-трафика через большую часть сетевого стека, включая AFD (который, по сути, является представлением режима ядра TCP-сокета пользовательского режима), а также слои, соответствующие слоям TCP и IP-протокола"
В качестве альтернативы, вы можете перехватить трафик на уровне Windows Filtering Platform (WFP) с помощью Microsoft Message Analyzer:
https://blogs.msdn.microsoft.com/winsdk/2014/08/15/rejoice-we-can-now-capture-loopback-traffic/