Ошибка 104 Соединение Уже Существует

[Alexx_mfc 0]

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

Ситуация следующая: Сеть удаленного филиала соединена с головным офисом через шлюз с установленным ViPNet _Coordinator_Linux_3.7.1_(2757). ОС Ubuntu 10.04.4 LTS. Интерфейсы: eth0 - внешний (интернет), eth1 - внутренняя локальная сеть, vpn_tap_0 - VPN интерфейс для незащищенного (открытого трафика).

Туннелируемые ресурсы и защищенная сеть работают нормально. Во внутренней сети филиала работает веб сервер. С головного офиса пинг к нему через впн туннель проходит нормально. Но при попытке подключения по RDP или к веб сервису, трафик блокируется на VPN интерфейсе, в журнале пакетов ошибка:

104 Соединение уже существует Для создаваемого соединения параметры исходящих пакетов (socketpair) совпадают с уже существующими, такое соединение блокируется.

Та же ошибка при попытке доступа по RDP на другие внутренние не защищенные и не туннелируемые ресурсы.

В других филиалах конфигурация аналогична, все работает без проблем.

[ingenico 0]

Похожая тема была тут - http://www.infotecs.ru/forum/index.php?showtopic=8074

Я сам сталкивался с такой ошибкой в 2014 году при настройке статического NAT (как раз доступ по RDP на незащищенный внутренний сервер) на дистрибутиве Coordinator Linux 3.7.4-4464.

Ранее использовали Coordinator Linux 3.6.X - там таких ошибок не было.

Техподдержка подтвердила что это действительно ошибка. Получили от них дистрибутив Coordinator Linux 3.7.5(6980).

С ним таких проблем уже не было.

Вот его changelog, там как раз пофиксена ошибка 104:

Linux Coordinator 3.7.5-6980

Список изменений

Id Type Title 109571 Issue Проблема с кластером ФССП HW 1000 110405 Issue Останавливается служба failover 105603 Issue Found coredump file 109934 Issue Во 2 режиме безопасности пассивная нода не проверяет arp активной. 110543 Bug Кодировка в журналах mftp 110546 Bug Проблемы 3.7.4: При очереди писем около 14000 нагрузка возросла до 100% 62142 Bug Проблема с дублем IP на узлах при старте iplir 84283 Bug Координатор сбрасывает firewall-ip при смене настроек адаптера 85468 Bug Падение iplircfg при обработке UDB команды 300 89611 Issue 1 событие с новыми АП после обновления СМ с 3.5.2 до 3.7.4 90846 Issue разница в pacettype v 3.6.5 и 3.7.4 91409 Issue странности в работе ПО 96699 Bug 3.7: unmerge segmentation fault на dst 2.8 96926 Issue Cвязка Администратор 2.8 + Linux Coordinator 3.7.5 97253 Bug 100% загрузка демоном iplircfg после старта на ARM координаторе 97904 Issue Ошибка при установке Vipnet Coordinator Linux 98360 Issue 104-событие при прохождении транзитного открытого трафика 99381 Issue Проблема с работой ПО в условиях переключения каналов доступа 99806 Issue Coordinator Linux: Разворачивание dst с количеством связей в 20000

Обращайтесь в техподдержку за свежей версией дистрибутива.

[Alexx_mfc 0]

Обновили версию, ошибка исчезла.

Спасибо.

[spec89 0]

Подниму ка тему. Имеется координатор HW1000 (4.2.4) Периодически на нём выскакивает  данное событие 104 Соединение заблокировано, так как параметры исходящих пакетов (socketpair) для этого соединения совпадают с такими параметрами для ранее установленного соединения.

Схема проста: в координатор приходит 2 провода. Eth0 -локалка, eth1- соединение с прокси сервером, прямым кабелем.

Так вот некоторые клиенты из локалки, при обращении к прокси получают "отказ". Пинга до прокси нет. Стоит выполнить трассировку, она выполняется успешно и пинг возобновляется, соответственно интернет появляется.

