Нет Связи По Vipnet Монитор

[slavanchuk]

Разобрался. Нужно прописать на координаторе в мониторе фильтры и правила трансляции адресов, причём одновременно.

Всем спасибо за обсуждение темы.

Да, действительно. В координаторе же есть собственное натирование, которым всегда можно воспользоваться вместо штатного в windows server. С другой стороны, он и с тем должен был работать - у меня несколько лет назад в подобном случае это получилось.

[Dmitrey_61]

Если только NAT правило написать, то не будет работать. Нужно ещё написать правила в фильтрах открытой сети.

[slavanchuk]

Если только NAT правило написать, то не будет работать. Нужно ещё написать правила в фильтрах открытой сети.

Согласен. Открытые компьютеры же к VPN не относятся, так что это - открытая сеть.

[demda]

Здравствуйте! подскажите пожалуйста умеет ли СУ VipNEt работать через два канала дело в том что у нас есть две сети первая это собственно интернет а вторая это наш интранет координатор подключен и туда и туда многие клиенты тоже имеют доступ и в глобал и в наш интранет и те хосты которые зацеплены только в интранет не хотят кате6горически через него цепляться а когда пропадает глобал происходит полное падение защищенной сети. IP адреса доступа из интранет фиксируются и на клиентах и на координаторе. В чем может быть проблема?

[slavanchuk]

Здравствуйте! подскажите пожалуйста умеет ли СУ VipNEt работать через два канала дело в том что у нас есть две сети первая это собственно интернет а вторая это наш интранет координатор подключен и туда и туда многие клиенты тоже имеют доступ и в глобал и в наш интранет и те хосты которые зацеплены только в интранет не хотят кате6горически через него цепляться а когда пропадает глобал происходит полное падение защищенной сети. IP адреса доступа из интранет фиксируются и на клиентах и на координаторе. В чем может быть проблема?

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

Из Вашей фразы не очень понятна ситуация. Распишите, пожалуйста, подробнее что и куда подключено, какие подсети и тому подобное.

[demda]

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

Из Вашей фразы не очень понятна ситуация. Распишите, пожалуйста, подробнее что и куда подключено, какие подсети и тому подобное.

Выглядит это следующим образом у нас в городе есть интранет сеть (корпоративная, поддерживаемая городской администрацией построенная на cisco) в эту сеть подключены некоторые органы исполнительной власти, кроме того в каждый орган исполнительной власти подключен интернет (глобал), во всех вышеописаных учреждениях есть клиенты и есть несколько организаций в которых имеются координаторы, которые тунелируют определенные незащищенные сервера вот эти самые координаторы имееют подключение в глобал и в наш интранет. Интранет организован следующим образом: имееются роутеры cisco в каждом органе власти которые между собой объеденены в центральный роутер cisco между ними организована маршрутизация ip адреса выдаются следующим образом: на каждую cisco выдается своя подсеть 10.33.xx.yy где xx-номер сети, за который отвечает своя cisco ну а yy - это номер хоста маска у каждой посети 24-я как я уже писал выше все они между собой маршрутизируются координаторы подключены в cisc'и НАПРЯМУЮ то есть имеют адреса из сетей 10.33 также все координаторы подключены в интернет (некоторые напрямую на глоб. IP) некоторые через статические МЭ, некоторые через динамические) в органах власти IP-адреса (на всех машинах втч на тех где клиенты) из диапазанов 192.168 на границе их сетей стоят МЭ (не координаторы) которые сами маршрутизируют сл. образом 0.0.0.0/0.0.0.0 ->на провайдера (через NAT) 10.33.0.0/255.255.0.0 на cisco (тоже через nat) раньше так не делали а каждой машине выдавали второй адрес из сети 10.33. а cisco подключали непосредственно в комутатор но потом начались гадости и колизии в сетях связанные с бродкастами и все ушли на NAT(это было до разворачивания VIpNet-сети). Сейчас при пропадании интернета (неважно где на координаторе или на клиенте) через интранет связи нет хотя в адресах координатора адрес интранета зафиксирован этот адрес виден с клиента в свойствах координатора, однако связи нет. Если потребуются еще уточнения с удовольствием отвечу. Вот картинка со схемой, извините за то***сть времени рисовать красиво не было в паинте делал.

[slavanchuk]

