Проблема VipNet ISA - решена!!!

[Гость alex357]

Проблема решается следующим образом:

1)Машине на которой установлен клиент VipNet присваивается статический IP (хотя можно и по имени машины)

2)На Иса создаётся правило публикации сервера - port UDP-55777 (Receive) - External - IP машины на которой установлен клиент VipNet

3) На Иса создаётся правило по порту UDP-55777(Send) -IP машины на которой установлен клиент VipNet - External

И всё! Будут вопросы, пишите - KolbasovAM@ssk.tomsk.ru ICQ-332-979-520

[micmail]

к сожалению - не работает.

можно еще подробностей ?

[IZVNE]

к сожалению - не работает.

можно еще подробностей ?

А в чем собсна проблема? Что именно не работает? Что в логах?

[vippi]

Не удаётся заставить випнет работать через ису-2006. Машинка с випнет-клиентом опубликована, порты наружу тоже открыты, всё в точном соответствии с мануалом. И даже более того - на исе пробовал открывать кингстоны полностью, не ограничивая номера портов или адреса стучащихся серверов. Не помогает. Вообще непонятно ни мне, ни тому, кто вроде должен знать "как", что должно там быть. В логах исы пакеты от рабочей станции наружу то идут, то не идут (не блокируются, их просто нет). В логах випнета иногда появляются принимаемые пакеты и для принимаемых от координатора пакетов пишет, что порт отправителя не совпадает с реальным портом (примерно так, сейчас просто не оттуда пишу). Снаружи бывает, что сервер стукнется по какому-то левому порту 55524 (пробовал и его открывать, не помогло), но чаще просто ничего. В TMeter, который стоит как простой счётчик, видно также, что пакеты идут только "туда", обратно из инета ничего не приходит. У меня есть подозрение, что дело вообще не в ИСА, а что-то в настройках этого випнета надо крутить, наша местная техподдержка не в курсе. ИСА поставлена "с нуля", никаких лишних правил и публикаций на ней нет, до этого вообще на шлюзе ничего не стояло (впрочем, всё равно не работало). Да, и ещё. В тех редких случаях, когда при проверке соединения випнет-монитор всё-таки соблаговоляет послать пакеты на порт 55777, в логах исы потом видно, что соединение закрывается по таймауту.

[vippi]

81.27.62.254 - внешний випнетовский прибамбас (типа, стервер "Инфоцентра", который типа тужится предоставлять эти "секурные" услуги?)

85.249.87.106 - наш ИСА-шлюз, внешний адрес

192.168.0.102 - адрес клиентской машинки во внутренней ЛАН

---------------------------------------------------------------------------------------------

08.02.2009 11:55:22.846 Have outgoing files for 1106000A

08.02.2009 11:55:22.846 Get IP for 1106000A

08.02.2009 11:55:22.846 IP for 1106000A=81.27.62.254

08.02.2009 11:55:22.846 Start connect to 81.27.62.254 on port #5002

08.02.2009 11:55:22.862 2096 Connecting to 81.27.62.254 ...

08.02.2009 11:55:43.747 2096 Error 10060 in function FD_CONNECT

Connection timed out: Узел недоступен.

08.02.2009 11:55:43.747 2096 Closed

08.02.2009 11:55:44.838 Have outgoing files for 1106000A

08.02.2009 11:55:44.838 Get IP for 1106000A

08.02.2009 11:55:44.838 IP for 1106000A=81.27.62.254

08.02.2009 11:55:44.838 Start connect to 81.27.62.254 on port #5000

08.02.2009 11:55:44.854 2096 Connecting to 81.27.62.254 ...

08.02.2009 11:56:05.786 2096 Error 10060 in function FD_CONNECT

Connection timed out: Узел недоступен.

08.02.2009 11:56:05.786 2096 Closed

08.02.2009 11:56:06.892 Have outgoing files for 1106000A

08.02.2009 11:56:06.892 Get IP for 1106000A