В фаерволле всё открыто, NAT не используется на координаторе. У клиентов координатор -шлюз по умолчанию, у координатора - прокси. У прокси обратный маршрут имеется.

Куда копать?

[azz 0]

Можете в журнал ip пакетов посмотреть, на предмет есть ли два одинаковых соединения.

[spec89 0]

IP источника разные, но порты источника одинаковые. IP адреса назначения есть как одинаковые так и разные.

[zero 0]

22 часа назад, spec89 сказал:

Куда копать?

Думаю, что разумно копать в ТП. Сомневаюсь, что кто-то на форуме будет бесплатно и профессионально анализировтаь Ваш журнал ip-пакетов на предмет совпадения записей.  Тут нужен полноценный анализ и эксперт, тем более, что версия у Вас довольно свежая.

[spec89 0]

Спасибо! Запрос направил.

[metlt 0]

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

[metlt 0]

никто не может помочь ?

[R.Sheyn 0]

Вы хоть схемку накидайте примерно, где этот координатор в схеме, что за координатор, версия.

Вообще такая проблема с GRE существует.

[metlt 0]

24 минуты назад, R.Sheyn сказал:

Вы хоть схемку накидайте примерно, где этот координатор в схеме, что за координатор, версия.

Вообще такая проблема с GRE существует.

Випнет клиент:

Версия ПО: 4.3(2.46794) RUS
Версия ОС: Microsoft Windows Server 2012 R2 Server Standard Edition (full installation), 64-bit (build 9600.winblue_r4.141028-1500)

Випнет Координатор:

Версия ПО: 4.3(2.37273) RUS
Версия ОС: Microsoft Windows 7 Ultimate Edition, 32-bit Service Pack 1 (build 7601.win7sp1_ldr_escrow.180422-1430)

 

[R.Sheyn 0]

14 минут назад, metlt сказал:

Випнет клиент:

Версия ПО: 4.3(2.46794) RUS
Версия ОС: Microsoft Windows Server 2012 R2 Server Standard Edition (full installation), 64-bit (build 9600.winblue_r4.141028-1500)

Випнет Координатор:

Версия ПО: 4.3(2.37273) RUS
Версия ОС: Microsoft Windows 7 Ultimate Edition, 32-bit Service Pack 1 (build 7601.win7sp1_ldr_escrow.180422-1430)

 

Т.е. Вы с випнет клиента поднимаете GRE туннель до туннелируемого узла, потом с другого випнет клиента тоже пытаетесь поднять gre туннель до этого узла? И при этом на координатора у вас сорс нат? Да, в этом случае нормально, что вы получаете 104 событие, отключайте нат.

[metlt 0]

22 минуты назад, R.Sheyn сказал:

Т.е. Вы с випнет клиента поднимаете GRE туннель до туннелируемого узла, потом с другого випнет клиента тоже пытаетесь поднять gre туннель до этого узла?

да все верно

23 минуты назад, R.Sheyn сказал:

 И при этом на координатора у вас сорс нат? Да, в этом случае нормально, что вы получаете 104 событие, отключайте нат.

если я отключу нат, сеть развалится

Объясню зачем подымаем впн, на випнет клиенте крутится база 1с, по виртуальному ип адресу к базе не могу подключиться, а локальные сети пересекаются адресацией, придумал только так, может вы подскажите как разрулить эту тему

[R.Sheyn 0]

12 минут назад, metlt сказал:

на випнет клиенте крутится база 1с,

т.е. на двух випнет клиентах? если вы пытаетесь поднять два туннеля с двух клиентов?

12 минут назад, metlt сказал:

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

поясните пожалуйста.

Я так понимаю, у вас default gw для туннелируемого узла не координатор? что мешает на маршрутизаторе, который является default gw написать статический маршрут на виртуальные адреса через координатор? или написать статику на самом туннелируемом узле.

 

