Настройки Удаленного Клиента От А До Я

[Отдел ИБ]

Доброго времени суток.

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

Используемое ПО и ПАК: координатор HW1000, Client 3.1(1.5030).

Координатор находится в 3 режиме, без использования межсетевого экрана.

Внутренние ip-адреса интерфесов:

172.20.36.99

192.168.36.22

10.241.0.4

Вначале опишу, что я сделал.

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

В настройках защищенной сети выбрал следующие данные:

Т.е., помимо указанного мной внешнего ip координатора добавляется в качестве МЭ внутренний адрес одного из интерфейсов координатора, и эти сведения скорее всего он получает через интернет, поскольку каждый раз я удаляю этот адрес (10.241.0.4), и секунды на 2-3 координатор становится доступным. Но потом события с непонятной очередностью могут сложиться в 2 направлениях:

1) Остается только указанный мной внешний IP координатора, но при этом перестает быть активным чекбокс "Использовать виртуальные адреса", как следствие подключиться через интернет невозможно.

2) Во вкладке межсетевой экран вновь появляется адрес 10.241.0.4, "Использовать виртуальные адреса" по-прежнему доступно и чекбокс остается выбранным, НО более приоритетным оказывается адрес 10.241.0.4. И даже, если я его опускаю ниже по приоритету либо выставляю большую метрику, координатор все равно остается недоступным, поскольку снова становятся недоступными виртуальные адреса.

Спасибо тем, кто дочитал(:

Собственно, вопросы:

1) От чего зависит доступность чекбокса "Использовать виртуальные адреса"?

2) Как избавиться от постоянного обновления адреса 10.241.0.4 (я уже и пробовал менять firewallip в iplir, и удалять адрес третьего интерфейса координатора в iplir). Откуда вообще эти адреса поступают? Раньше я думал, что из iplir, но уже под сомнением...

Заранее благодарен тем, кто откликнется.

[Отдел ИБ]

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

В файле iplir.conf координатора в секции firewallip клиента, участвующего в межсетевом взаимодействии, стоит ip 10.241.0.4, хотя должен стоять внешний ip координатора (скриншот ниже).

Если я меняю адрес firewallip на внешний и стартую демон iplir, затем вновь останавливаю его и смотрю конфигурацию, firewallip для этого клиента вновь сбрасывается в 10.241.0.4.

Т.е. проблема, как оказалось, более глобальна.

Откуда iplir берет этот firewallip? в секции [dynamic] выставил firewallip в нужное значение, он сохранил свое значение.

[ПлотниковВН]

параметры координатора можно задавать в ЦУС. Опции s: , e: ...

Групповая регистрация узлов в задачах - Coordinator HW-1000 - IP-адреса

Подробнее описано в документации по ЦУС...

[Отдел ИБ]

спасибо за ответ, было дело, пробовал, прописанные в ЦУС адреса по приоритету все равно ниже, получается, как таковой разницы нет, что прописывать адреса в справочники, что напрямую на клиенте.

а по-поводу "использования виртуальных адресов" просветить сможете?

[ПлотниковВН]

по-поводу "использования виртуальных адресов" просветить сможете?

К сожалению опыта работы с виртуальными адресами у меня лично нет... только теоретически, но этого мало чтобы советовать что-то по ним...

[diip]

А нельзя просто прописать явно маршрут на этот АП( или подсеть) в координаторе ? средствами командной строки:

# ip route add подсеть/28 via 172.20.36.99 dev eth1 ..чтото типа такого.

У меня много таких маленьких подсеток идущих через всякие впны(ростелекома и прочих) .Снаружи и внутри от координатора . Но у меня только 2 интерфейса на координаторе . А разруливает эти пакеты в дальнейшем роутер на линухе . Раньше подобная вещь появлялась постоянно. Явное указание маршрута в координаторе на АП устраняет проблему . У меня , по крайней мере.

[Отдел ИБ]

А нельзя просто прописать явно маршрут на этот АП( или подсеть) в координаторе ? средствами командной строки:

# ip route add подсеть/28 via 172.20.36.99 dev eth1 ..чтото типа такого.

У меня много таких маленьких подсеток идущих через всякие впны(ростелекома и прочих) .Снаружи и внутри от координатора . Но у меня только 2 интерфейса на координаторе . А разруливает эти пакеты в дальнейшем роутер на линухе . Раньше подобная вещь появлялась постоянно. Явное указание маршрута в координаторе на АП устраняет проблему . У меня , по крайней мере.

Спасибо за ответ.

Дело в том, что раньше удаленные VipNet-клиенты спокойно ходили до координатора и связывались с внутренними клиентами, маршрутизация однозначно в порядке.

Насколько я понимаю, клиент должен сообщать координатору свой ip-адрес. Адрес координатора как раз прописан во вкладке "Межсетевой экран". Но поскольку реальный внешний адрес координатора постоянно сбрасывается в 10.241.0.4, то клиент не может достучаться до координатора => координатор не может связаться с клиентом, поскольку не получил от него его текущий ip.