Выглядит это следующим образом у нас в городе есть интранет сеть (корпоративная, поддерживаемая городской администрацией построенная на cisco) в эту сеть подключены некоторые органы исполнительной власти, кроме того в каждый орган исполнительной власти подключен интернет (глобал), во всех вышеописаных учреждениях есть клиенты и есть несколько организаций в которых имеются координаторы, которые тунелируют определенные незащищенные сервера вот эти самые координаторы имееют подключение в глобал и в наш интранет. Интранет организован следующим образом: имееются роутеры cisco в каждом органе власти которые между собой объеденены в центральный роутер cisco между ними организована маршрутизация ip адреса выдаются следующим образом: на каждую cisco выдается своя подсеть 10.33.xx.yy где xx-номер сети, за который отвечает своя cisco ну а yy - это номер хоста маска у каждой посети 24-я как я уже писал выше все они между собой маршрутизируются координаторы подключены в cisc'и НАПРЯМУЮ то есть имеют адреса из сетей 10.33 также все координаторы подключены в интернет (некоторые напрямую на глоб. IP) некоторые через статические МЭ, некоторые через динамические) в органах власти IP-адреса (на всех машинах втч на тех где клиенты) из диапазанов 192.168 на границе их сетей стоят МЭ (не координаторы) которые сами маршрутизируют сл. образом 0.0.0.0/0.0.0.0 ->на провайдера (через NAT) 10.33.0.0/255.255.0.0 на cisco (тоже через nat) раньше так не делали а каждой машине выдавали второй адрес из сети 10.33. а cisco подключали непосредственно в комутатор но потом начались гадости и колизии в сетях связанные с бродкастами и все ушли на NAT(это было до разворачивания VIpNet-сети). Сейчас при пропадании интернета (неважно где на координаторе или на клиенте) через интранет связи нет хотя в адресах координатора адрес интранета зафиксирован этот адрес виден с клиента в свойствах координатора, однако связи нет. Если потребуются еще уточнения с удовольствием отвечу. Вот картинка со схемой, извините за то***сть времени рисовать красиво не было в паинте делал.

Что касается linux-координаторов и HW1000, то у них есть возможность сконфигурировать работу с определёнными узлами через определённый канал. Это - секция channels в iplir.conf. Я об этом уже писал на форуме. В этой секции вы описываете каждый канал.

[channels]
channel= LocalNet, WorkDepartmentGroup, OtherGroup
channel= ReservLocalNet
channel= Internet, SalesDepartmentGroup

А в настройках работы с определённым координатором или клиентом определить channelfirewallip и channelport. В этом случае, можно, к примеру, сделать работу с корпоративными координаторами только через корпоративный канал.

Что касается клиентов, то тут всё проще. На них должна стоять настройка "с динамической трансляцией" и в адресных справочниках координатора стоять должны все возможные IP (интра и интернет). Какой у вас режим работы через межсетевой экран стоит на клиентах? Если эти условия выполнены, то проблемы уже с общесетевой маршрутизацией. Для каждого координатора в настройках клиента на разные адреса (разных сетей) вы можете ставить метрику, чтобы отдавать предпочтение определённым каналам, а также менять порядок этих адресов.

[demda]

Что касается linux-координаторов и HW1000, то у них есть возможность сконфигурировать работу с определёнными узлами через определённый канал. Это - секция channels в iplir.conf. Я об этом уже писал на форуме. В этой секции вы описываете каждый канал.

[channels]
channel= LocalNet, WorkDepartmentGroup, OtherGroup
channel= ReservLocalNet
channel= Internet, SalesDepartmentGroup

А в настройках работы с определённым координатором или клиентом определить channelfirewallip и channelport. В этом случае, можно, к примеру, сделать работу с корпоративными координаторами только через корпоративный канал.

Что касается клиентов, то тут всё проще. На них должна стоять настройка "с динамической трансляцией" и в адресных справочниках координатора стоять должны все возможные IP (интра и интернет). Какой у вас режим работы через межсетевой экран стоит на клиентах? Если эти условия выполнены, то проблемы уже с общесетевой маршрутизацией. Для каждого координатора в настройках клиента на разные адреса (разных сетей) вы можете ставить метрику, чтобы отдавать предпочтение определённым каналам, а также менять порядок этих адресов.

В том и дело, что в настройках клиента стоит МЭ с динамической трансляцией. IP-адреса доступа в справочниках есть (интер и интра) координаторы есть 1000 есть 2000 а есть и софтварные на винде. Про проблемы с общесетевой маршрутизацией исключены так как без клиента доступ ко всем узлам интранета есть и даже если в настройках фильтров открытой сети на координаторе создать разрешающие правило к нему можно достучатся пингами (втч с машины с клиентом). Вот с метрикой стоит подумать идея хороша. Я попробую. Кстати если пропадает глобал координаторы между собой тоже не могут установить соединения хотя подключены в интранет они без МЭ. и по разрешающим правилам открытой сети достают друг-друга (например пингом). Если есть еще какие-то идеи кроме метрики напишите пожалуйста. Я с метрикой поэкспериментирую и отпишусь.

[slavanchuk]

Обязательно попробуйте настроить на координаторах каналы, чтобы они принудительно работали через интранет. Это должно обеспечить бОльшую стабильность.

[demda]