08.02.2009 11:56:06.892 IP for 1106000A=81.27.62.254

08.02.2009 11:56:06.892 Start connect to 81.27.62.254 on port #5001

08.02.2009 11:56:06.908 2096 Connecting to 81.27.62.254 ...

08.02.2009 11:56:27.824 2096 Error 10060 in function FD_CONNECT

Connection timed out: Узел недоступен.

08.02.2009 11:56:27.824 2096 Closed

08.02.2009 11:56:27.824 Set Error for 1106000A for 300 sec

---------------------------------------------------------------------------------

Начато соединение

Тип журнала: Служба межсетевого экрана

Состояние:

Правило: VIPNet Outbound

Источник: Внутренняя (192.168.0.102:55777)

Назначение: Внешняя (81.27.62.254:55777)

Протокол: VIPNet Out

Пользователь: -

Дополнительные сведения

Number of bytes sent: 0 Кол. байт получено: 0

Processing time: 0 ms Original Client IP: 192.168.0.102

Client agent: -

----------------------------------------------------------------------------------

Закрытое соединение GW-1 08.02.2009 11:57:59

Тип журнала: Служба межсетевого экрана

Состояние:

Правило: VIPNet Outbound

Источник: Внутренняя (192.168.0.102:55777)

Назначение: Внешняя (81.27.62.254:55777)

Протокол: VIPNet Out

Пользователь: -

Дополнительные сведения

Number of bytes sent: 1785 Кол. байт получено: 0

Processing time: 158000 ms Original Client IP: 192.168.0.102

Client agent: -

И ещё - нет в логах ИСЫ входящих по 55777 UDP, никто по этой бубликации не стучится. Соединение от клиента закрывается по таймауту. Количество полученных байт всегда НОЛЬ.

[vippi]

Имя сети ViPNet: ИнфоЦентр - Сублицензия

Номер сети ViPNet: 4358

Сетевой узел ViPNet: 043_200_025073 ООО Владимирские автобусные линии

Имя пользователя ViPNet: 043_200_025073 ООО Владимирские автобусные линии

ВПозвонил в ваш хотлайн - послали куда подальше. Я конечно понимаю, что лично мне никто ничем не обязан, но что делать, если уже месяц никто не может ума дать ?

[vippi]

Ещё кусочек лога из нетмона на шлюзе:

73 09:36:23.863 LOCAL 001D468DFDC3 UDP Src Port: Unknown (1811); Dst Port: Unknown (55777); Length = 384 (0x180) GW-1 81.27.62.254 IP

FRAME: Base frame properties

FRAME: Time of capture = 09.02.2009 09:36:23

FRAME: Time delta from previous physical frame: 656250 microseconds

FRAME: Frame number: 73

FRAME: Total frame length: 418 bytes

FRAME: Capture frame length: 418 bytes

FRAME: Frame data: Number of data bytes remaining = 418 (0x01A2)

ETHERNET: EType = Internet IP (IPv4)

ETHERNET: Destination address = 001D468DFDC3

ETHERNET: 0....... = Individual address

ETHERNET: .0...... = Universally administered address

ETHERNET: Source address = 00804837215F

ETHERNET: .0...... = Universally administered address

ETHERNET: Ethernet Type : 0x0800 (Internet IP (IPv4))

IP: Protocol = UDP - User Datagram; Packet ID = 14247; Total IP Length = 404; Options = No Options

IP: Version = IPv4; Header Length = 20

IP: 0100.... = IP Version 4

IP: ....0101 = Header Length 20

IP: Type of Service = Normal Service

IP: 000..... = Precedence - Routine

IP: ...0.... = Normal Delay

IP: ....0... = Normal Throughput

IP: .....0.. = Normal Reliability

IP: ......0. = Normal Monetary Cost

IP: Total Length = 404 (0x194)

IP: Identification = 14247 (0x37A7)

IP: Fragmentation Summary = 0 (0x0)

IP: .0.............. = May fragment datagram if necessary

