Forum Replies Created
-
Posts
-
NDISAPI в сборке собрана с поддержкой UNICODE, так что, на выбор, надо или включить UNICODE для вашего приложения или пересобрать NDISAPI без UNICODE.
И второе, для 64-битной системы стоит все-таки использовать 64-битное приложение (и соответственно 64-битную сборку DLL). Не будет потерь производительности при конверсии структур для 64-битного драйвера.
Добавил, так же немного обновил реализацию, добавил инсталлятор и подписал все драйвера.
Для тестов руки не дошли, так что если не затруднит – напишите как отрабатывает новое событие.
Кастомная сборка делается для клиента с новым имененм драйвера и рядом других параметров.
Но если очень хочется попробовать, то почему нет. По ссылке тестовая сборка, заранее предупреждаю, что не проверял работоспособность нового API:
- бинарники драйверов для Vista/7/8. Под десятку сложнее процедура подписи, поэтому не включен. Драйвера можно поставить вручную через свойства сетевого соединения.
- бинарники и исходный код для NDISAPI.DLL с новой функцией
Технически это может сделать любой драйвер сетевого протокола, в том числе TCP/IP или Winpcap (если использовался Wireshark).
В принципе, поскольку драйвер фильтрует все NDIS запросы к сетевому интерфейсу, то можно либо добавить notification event на изменение фильтра, либо не позволять кому бы то ни было менять фильтр установленный через winpkfilter. Можно добавить такое к custom сборке…
И еще один момент, любое другое приложение обращающееся к драйверу может поставить свои события на пакеты и мост перестанет их получать. Например, достаточно запустить стандартный passthru на одном из интерфейсов моста, чтобы последний перестал нормально работать. В целом для production стоит ограничить доступ к драйверу (для демо версии это неудобно).
Маловато конечно информации, чтобы делать какие-то выводы. Во-первых, какие интерфейсы включены в мост? Два обычных Ethernet 802.3?
Для начала стоит посмотреть в отладчике чем заняты рабочие потоки после того как мост перестает работать. Для наглядности я бы добавил консольный вывод в рабочие потоки (получил пакеты -> переслал пакеты). Сразу будет понятно какой поток заснул или вообще вышел.
Например, если мост перестал функционировать, но при этом потоки продолжают получать и перекладывать пакеты и оба сетевых интерфейса сами по себе работают нормально (пингают хосты в подключенных сетях), то возможно что-то сбрасывает promiscuous фильтр на одном или на обоих интерфейсах. Это несложно проверить, прочитав текущий фильтр, как, впрочем, несложно и поправить, восстановив promiscuous.
If I’m not mistaken Internet Gateway uses single thread to send/receive packets from both adapters (LAN and WAN) waiting with WaitForMultipleObjects an adapter associated event objects.
So, in order to implement bandwidth management I’d advise launching two threads instead, one per network interface, each waiting with WaitForSingleObject on associated event. This way you should be able to delay packets for the selected network adapter without affecting the second one. Just note to take care about threads synchronization when accessing shared data. You can use Ethernet Bridge source for the reference for thread per network adapter model.
В общем да, рестартовать мост имеет смысл если произошли изменения в используемых интерфейсах, остальные изменения можно игнорировать. Внутренне HANDLE сетевого адаптера – это указатель на структуру в ядре, она удаляется только при удалении адаптера из системы, то есть HANDLE может изменится только если адаптер был удален и снова добавлен.
Единственно, если 32-битное приложение работает с драйвером на 64-битной системе, то NDISAPI включает дополнительный уровень трансляции для хэндлов (из 32 в 64 битные) и на постоянство хэндлов полагаться нельзя, 32-битные хэндлы в этом случае – индексы в массиве 64-битных.
Судя по симптомам, скорей всего дело в том, что один из интерфейсов переподключается в процессе работы. Это поведением можно симитировать сделав disable/enable одной из сетевых карт моста в процессе работы.
Простоты ради Ethernet Bridge не обрабатывает изменения сетевой конфигурации. Нужно бы добавить мониторинг изменений доступных интерфейсов (SetAdapterListChangeEvent) и останавливать/перезапускать мост когда один из адаптеров “уходит”/”возвращается”.
Как-нибудь доработаю на досуге, по хорошему для длительной работы из него вообще предпочтительней сделать сервис.
Normally I’d use IP Helper API for this purpose. For the TCP protocol it can be done with the following steps:
1) Use GetExtendedTcpTable and GetOwnerModuleFromTcpEntry to build the mapping from the local (IP address, TCP port) to process executable.
2) Extract IP and port information from the packet and use the mapping built on previous step to look up the process executable.
3) Update the mapping periodically or when you can’t lookup process for the certain packet.For the UDP just use GetExtendedUdpTable and GetOwnerModuleFromUdpEntry instead.
2) а вот тут я мало что понял.
Вместо моста делаем шлюз, где одна сетевая карта раздает интернет на другую. Как еще проще обьяснить – не знаю. В такой конфигурации можно фильтровать как внешний, так и внутренний интерфейс и отбирать/модифицировать нужный траффик.
Согласен, есть нюансы…
С другой стороны, против использования встроенного моста и Windows 7 есть один серьезный аргумент – нет гарантированной возможности забиндиться на интерфейсы под мостом (причем непонятно от чего это зависит), а это в свою очередь означает, что нет возможности фильтровать транзитный трафик (он обработается внутри моста).
Таким образом, видится два варианта:
1) Перенести функционал моста непосредственно в драйвер.
2) Использовать routing/NAT. Опять же можно использовать как самописный NAT, так и встроенный в Windows Internet Connection Sharing (ICS). Тогда будет достаточно запустить приложение только на одном интерефейсе (внешнем или внутреннем в данном случае роли не играет) и отбирать только нужный трафик.На компе я удалил мост, а из устройств – сетевые карты; перезагрузился, установил драйверы для сетевых карт, создал мост. После этого WinpkFilter стал видеть сетевые интерфейсы правильно: мост видит, а сетевые карты нет.
Тем не менее, я бы на это не полагался и организовал бы мост средствами WinpkFilter.
Еще один возможный вариант – использовать не мост, а маршрутизацию. Несколько лет назад делал нечто подобное для NetTalk DUO при подключении через USB (RNDIS). В такой конфигурации в системе появляется дополнительный сетевой интерфейс, а NetTalk DUO выглядел как сетевое устройство подключенное к той же сети. Приложение на winpkfilter обеспечивало выдачу адресов в этой сети по DHCP и организовывало NAT из этой сети на внешний интерфейс, таким образом NetTalk DUO получал доступ к интернету от подключенного лэптопа.
Да, любопытно, я такой список интерфейсов наблюдаю, только если сначала сбриджить два адаптера, а затем в свойствах моста отключить их от моста. Похоже не все так гладко с этой конфигурацией на Windows 7…
Тем не менее, в качестве основы для решения поставленой задачи, я бы рекомендовал взять мост построеный на WinpkFilter:
https://www.ntkernel.com/bridging-networks-with-windows-packet-filter/
Код на GitHub:
https://github.com/wiresock/ndisapi/tree/master/examples/ethernet_bridge
и в нем отдельно обработать SIP трафик. Мне кажется так и проще и надежней с учетом не до конца предсказуемого поведения встроенного моста Windows.