Обязательно попробуйте настроить на координаторах каналы, чтобы они принудительно работали через интранет. Это должно обеспечить бОльшую стабильность.

Это да, есть только один момент через глобал они тоже работать должны есть таки у кого интранета нет. Вот только с метрикой не удалось. Ну не желает он через интранет-каналы цеплятся и все

[demda]

Это да, есть только один момент через глобал они тоже работать должны есть таки у кого интранета нет. Вот только с метрикой не удалось. Ну не желает он через интранет-каналы цеплятся и все

Эксперименты с метриками на клиентах ничего не дали при пропадании интернета не желает цеплятся через интранет. Может быть еще есть какие идеи?

[slavanchuk]

Это да, есть только один момент через глобал они тоже работать должны есть таки у кого интранета нет. Вот только с метрикой не удалось. Ну не желает он через интранет-каналы цеплятся и все

Вы можете индивидуально настраивать с какими узлами по какому каналу работать. Допустим, координаторы - только по интранет. Это делается на раз-два при помощи channels.

[slavanchuk]

Эксперименты с метриками на клиентах ничего не дали при пропадании интернета не желает цеплятся через интранет. Может быть еще есть какие идеи?

А в блокированных пакетах ничего нет? И интересно было бы посмотреть журнал пакетов координатора, к которому без интернета он прицепиться не может. Возможно, по какой-то причине идёт блокировка. Но это, больше как предположение. Но проверить нужно.

[demda]

А в блокированных пакетах ничего нет? И интересно было бы посмотреть журнал пакетов координатора, к которому без интернета он прицепиться не может. Возможно, по какой-то причине идёт блокировка. Но это, больше как предположение. Но проверить нужно.

Проблема стала понятна на двух координаторах hw1000 и hw2000 , которые настравались и конфигурировались когда-то давно кто-то натроил работу по виртуальным IP и для какик-то целей замаршрутизировал их на интернет-интерфейс (а эти координаторы являются серверами адресов для большинства СУ). Спасибо всем, кто принимал участие. Сейчас возник такой вопрос в одном из ведомств, где есть клиент с настройкой МЭ через динамичесткий НАТ и МЭ (не координатор) хочу разместить софтварный координатор под виндой, поставив его в разрыв интернет-канала между провайдером и межсетевым экраном (не координатором там kerio control) избавляться от керио не хочется так-как есть резервный интернет-канал и настроена балансировка. Вопрос такого плана у меня в сети есть еще клиент чужой защищенной сети (тоже настроен через МЭ с динамическим НАТ) не повлияет ли установка координатора по вышеприведенной схеме на работу "чужого" клиента? Просто мне рассказывали, что такие казусы бывали.

[slavanchuk]

Да, казусы есть. В случае, если они работают по одному порту (например, 55777), то, если связи между координатором и клиентом сторонней сети нет (межсетевое взаимодействие), то VipNet будег говорить, что не найден ключ для сетевого узла. В принципе, если развести их по разным портам (например, координатор работает через 55777, а клиент через 55888), то они не должны конфликтовать. VipNet будет обрабатывать 55888 как обычный трафик. Либо они не должны пересекаться. У нас основной межсетевой экран - сертифицированная Cisco и координаторы уже как экраны второго уровня. Для клиента просто настроен NAT.

[AnTonN(c)]

...VipNet будет обрабатывать 55888 как обычный трафик...

ViPNet всегда "увидит" защищенный трафик и не важно на каком сетевом (кроме режима 5) или протокольном портах! Транзит защищенного трафика возможен только при условии связи транзитного узла с конечными. Есть еще схемы с "зелеными" узлами, да только разобраться как они работают пока не знаю: ни в документации не описано, ни на словах мало кто знает.

[demda]

Да, казусы есть. В случае, если они работают по одному порту (например, 55777), то, если связи между координатором и клиентом сторонней сети нет (межсетевое взаимодействие), то VipNet будег говорить, что не найден ключ для сетевого узла. В принципе, если развести их по разным портам (например, координатор работает через 55777, а клиент через 55888), то они не должны конфликтовать. VipNet будет обрабатывать 55888 как обычный трафик. Либо они не должны пересекаться. У нас основной межсетевой экран - сертифицированная Cisco и координаторы уже как экраны второго уровня. Для клиента просто настроен NAT.

Спасибо, за участие. Попробую так и сделать

[demda]

...VipNet будет обрабатывать 55888 как обычный трафик...

ViPNet всегда "увидит" защищенный трафик и не важно на каком сетевом (кроме режима 5) или протокольном портах! Транзит защищенного трафика возможен только при условии связи транзитного узла с конечными. Есть еще схемы с "зелеными" узлами, да только разобраться как они работают пока не знаю: ни в документации не описано, ни на словах мало кто знает.

А как Вы можете посоветовать развести данную ситуацию?

[slavanchuk]

...VipNet будет обрабатывать 55888 как обычный трафик...