IP: ..0............. = Last fragment in datagram

IP: ...0000000000000 = Fragment Offset 0 (0x0000)

IP: Time to Live = 127 (0x7F)

IP: Protocol = UDP - User Datagram

IP: Checksum = 50485 (0xC535)

IP: Source Address = 85.249.87.106

IP: Destination Address = 81.27.62.254

UDP: Src Port: Unknown (1811); Dst Port: Unknown (55777); Length = 384 (0x180)

UDP: Source Port = 0x0713

UDP: Destination Port = 0xD9E1

UDP: Total length = 384 (0x180)

UDP: UDP Checksum = 0xC557

UDP: Data: Number of data bytes remaining = 376 (0x0178)

При этом в журнале "монитора" випнет фиксируются TCP пакеты на порты 5000...5002 того же сервера 81.27.62.254. Поскольку понять, как это работает, я не могу, то и сделать ничего не могу. А кто может? Наверняка всё дело в какой-нибудь простой галочке в настройках випнета, и уж точно не в ИСА-сервере.

[Stratos]

Добрый день, vippi

Вам необходимо обратиться в службу техподдержки компани Инфотекс Интернет Траст и озвучить им Вашу проблему.

Координаты службы технической поддержки:

e-mail: helpIIT@infotecs.ru

tel: +7 (495) 737-3369 с 09-00 до 18-00 по московскому времени

P.S. Ваше обращение было передано в службу техподдержки компани Инфотекс Интернет Траст

[NightAngel]

Та же проблема что и у vippi. Есть клиент в сети с ИСОй, на компе стоит фаерволклиент для ИСЫ. Правила вроде бы разрулил, сервер для клиента запаблишил. Результату ноль. Орбитовская поддержка полный ноль в квадрате. А соединения как не было и нетю В логах ИСЫ вообще невижу ELG протокола на порты 55777. Зато лезут UDP 2046 и TCP 5000-5002 вовсю лезут. Причем с учетом правила для лазания этой машины по нету, в логах МФТП пишет что узел недоступен. ежели компу оставляю тока правила для ВипНета, а из доступа к интернету его выкидываю, то в логах МФТП пишет, Узел доступен но МФТП на нем не активен.

Меня этот дебильный випнет уже выбесил. Не ужели не могли по нормальному ВПН организовать без этих извратов???

[Stratos]

NightAngel

За какими файрвольными настройками стоит Клиент?

UDP 2046 - проверка соедиения

TCP 5000-5002 - это порты MFTP

Узел доступен но МФТП на нем не активен. - это говорит, что MFTP на узле не активен по причине того, что транспортному модулю нечего отправлять/принимать.

P.S. Насчет Вашего последнего предложения - Вы думаете после Ваших слов Вам помогут в форуме??? Сомневаюсь....

[dudandr]

Что Вы пишите - проблема решена! Враньё. Не решена проблема. С 2007 года нет инструкции как прокинуть UDP 55777 трафик через ISA сервер. Давайте уж решение в студию. А как написано - не работает!!! Решайте проблему.

[Stratos]

to all

Господа.

Требовать решение в студию, это конечно хорошо. НО!!! Вы все забываете об одном тонком моменте - у каждого клиента, ISA настроена по своему, зачастую, клиент даже не знает, что и как настроено на этом злосчастном сервере. Поэтому универсального ответа дать нельзя. Точнее можно, дать ответ, какой дал автор этой темы.

Только уверяю Вас всех, ВСЕМ он не подойдет 100%.

Плюс, сама схема использования продуктов ViPNet у всех своя, зачастую, построенная с нарушением технологии построения VPN на базе продуктов ViPNet.

Просьба привести КОНКРЕТНЫЕ СХЕМЫ использования. Будем моделировать.

[NightAngel]

Описываю подробно всю ситуацию.

Есть сеть с выходом в интернет через АДСЛ2+ модем. На нем стоит