[Rinya]

Добрый день!

Попробуйте посмотреть в iplir.conf в секции [adapter] на каком из интерфейсов стоит type=internal, возможно у вас стоит эта надпись на интерфейсе который имеет адрес

10.241.0.4, поэтому клиенты считают его приоритетным, т.е. внешним. Пропишите type=internal на интерфейсе который внешний, думаю поможет.

[ingenico]

Судя по всему, ваш Координатор спрятан за корпоративным файерволлом. Поэтому ближайший к этому файерволлу интерфейс Координатора, должен быть External. В документации подробно описаны настройки iplir.conf для такого подключения. Или можно в ЦУС прописать соответствующую строчку, чтобы удаленные Клиенты сразу понимали куда им коннектится.

[Rinya]

Действительно, external. напутал в верхнем ответе.

[AnTonN(c)]

Рекомендую статику без фиксации выставлять на координаторах.

То есть переведите координатор в статику.

[Отдел ИБ]

Судя по всему, ваш Координатор спрятан за корпоративным файерволлом. Поэтому ближайший к этому файерволлу интерфейс Координатора, должен быть External. В документации подробно описаны настройки iplir.conf для такого подключения. Или можно в ЦУС прописать соответствующую строчку, чтобы удаленные Клиенты сразу понимали куда им коннектится.

Действительно, external. напутал в верхнем ответе.

Данные настройки уже выставлены, для двух внутренних интерфейсов стоит internal, а для интерфейса, который стоит за МЭ, стоит external.

[Отдел ИБ]

Рекомендую статику без фиксации выставлять на координаторах.

То есть переведите координатор в статику.

Статическую трансляцию адресов сделать?

Я в четверг скину основные настройки координатора, может это даст какие-то зацепки.

[AnTonN(c)]

И маршрутизацию не забудьте.

[ssl_236]

недавно у меня такая же была проблема но решилась установкой обоих адаптеров в состояние internal т.к. ПАК смотрит напрямую в инет, раньше стоял за файрволои тогда на внешнем было external. Как я думаю надо смотреть в сторону настройки при размещениии за файрволом со статической трансляцией

[Отдел ИБ]

Настройки в файле iplir

1. Сам координатор

2. Клиент, который соединяется удаленно (красными вопросами отмечены строчки, в которых непонятно, откуда берутся ip-адреса. Я их и менять пробовал, и удалять, все равно сбрасываются в эти значения).

3. Параметры интерфейсов координатора, настройки работы

4. Настройки интерфейсов (eth2 отключен в силу временной ненадобности).

5. Маршрутизация

6. Настройки ip-адресов в ЦУС для клиента и координатора.

Пробовал прописывать в ЦУС внешний ip-адрес для координатора и формировал новые справочники + дистрибутив для удаленного клинета, не помогло.

Повторюсь, основные проблема в том, что:

1) На клиенте не доступен чекбокс "Использовать виртуальные ip-адреса" (Выбран режим работы через МЭ и динамическая трансляция адресов)

2) В настройках МЭ на клиенте автоматически приоритетнее выставляется ip 10.241.0.4 вместо заданного ручками или прописанного в дистрибутиве внешнего ip-адреса координатора (файерволла).

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

[Rinya]

Давайте попробуем следующим образом.

Выставьте значение fixfirewall= off

в секции [dynamic] значение firewallip=0.0.0.0

что получится?

[AnTonN(c)]

1. как и в предыдущем посте fixfirewall= off

2. Кто такой 172.20.36.23?

3. Дополнительно пришлите скрин вкладки Инфо с клиента.

4. В ЦУС для координатора пропишите одиночный ip: 176.x.x.36

5. Взаимодействие через Интернет?

Координатор вообще считает, что клиент в одной подсети с ним. Маска 16. Как себя поведет координатор? Честно не знаю. Вроде на виртуальные перешел, но кто знает...

Я бы еще одну вещь сделал: запустил tcpdump на eth1 координаторе и посмотрел есть ли arp запросы на адреса 172.20.0.35 и 172.20.47.223.

Секцию dynamic вообще не трогаем, так как dynamic_proxy= off. А это значит, что она не обрабатывается.

[Отдел ИБ]

Скорее всего, вы будете долго и очень громко смеяться..

На решение меня натолкнула запись про ip-адрес 172.20.0.35. Я вспомнил, что дома я делал адресацию по такому же принципу, как и на работе, и поэтому 172.20.0.35 - локальный ip моего ноутбука => когда я пытаюсь удаленно подключиться, випнет клиент видит, что мы находимся в одной сети с координатором и пытается подключиться по реальным адресам...

Сейчас поменял дома адресацию, координатор стал доступен.

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

[AnTonN(c)]

Все хорошо, что хорошо кончается.