ViPNet всегда "увидит" защищенный трафик и не важно на каком сетевом (кроме режима 5) или протокольном портах! Транзит защищенного трафика возможен только при условии связи транзитного узла с конечными. Есть еще схемы с "зелеными" узлами, да только разобраться как они работают пока не знаю: ни в документации не описано, ни на словах мало кто знает.

А по какой логике тогда VipNet определяет - его трафик или не его? В пределах одной сети он смотрит трафик по адресам, а если видит чужой транзитный трафик, то ругнётся на ключ. А в случае, если это упакованный в UDP пакет по совершенно постороннему порту для отправки во внешнюю сеть, разве он будет все UDP пакеты мониторить? И зачем VipNet-ту какие-то метки присваивать.

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

[AnTonN(c)]

2demda:

Тут два варианта: пускать трафик клиента в обход координатора или делать межсеть, то есть связывать по ТК.

2slavanchuk:

...А по какой логике тогда VipNet определяет - по заголовкам. Всем известно, что идентификаторы СУ уникальны и не могут пересечься: первые 4 - номер сети, следующие 4 - номер СУ. Вот она и идентификация.

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

...упакованный в UDP пакет по совершенно постороннему порту...- если шифрованный трафик, то он его определит. Если открытый, то правилами firewall и/или режимами обработается.

... какие-то метки присваивать... - конечно присваивает, только не метки, а заголовки. Инкапсуляция в udp ж идет.

...Ваше возражение проверено на практике или это догадка?... - это реальная практика.

[slavanchuk]

2demda:

Тут два варианта: пускать трафик клиента в обход координатора или делать межсеть, то есть связывать по ТК.

2slavanchuk:

...А по какой логике тогда VipNet определяет - по заголовкам. Всем известно, что идентификаторы СУ уникальны и не могут пересечься: первые 4 - номер сети, следующие 4 - номер СУ. Вот она и идентификация.

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

...упакованный в UDP пакет по совершенно постороннему порту...- если шифрованный трафик, то он его определит. Если открытый, то правилами firewall и/или режимами обработается.

... какие-то метки присваивать... - конечно присваивает, только не метки, а заголовки. Инкапсуляция в udp ж идет.

...Ваше возражение проверено на практике или это догадка?... - это реальная практика.

Ну, если то, как говорит AnTonN© верно, то в этом случае только связывать сети или использовать другой межсетевой экран на выходе из сети. Хотя, если это клиент какой-то сторонней сети, то не всегда люди пойдут на связывание. А если это клиент Инфотекс-Интернет Траст, то они вообще берут деньги за связывание узлов со своей сетью.

[Chezok]

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

Клиент обычный виндоузный версии 3.1.5 и координатор HW1000. Так вот, клиент выдаёт точно такое сообщение, что и в первом посте. При этом пинги что до туннельных машин, что до самого координатора по виртуальному IP проходит. Обновления от администратора тоже доходят до клиента. Но випнет постоянно ругается что координатор не доступен.

Я как понял наблюдается такая проблема на версиях младше 3.2 и hw координатором (сужу из второго поста). Как с этим можно побороться ? Обновление клиента до версии 3.2 ?

[AnTonN(c)]

2 Chezok: такое может быть, если на HW выполнена команда iplir stop и после нее не выполнена команда iplir start. Коротко говоря, не запущен демон iplir.

[Chezok]

2 Chezok: такое может быть, если на HW выполнена команда iplir stop и после нее не выполнена команда iplir start. Коротко говоря, не запущен демон iplir.

Не всё так просто, iplir запущен. т.к. банально с соседнего клиента координатор доступен. Да и проверялось не раз, и iplir пере запускался.

UPD: Обновил с версии 3.1 до 3.2, всё заработало. Предыдущие разу переустановка версии 3.1 не помогала.

[slavanchuk]

2demda:

Тут два варианта: пускать трафик клиента в обход координатора или делать межсеть, то есть связывать по ТК.

2slavanchuk:

...А по какой логике тогда VipNet определяет - по заголовкам. Всем известно, что идентификаторы СУ уникальны и не могут пересечься: первые 4 - номер сети, следующие 4 - номер СУ. Вот она и идентификация.

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

...упакованный в UDP пакет по совершенно постороннему порту...- если шифрованный трафик, то он его определит. Если открытый, то правилами firewall и/или режимами обработается.

... какие-то метки присваивать... - конечно присваивает, только не метки, а заголовки. Инкапсуляция в udp ж идет.

...Ваше возражение проверено на практике или это догадка?... - это реальная практика.

Проверил-таки на практике. Действительно, даже по разным портам развести не получится. Довольно трудоёмко получается для iplir смотреть содержание каждого пакета. Тем не менее, он так работает. Так что, действительно - либо в обход, либо межсетевое взаимодействие.