Microsoft ISA Server 2006 Standart Edition (предложения сменить

фаерволл не рассматриваются ибо весь софт лицензионный), плюс стоит

Антивирус Касперского Total Space Suite (KAV for ISA + KAV for Server

+ KAV AdminKit). Все это добро управляется осью Windows Server 2003 R2

Standart Edition и поднято в домен. Внешний IP назначается автоматически

провайдером. Иса стоит именно в режиме фаервола с обязательным требованием

авторизации (методом ввода пароля или автоматически через NTLM через

Microsoft Firewall Client for ISA Server). На рабочей станции стоит

Антивирус Касперского для Windows WorkStation, Клиент для межсетевого

экрана ИСА сервера.

Далее делалось следующее: На сервере с ИСОЙ создавались новые

протоколы для общения по UDP порту 55777. Причем варианты направлений

пробовались самые разные (их там четыре: отправить, отправить и

получить, получить, получить и отправить).

Правило для выпускания этого протокола на ружу выглядит следующим образом:

Действие Откуда Куда Протокол Пользователи

================================================================================

=

Разрешить 192,168,5,40 Внешняя Vipnet55777 Все пользователи( + системная служба, добавил позже для эксперимента)

<<Откуда>> - АйПи адрес компа с которого должен коннектится клиент. Ради

интереса добавлял "Внутренняя сеть", т.е. все компы локалки, плюс

"Локальный компьютер", т.е. тот комп который выполняет функции сервера

ИСЫ.

<<Куда>> - собственно все адреса не входящие в диапазон АйПи адресов

локальной сети. Кстати следует заметить, что на сервере стоят две

сетевые карты, одна смотрит в локалку (диапазон 192,168,5,*), вторая

глядит на модем (диапазон 192,168,1,*). Между ними поднят роутинг по

подсетям. Модем работает в режиме Роутера и соединение с провайдером

устанавливает сам, через PPPoE.

<<Протокол>> - собственно добавленные порты UDP 55777 как было

написано чуть выше.

<<Пользователи>> - по спецификации ISA Server есть три категории

пользователей SecureNat, Firewall Client, WebProxy Client. SecureNat -

не подлежат учету, авторизация идет по IP-адресу клиента при входе на

дефолтный шлюз. Firewall Client - Клиенты межсетевого экрана (MSFWC)

это клиенты которых авторизует этот самый Мелкомягкий клиент для ИСЫ.

WEBProxy - Это авторизация через браузер типа Интернет Эксплорера или

любая программа в которой есть настройки для ввода прокси сервера

и/или авторизационных данных. Все пользователи по документации ИСА

сервера - это как раз клиенты SecureNat не требующие авторизации, "Все

прошедшие проверку" - клиенты фаервола и ВебПрокси. Здесь ставил все

варианты в том числе добавлял "системные и сетевые службы".

Соединение с Координаторами КТФОМСа не идет ни под каким соусом.

Проверка связи выкидывает вот такой вот лог (см. Вложение).

Причем в логах ИСЫ я вижу только порты UDP2046, TCP5000-5002. А вот

порт 55777UDP мне даже никак не хочет показаться. В прятки что-ли со

мной играет? Можно ли сменить его на любой другой порт

Пробовал дома. Модем тоже сидит роутером, фаервол отключен, в т.ч. и

антивирус (решил рискнуть :-). Тоже самое связи с координаторами нет.

В настройках узла ЛПУ_ТУАПСЕ_ДГП, пробовал разные варианты включая

отключение использования фаервола. Связи нет и все тут.

Прогулялся в наш КТФОМС, посмотрел сравнил настройки. У нас в

программе виртуальные адреса доступа к Координаторам через межсетевые

экраны разные...

Что будем делать , как его бороть???

P.S. Установка корневых сертефикатов не помогла вообще.

_____________________.txt

[Stratos]

NightAngel

Будем моделировать Вашу ситуацию.

Как только появится информация, или будет нужна дополнительная информация - отпишусь.

[NightAngel]

