Forum Replies Created
-
Posts
-
Я Дельфи не очень читаю, поэтому лучше расскажу как это надо было делать.
Если собираешься фильтровать на внешнем интерфейсе и меняешь destination IP, то нужно запомнить какое соединение и как ты изменил (source IP/port, original destination IP/port). Иначе пакет с измененным (TCP SYSN) IP адресом выйдет наружу, удаленный сервер (на который был осуществлен редирект) тебе ответит(TCP ACK), а затем в полученном от этого сервера на внешний интерфейс пакете нужно будет заменить source IP/port (они на момент получения принадлежат серверу на который был осуществлен редирект) на те которые были изначально (куда собственно клиент стучался). Ну и так далее для всех последующих пакетов. У тебя же в коде всего одна проверка на адрес, и такой логики судя по всему не присутствует.
Хотя обычно такая фильтрация делается на внутреннем интерфейсе с редиректом на локальный HTTP сервер. Так как то правильней чем редиректить с внешнего куда-то на удаленный сервер.
Actually that depends from the NAC implementation, an example NAC can be built using drivers similar to winpkfilter. So I can hardly advise anything without the details.
I have not seen the behaviour like this myself, but I have heard about one such case already. I agree with the second post in MSDN that this may be caused by pending NBL’s in underlaying NDIS miniport driver. Have you tried to update your WAN/LAN drivers? Which exactly causes the hang?
One possible option can be disabling network interfaces prior to LWF driver uninstallation. It can be also done from command line using devcon utility like described here http://wlanbook.com/enable-disable-wireless-card-command-line/
For Windows XP 32 bit you probably use WinpkFilter NDIS-hooking driver which intercepts bindings between TCPIP and network interfaces. This type of driver does not care about underlying network interface media type.
Unlike NDIS-hooking driver other WinpkFilter drivers (NDIS IM and NDIS LFW) are installed to filter media types specified in INF file. Current INF files specify ethernet, wan and ppip network media types. You can add nolower media type (VMWare adapters has this media type) into the INF file and this will cause WinpkFilter driver to bind to VMWare adapters. However, besides VMWare network adapters WinpkFilter will be also installed to filter other network interfaces with nolower media. This may cause stability side effects, so you can try this on your own risk.
Не все тут просто, как минимум нужно сохранять какой-то контекст для каждой интересующей TCP сессии. Дальше есть два варианта:
1) Кешировать пакеты сессии до тех пока не будет получен весь файл. Для этого придется генерировать ACK пакеты в обратном направлении. Как только файл получен проанализировать его и отправить соответствующие пакеты по назначению. В данном случае придется самостоятельно контроллировать доставку пакетов и делать ретрансмиты если пакеты теряются.
2) Для каждой сессии сохранять ее текущее состояние и каждый следующий пакет анализировать с учетом состояния сессии. Как, например, при обнаружении метода POST сохранить контекст сессии (IP адреса и порты) и затем все пакеты проверять на принадлежность этой сессии. Если пакет принадлежит этой сессии то анализировать его с учетом того что это метод POST.
Первый метод довольно сложный и я бы его не рекомендовал, а второй вполне реально реализовать. Придется конечно реализовать анализатор интересующего протокола, чтобы для каждого пакета понимать, что он содержит и как это должно быть проанализировано.
By the way, VirtualBox packet duplication issue it had in the past:
I was not able to reproduce packet duplication with enabling routing and even installing the VirtualBox. However, can you try to uncheck VirtualBox Bridge Networking Driver and see if packet duplication still takes place?
In the past I have observed packet duplication when working over my version of Ethernet Bridge based on NDIS IM driver. In order to get brdged to the real network NDIS IM driver has to place the real network interface into the promicsuous mode in order to be able to get packets destined to Ethernet address different from the NIC hardware address. So you have the cocktail of routing and bridging in the promiscuous mode on your system and adding one extra binding into the configuration (like LWF filter driver) in theory may cause packet duplication. So it makes sense to remove Virtual Box Network bridging from the configuration to see if there is any difference.
All instances are removed from both WindowsINF and WindowsSystem32DriverStoreFileRepository using the pnputil.exe shipped with Windows, and verified through Windows Explorer and grep utilities. I’ve seen this on the Asus mentioned above, and a Virtual Machine running under Virtual Box.
After you think that you have uninstalled and removed WinpkFilter driver I would also check if registry key HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesndisrd still exists. Sometimes uninstall does not remove this key.
What OS have you been testing with? Have you any other low level network components installed besides WinpkFilter LWF? Are you able to reproduce the problem with basic samples like passthru?
Internet Gateway is a very draft sample application which includes some relatively complex advanced functionalities (NAT, routing capabilites). It may be some kind of bug in the Internet Gateway itself. Thats why it would be good to know if this problem is reproducible with a very simple test application like passthru. If passthru works fine then this is probably Internet Gateway issue, otherwise this is something about network configuration or drivers conflict.
