none
0xc0040017 в логах исы и тмг. Организация удаленного офиса без впн. RRS feed

  • Вопрос

  • Дано:

    Сеть ЦО: 192.168.1.0/24 шлюз 192.168.1.102 внешний ип 1.1.1.1

    Удаленная сеть: 192.168.200.0/24 шлюз 192.168.200.102 терминал 192.168.200.2 внешний ип 2.2.2.2 проброс порта 10000 с 2.2.2.2 на 192.168.200.2 с помощью керио или тмг или центос (пробовал все)

    Все стандартно, между шлюзами интернет, нужно из внутренней сети подключаться к удаленной по внешнему ипу (не по впн)

    Из 100 машин есть несколько машин, после подключения которых к терминалу удаленного офиса, другием машины подключаются туда и у них висит черный экран и не идет соединение. При том несколько из этих машин подключаются нормально. Если эти несколько машин не подключаются вообще, все остальные машины в офисе подключаются к удаленке нормально (для терминала на 2008), если ставить терминал 2003 все машины подключаются нормально. 

    ТМГ или Иса в ЦО (ставил и то и то) при подключении избранных компьютеров пишут все нормально в логах, если после избранного подключается любой другой компьютер из ЦО и у него висит черный экран, в логах пишется: 0xc0040017 fwx_e_tcp_not_syn_packet_dropped

    В ЦО все стандартно, Иса за ним реальные компьютеры в домене.

    На удаленке ВМСфера, на которой развернуты сервера для подключений.

    Иса и ТМГ точно не при делах, т.к. пробовал ставить Зикселевкий роутер, в ошибках ни че не пишет, но симптомы теже.

    Буду признателен за любые идеи.

    Например: в цо есть компьютер 1,2,3

    2 и 3 могут подключаться к удаленке, если подключается после них 1, они продолжают работать, если 2 или 3 дисконектит, то подключиться не смогут, если 1 выйдет с удаленке, то 2 и 3 смогут подключиться через 10-15 мин, либо после ребута сервера, или локальной машины. В логах Винды чисто со всех сторон.



    30 ноября 2012 г. 11:48

Ответы

  • Добрый день.

    Было бы просто отлично, если бы в описании проблемы вместо малополезной информации про подсети была очень полезная информация про версии операционных систем (ОС, уровень сервиспака и т.п.) на клиентах, после подключения которых все становится плохо, ну и об остальных тоже.  =)

    В целом все напоминает (исходя из прочитанного) проблему с MTU и неверной обработкой ICMP-сообщения о необходимости его понизить. Ради эксперимента попробуйте понизить MTU по умолчанию на проблемной машине (и интерфейсе принимающего устройства, которое делает проброс). Я бы попробовал сразу до 512 (понятно, что "с возвратом"). Если это решит проблему - тогда нужно подбирать MTU уже для всех.


    http://OpsMgr.ru/

    • Помечено в качестве ответа osr_MVP, Moderator 3 декабря 2012 г. 7:40
    2 декабря 2012 г. 6:08
    Отвечающий

Все ответы

  • Смоделировал ситуацию на другом облаке с другим провайдером, все работает. Скорее всего проблема с внутренними интерфейсами.
    1 декабря 2012 г. 11:40
  • Добрый день.

    Было бы просто отлично, если бы в описании проблемы вместо малополезной информации про подсети была очень полезная информация про версии операционных систем (ОС, уровень сервиспака и т.п.) на клиентах, после подключения которых все становится плохо, ну и об остальных тоже.  =)

    В целом все напоминает (исходя из прочитанного) проблему с MTU и неверной обработкой ICMP-сообщения о необходимости его понизить. Ради эксперимента попробуйте понизить MTU по умолчанию на проблемной машине (и интерфейсе принимающего устройства, которое делает проброс). Я бы попробовал сразу до 512 (понятно, что "с возвратом"). Если это решит проблему - тогда нужно подбирать MTU уже для всех.


    http://OpsMgr.ru/

    • Помечено в качестве ответа osr_MVP, Moderator 3 декабря 2012 г. 7:40
    2 декабря 2012 г. 6:08
    Отвечающий
  • Действительно, понижение параметров MTU даже до 1400 помогло. Понижал параметры на удаленных серверах командой

    netsh interface ipv4 set subinterface "Название сетевого подключение (у меня <int>)" mtu=1400 store=persistent 

    Спасибо за помощь.

    3 декабря 2012 г. 5:48