А у меня реально VipNet Client [Деловая почта] заработал через ISA Server 2006. Напишу инструкцию выложу в интернет.

Инструкция по настройке

[IZVNE]

На самом деле то что описано в первом посте реально работает и без всяких проблем.

Но вот когда встает проблема с работой нескольких VipNet одновременно вот тут уже такие танцы с бубном начинаются. И самое отвратительное что с несколькими VipNet ISA не работает.

Уважаемые администраторы форума могут со мной спорить но пробовал и на 2004 ISA и на 2006 ISA в разных локальных сетях. На выход проблем не будет но на входе ISA будет тупо кидать все на одну машину. Она в данном случае просто не может идентифицировать с какой машины ушел пакет чтобы его вернуть на ту же машину.

[Stratos]

IZVNE

И самое отвратительное что с несколькими VipNet ISA не работает.

- откуда такое стойкое убеждение? Разводите клиентов по портам и будет Вам счастье.

to all

Что касается совместной работы ViPNet Клиента или Координатора с клиентом ISA - работать не будет НИКОГДА!!! Читайте внимательно документацию на ПО ViPNet - "На компьютере не должно быть установлено никаких других ПСЭ (firewall)". Ну не дружит драйвер защиты ViPNet с драйвером ISA клиента.

[IZVNE]

2Stratos

Если бы я не поставил кучу экспериментов я бы так не говорил. Но увы. В нашем холдинге есть компания администратор которой так же не смог реализовать работу 2 VipNet через одну ISA. И таких людей довольно много. Вы гуглом поищите подобную проблему. Я Вас уверяю найдете аналогичные отзывы как и звесь.

Под разводкой по портам вы что имеете в виду?

Уходит все на 55777 а принимать на разных портах типа 55778, 55779 и так далее?

[Stratos]

IZVNE

Да, разводите по портам.

Пропишите маршруты и счастье обеспечено.

В конце концов, поставьте за ису координатор, тогда проблема портов отпадет, координатор должен сам все разрулить.

[vit83]

И все таки хотелось бы увидеть окончание темы... у кого нибудь заработало несколько клиентов?

[vippi]

На самом деле то что описано в первом посте реально работает и без всяких проблем.

Ничего подобного, на самом деле оно рабоает не потому, что должно, а потому что случайно так совпало. Я провёл много экспериментов, ситуация прикольная до смешного. Объясняю.

Виндовозный НАТ работает по принципу Random Ports. То есть, НАТ пересылает клиентские пакеты с такой адресацией:

gatewayaddr:randomport -> serveraddr:55777

(здесь gatewayaddr - адрес клиентского шлюза, serveraddr - адрес сервера-координатора)

соответственно и ждёт ответов на порт randomport, чтобы вернуть их клиенту. И никакая такая бубликация 55777 помочь делу не может в принципе, ибо пакеты, которые сервер-координатор тупо шлёт обратно на порт 55777, клиента не интересуют - они не являются ответом на его пакеты. Может быть совершенно случайно совпадение, что НАТ в качестве randomport выберет именно порт 55777 - и всё заработает. Я специально добивался этого следующим макаром - координатор сканирует порт 55777 шлюза, а поскольку тому предписано пересылать такие запросы клиентской машине, устанавливается "канал проходимости", происходит фиксация исходящего со шлюза порта значением 55777 и после этого всё работает, можно снимать сканирование порта, но только до перезагрузки клиента. То есть, на следующий день виндовозный НАТ опять выберет порт от балды, и ничего работать не будет.

Далее. Поставив шлюзом вместо виндовозной машинки машинку на фряхе, включаю same_ports - само собой, всё работает. Далее вывожу фряшный НАТ в режим Random Ports и нате-здрасте - ни фига не работает, причём мониторинг пакетов говорит всё о том же - клиенту ни в какие ворота не стучат "чужие" ответы на порт 55777, которые ему исправно пересылает бубликация. Ему нужны "родные" ответы, которые он ждёт от НАТ.