С натом не получится никак поднять GRE, действительно socketpair совпадает: сорс адрес из-за ната один, протокол один и дест адрес один, полная идентичность. Ну если только натить каждого випнет клиента в разный адрес...

[metlt 0]

Только что, R.Sheyn сказал:

т.е. на двух випнет клиентах? если вы пытаетесь поднять два туннеля с двух клиентов?

 

да забываю сказать, что да, два випнет клиента

Только что, R.Sheyn сказал:

Я так понимаю, у вас default gw для туннелируемого узла не координатор? что мешает на маршрутизаторе, который является default gw написать статический маршрут на виртуальные адреса через координатор? или написать статику на самом туннелируемом узле.

да default gw не координатор, это вообще другая сеть

1 минуту назад, R.Sheyn сказал:

поясните пожалуйста.

я в 1с не селен, но мне админ 1с сказал так, что если я клиентом 1с подключаюсь к базе по виртуальному адресу, то ничего не получается, типа 1с сервер не видит этот виртуальный адрес

[R.Sheyn 0]

14 минут назад, metlt сказал:

я в 1с не селен, но мне админ 1с сказал так, что если я клиентом 1с подключаюсь к базе по виртуальному адресу, то ничего не получается, типа 1с сервер не видит этот виртуальный адрес

1с админ очевидно не понимает как это все работает и ему лень вникать.

Не если такое дело, то можно попробовать так.

21 минуту назад, R.Sheyn сказал:

Ну если только натить каждого випнет клиента в разный адрес...

 

[metlt 0]

Только что, R.Sheyn сказал:

1с админ очевидно не понимает как это все работает и ему лень вникать.

т.е. можно все настроить и на виртуальных ип ?

[R.Sheyn 0]

13 минут назад, metlt сказал:

т.е. можно все настроить и на виртуальных ип ?

я не вижу проблем, на 1с в клиенте переключаете туннели на виртуальную видимость и снимаете галочку не туннелировать адреса локальной сети(это чтобы побороть пересечение сетей)

на туннеле обращаетесь к клиенту по виртуальному адресу.

[metlt 0]

Помоги еще раз, я реально уже запутался, как мне организовать лучше доступ из открытой сети до випнет клиента ?

[metlt 0]

Ребята помогите, не получается и все тут

[R.Sheyn 0]

Из открытой сети идете на виртуальный адрес випнет клиента. На самом випнет клиенте выставляете для туннелей координатора виртуальную видимость и выключаете галочку не туннелировать адреса локальной сети.

[metlt 0]

11 минут назад, R.Sheyn сказал:

Из открытой сети идете на виртуальный адрес випнет клиента. На самом випнет клиенте выставляете для туннелей координатора виртуальную видимость и выключаете галочку не туннелировать адреса локальной сети.

Смотрите, на маршрутизаторе(192.168.0.1) я создаю маршрут 11 сети до 192.168.0.12, на координаторе (192,168,0,12) я создаю туннель 

правильно ?

[R.Sheyn 0]

28 минут назад, metlt сказал:

Смотрите, на маршрутизаторе(192.168.0.1) я создаю маршрут 11 сети до 192.168.0.12, на координаторе (192,168,0,12) я создаю туннель 

правильно ?

Адреса с которых вы будете обращаться добавляется в туннель на координаторе через ЦУС. Да, на маршрутизаторе пишете маршрут на 11 сеть через координатор. Нат вам не нужен.

[metlt 0]

В 27.11.2019 в 12:04, R.Sheyn сказал:

Адреса с которых вы будете обращаться добавляется в туннель на координаторе через ЦУС. Да, на маршрутизаторе пишете маршрут на 11 сеть через координатор. Нат вам не нужен.

Спасибо за помощь, с маршрутизатора 192.168.0.пинг на 1 11.0.0.70 есть, а например машина за маршрутизатором 192.168.0.50 уже нет, я так думаю потому что 11.0.0.70 не знает о 0.150

Вот такие события на коордианторе 0.12