Так вот, внимательно прочитав инфу по фряхе, читаю, что same_ports работает только дотоле, доколе свободен требуемый порт, в противном случае НАТ без предупреждений переходит в режим Random. А это значит, что даже на никсах, если чем нибудь занять злополучный порт 55777, ни фига работать не будет. Данному предположению также было сопоставлено экспериментальное доказательство.

Выводы:

1. ISA-сервер тут совершенно ни при чём, его отсутствие, равно как и его присутствие, картины совершенно не меняет, если же админ не умеет делать бубликацию, гнать его метлой поганой и випнет тут не виноват.

2. Если координатор не умеет работать с произвольными клиентскими портами, то требуется официальный ответ разработчика "Да" или "Нет". А это, вообще-то, просто нонсенс, ведь порт 55777 не обязан быть свободен, равно как и клиент и его НАТ НЕ ОБЯЗАНЫ соблюдать номер исходящего порта, также и атаку DoS провести на такую систему будет раз плюнуть, достаточно только занять клиентский 55777, и система отвалится, ну и многое другое.

3. Если же продукт уже много лет работоспособен на территории огромной страны и все довольны, тогда производителю следует озаботиться кадровым вопросом, равно как и вопросом подбора партнёров в регионах.

4. Использование хакерских методов пролома НАТ (см. документацию к продукту в части объяснения принципов поддержания канала) неприлично для серьёзного продукта, непонятно, от кого он защищает и кого защищает.

5. Конкретно во FreeBSD (на других не проверял) можно перевести НАТ в режим "правильной работы", когда пролом НАТ "со стороны" станет невозможен. В сочетании с рандомными портами такой НАТ полностью непрозрачен как для злобных хакеров, так и для системы ВипНет, поскольку последняя строится на принципах P2P, а это неприлично для серьёзного продукта.

[Stratos]

vippi

По п.п. 2 - делайте официальный запрос в компанию, Вам официально ответят.

По п.п. 3 - вообще непонятно, что Вы имели в виду....

По п.п. 4 - так же выводы непонятны. Я бы даже сказал что это не выводы, а вопросы...

[vippi]

vippi

По п.п. 2 - делайте официальный запрос в компанию, Вам официально ответят.

По п.п. 3 - вообще непонятно, что Вы имели в виду....

По п.п. 4 - так же выводы непонятны. Я бы даже сказал что это не выводы, а вопросы...

Пункт 2 мы возложили на вашего регионального партнёра. Пусть сами разбираются, не смогут - расторгнем договор и будем возить инфу в ПФР дискетами. Хотя, согласитесь, странно, что эта информация является столь засекреченной, что получить её можно, только сделав официальный запрос. То есть, прочие всякие участники процесса за базар совершенно не отвечают и не могут сделать никаких внятных предположений относительно того, как вообще этот продукт работает.

Пункт 3 касательно потрясающих практических и теоретических знаний как основ сетевых технологий, так и конкретно сопровождаемого продукта всеми или некоторыми участниками процесса сопровождения. Техподдержка такого продукта не может собой представлять "девочку на телефоне" или "мальчика по вызову". Спецы нужны, и не просто спецы, а вооружённые чёткими инструкциями и внятными мануалами. Фраза "там ничего настраивать не надо, оно и так работает" в ответ на вопрос о тонкостях настройки внушает прямо недетское уважение к продукту, самое интересное, что и в мануале по инсталляции тоже так написано. Чтож оно тогда не работает - вопрос региональному вашему партнёру - ответ "а х... его знает" - тоже потрясающий. Или другой вариант - ну поставьте диалап-модем на этот комп - я что, за косяки продукта должен ещё и расплачиваться дополнительными подключениями? Судя по всему, это считается нормой...

PS: Но ведь есть рабочие примеры, то есть, ОНО РАБОТАЕТ? Так почему только "местами"? Я был готов предоставить любой вариант виндовозного шлюза в качестве полигона, так почему бы раз и навсегда не поставить точку в этом (я уверен) банальном вопросе? Да просто всем пофиг. Зарплату платят, да и ладно... Коммунизм отменён.

[Stratos]

vippi

Вы знаете, я за Ваши слова обоими руками "ЗА", но к сожалению, иногда бывают такие случаи, когда наши региональные партнеры "филонят" конечных клиентов.

В таких случаях мы рекомендуем писать жалобы напрямую к нам, мы будем сами разбираться с партнером, воспитывать их. Ну и конечно же, в самом худшем случае, поможем конечному клиенту сами.

Поэтому, рекомендую написать нам письмо с жалобой. Терпеть некомпетентность партнера нельзя ни в коем случае.

Писать можете как на hotline@infotecs.ru или мне в личку. Разберемся.

[eech]

Здравствуйте.

Проблема очень напоминает проблему Vippi, но имеются отличия.

1. До 2 сентября всё работало, а потом перестало. Причиной посчитали заражение вирусом, что потом подтвердилось. Было принято решение установить ПО на новую машину, что вызванный специалист и сделал. Связь отсутствует с теми же симптомами.

Лог Випент клиента МФТП:

------------------------------

poll for 0307000A

IP for 0307000A=10.80.1.2

Start connect to 10.80.1.2 on port #5002

Connecting to 10.80.1.2...

Error 10060 in function FD_CONNECT

Connection timed out

-------------------------------

То же самое на порты 5000 и 5001. Реальный адрес сервера 62.165.34.78, а вовсе не 10.80.....

При этом на ИСА пакет UDP на 62.165.34.78:55777 фиксируется только однократно при старте випнет клиента.

Потом пакеты идут только такие (IP назначения варьируется, но подсеть одна):

----------------------------------

Начато соединение EVEREST 10.09.2009 17:48:06

Тип журнала: Служба межсетевого экрана

Состояние:

Правило: Этран

Источник: Внутренняя (192.168.7.245:55777)

Назначение: Внешняя (10.80.1.2:55777)

Протокол: vipnet_udp_55777

Пользователь:

Дополнительные сведения

Number of bytes sent: 0 Кол. байт получено: 0

Processing time: 0 ms Original Client IP: 192.168.7.245

Client agent:

-----------------------------------

Пакеты уходят вникуда и естественно не возвращаются.

2. В логах иса (не в "наблюдении, а в самих файлах логов) присутствуют пакеты от 62.165.34.78:55777 на различные порты прокси, но они отвергаются сервером. Исходящих пакетов на 62.165.34.78 нет.

Клиент работал по правилу на прокси "разрешен весь исходящий трафик от клиентской машины наружу".

3. Сниффер на клиентской машине фиксирует множество пакетов 192.168.7.245:55777 -> 62.165.34.78:55777, но в логах иса такие пакеты вообще отсутствуют.

4. Был сделан эксперимент. Клиентскую машину выдернутую из сети соединили напрямую с моей машиной. Сниффер на моей машине не обнаружил ни одного пакета с адресом назначения 62.165.34.78. Собственно единственное, что могло напоминать пакет в интернет имело адрес назначения 255.255.255.255.

При этом поддержка божится, что наши пакеты на сервер поступают и сервер им отвечает... Я бы просто отказался верить поддержке, если бы не п.2

5. Был сделан другой эксперимент. Мы со специалистом установили программу еще на одну машину. У машины мгновенно отвалилась сеть. Випнет клиент заявил, что отказывается работать на машине без сетевого адаптера. Причем адаптер этот в устройствах был и протокол TCP/IP был настроен. Но команда ipconfig -all выдавала, что настроенных протоколов нет. После удаления клиента випнет все заработало.

6. При подключении USB GPRS модема всё работает.

7. Если выдернуть шнурок от провайдера из прокси сервера и воткнуть его в клиентскую машину, поменяв настройки TCP/IP на провайдеровские - все работает.

--------------------

Кто сталкивался с этим, помогите пожалуйста.