Тунель на HW1000 и ЦУС

[Польз44]

Здравствуйте! Имеется координатор vipnet HW1000 на нем зарегистрированы более 200 АП. Все АП используют VipNet монитор. В ЦУСе туннели для координатора не прописаны, а прописаны вручную на координаторе (tunnel= ).

Интересует такой вопрос: если в ЦУСе добавить новый туннель, разослать обновления, то не затрутся ли туннели прописанные вручную?

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

[xrockx]

Рекомендую внести в ЦУС'е все туннели, которые Вы используете.

По практике после добавления туннеля в ЦУС'е и рассылки обновлений, происходит затирание туннелей прописанных руками на Координаторах.

 

[Польз44]

1 час назад, xrockx сказал:

Рекомендую внести в ЦУС'е все туннели, которые Вы используете.

По практике после добавления туннеля в ЦУС'е и рассылки обновлений, происходит затирание туннелей прописанных руками на Координаторах.

 

Этого мы и боялись. Просто не всем VipNet клиентам нужны ВСЕ туннели. Получается они пропишутся у всех?

[ingenico]

Туннели из ЦУС пропишутся у всех Клиентов, которые работают с вашим HW1000. Ограничивать доступ конкретным Клиентам к конкретным туннелям можно правилами доступа в файле firewall.conf секция tunnel вашего HW1000.

[Польз44]

В 15.12.2015, 6:45:55, ingenico сказал:

Туннели из ЦУС пропишутся у всех Клиентов, которые работают с вашим HW1000. Ограничивать доступ конкретным Клиентам к конкретным туннелям можно правилами доступа в файле firewall.conf секция tunnel вашего HW1000.

а как ограничить некоторых клиентов? можно пожалуйста описать подробнее?

[ingenico]

Синтаксис правил firewall.conf описан в документации. Читайте.

По умолчанию в секции tunnel всего одно разрешающее правило для всех - rule= proto any from any to any pass.

Удаляете его и пишите свои правила.  

Например:

rule= num 1 proto any from anyid to 192.168.5.3  pass
rule= num 10 proto any from 0x1a260010 to 192.168.5.2  pass
rule= num 20 proto any from 0x1a260010 to 192.168.11.2  pass

Лучше использоват идентификаторы узлов в правилах, т.к. IP-адреса самих узлов могут ведь меняться.

Идентификаторы можно посмотреть в iplir.conf

[Польз44]

1 час назад, ingenico сказал:

По умолчанию в секции tunnel всего одно разрешающее правило для всех - rule= proto any from any to any pass.

Удаляете его и пишите свои правила.  

Например:

rule= num 10 proto any from 0x1a260010 to 192.168.5.2  pass
rule= num 20 proto any from 0x1a260010 to 192.168.11.2  pass

т.е. если я правильно понимаю, если прописать туннели в ЦУСе, например, S:192.168.5.1-192.168.11.255 и 2 правила указанные выше, то у всех клиентов будет прописан туннель 192.168.5.1-192.168.11.255, а у клиента 0x1a260010 будет только 2 туннеля: 192.168.5.2 и 192.168.11.2

[Vanish1990]

нет, туннель одинаков будет у всех, просто доступ клиент 0x1a260010 будет иметь только к 192.168.5.2 и 192.168.11.2

[Польз44]

Спасибо. Подумаем как лучше использовать туннели.

[Vintik]

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

Не стал новую тему создавать, почитал 5 шт и решил эта подходящая. Есть тут немного полезной информации в добавок.

\ Очень надеюсь что ingenico из Алма-Ата ещё в деле, дельные советы пишет (или писал если сменил деятельность). \

Вопрос по туннелям простой: 

Есть 2 координатора HW 1000 и 2000 (версия 3.5) (не принципиально думаю, в итоге 2000 должен соед с тремя 1000 + фаловер или...) 

Координаторы стоят на границах и за ними хосты с открытым трафиком.

Делается туннель, соединяются хосты 1000-ка с 2000.

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

На пример, было так (адреса придуманы, но суть та же):

На HW2000 использовал 3 интерфейса 

1) 192.168.0.2/24 - для связи с ПК во внутренней сети 192.168.0.3-254/24 Шлюз на ПК 192.168.0.2. Туннель для 192.168.0.3-254

2) 10.8.8.5/24 - для связи с HW1000 Шлюз 10.8.8.6 (IP HW1000 и Шлюз по умолчанию для HW2000)

3) 10.200.0.2/24 - для связи с ЦУС (10.200.0.3/24 Шлюз 10.200.0.2)

На HW1000 использовал 2 интерфейса 

1) 192.168.1.2/24 - для связи с ПК во внутренней сети 192.168.1.3-254/24 Шлюз на ПК 192.168.1.2. Туннель для 192.168.1.3-254

2) 10.8.8.6/24 - для связи с HW2000 Шлюз 10.8.8.5 (IP HW2000 и Шлюз по умолчанию для HW1000)

=====

Тест прекрасно отработал, из сети 192.168.0 пакеты шифровались, и передавались в 192.168.1 и наоборот. Дополнительно проверил как будет вести если подключить 2-ю сеть, на HW1000 добавил на eth1 IP 10.200.20.2/24 получил eth1:0 за которым были ПК 10.200.20.3-254/24 с шлюзом 10.200.20.2 и включены в туннель 10.200.20.2-254. Туннель заработал, пакеты шифруются HW-ки отлично делают своё дело. Это было собрано для проверки работоспособности, показать как и что делать в ЦУС и УКЦ.

=====

А теперь они хотят чтоб это всё работало так же, но из примера на ПК за границами хотят убрать шлюзы и сети "первые" совпадают. Типа чтоб это было как одна большая сеть. Понятно им придётся тогда контролировать чтоб с одной стороны не было совпадений с другой или тогда там надо дополнительно прописывать чтоб забирало одно, а показывало другое (я так понял из ЦУС такое уже не разослать), МЭ при этом в ЦУСе отключили чтоб "не мешали" (Хотя по моему там снятие галочки не чего не решает особо, если туда не чего не прописывать..)

И в итоге получается примерно вот так из того что было (в тунель возможно прописать и все IP с обеих сторон, но это слишком, т.к. на пример обращаясь к IP 192.168.0.55 с одной стороны имея это в тунели и там и тут - я не знаю куда будет попадать клиент, в свою сеть на 55 или на другую сторону к этому же 55 - как то пролетая по виртуальному.. т.е. как то не логично совсем, тем более если хотят типа чтоб было как одна. Потому разделил): 

На HW2000 использовал 3 интерфейса 

1) 192.168.0.2/24 - для связи с ПК во внутренней сети 192.168.0.3-127/24 Шлюза НЕТ. Туннель для 192.168.0.3-127

2) 10.8.8.5/24 - для связи с HW1000 Шлюз 10.8.8.6 (IP HW1000 и Шлюз по умолчанию для HW2000)

3) 10.200.0.2/24 - для связи с ЦУС (10.200.0.3/24 Шлюз 10.200.0.2)

На HW1000 использовал 2 интерфейса 

1) 192.168.0.254/24 - для связи с ПК во внутренней сети 192.168.1.128-253/24 Шлюза НЕТ. Туннель для 192.168.1.128-253

2) 10.8.8.6/24 - для связи с HW2000 Шлюз 10.8.8.5 (IP HW2000 и Шлюз по умолчанию для HW1000)

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

Вот и задумался, как это можно сделать?

С одной стороны HW-ка очень "умная" если правильно настроить, и по не стандартному пути наверно не хочет работать, который не приводится в инструкциях.

  

 

 

[ingenico]

Нарушена маршрутизация ответных пакетов в туннелях.  Ключевая фраза здесь " Если прописать шлюзом для ПК соответствующие IP координаторов, то начинает всё работать".

Вариантов тут много.

Обычно, если Координатор и туннелируемый ПК находятся в одной сети, но у ПК шлюзом по умолчанию не является IP Координатора, то помогает включение NAT на Координаторе, чтобы на туннелируемый ПК с Координатора уходил пакет, в котором Source IP был бы уже координаторовский.  

Что-то типа  rule= num 10 proto any from anyip to 192.168.0.3-192.168.0.127 change src=192.168.0.2:dynamic

Если NAT'a нет, то Source IP в пакете остается изначальный, про маршрутизацию с которым ПК ничего не знает и тупо шлет ответ на свой шлюз по умолчанию.

"На ПК шлюза нет".  Так не бывает, всё равно какой-то шлюз (не Координатора) там прописан. Скорее всего адрес Cisco или какого-то другого активного сетевого оборудования. Можно на этуCisco добавить маршрутизацию для сетей стоящих за удаленным Координатором (если знаем адреса этих сетей), чтобы ответ далее уходил на первый Координатор.

Или на самих туннелируемых ПК прописать нужные маршруты. Однако это не самый лучший способ.

 

P.S.  ViPNet в Казахстане пытаемся продавать потихоньку, являемся единственными дистрибьюторами этого решения + свой учебный центр, но масштабы продаж конечно же не сопоставимы с РФ  ))   

[Vintik]

Спасибо, точно не понял что надо, но на месте придутся разбираться значит.

А ШЛЮЗА поверьте реально нет. Пне дали типа - вот IP и вот и надо чтоб при разрыве они виделись.

Естественно когда они в одной сети - они видятся (зачем им шлюз если они в одной подсети), даже координатор их видит, просто там режим 2 вот и блокирует "лишних".

Далее настроил всё как описал выше - ну не видятся они если в тунель загонять и всё. 

Думал возможно мне IP не те дали. для есть ПК тестовый. туда вношу IP соотв. сети и вижу что отвечают они. И тут уточняю у вадминистратора - а какой там шлюз указан? На стороне клиента понятно его не могу применить, но на другой стороне при такой тесте мог бы использовать и связь бы появилась... и узнаю - а нет там шлюзом. Есть просто выделенная сеть и вот так начальство обдумало. Да только как видно Випнет по типичной схеме построения так не работает.

[Vintik]

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

Сегодня получил уточнение... оказалось им надо HW-ки без разбора всё принимали и на другой стороне выплёвывали.

Т.е. я так понял на канальном уровне чтоб это было. Некоторые кто не знаком с версией 3,5 мне скару сказали - HW такого делать не может,

но вы наверно видели что может, только ограничений ещё больше. Но это надо проверять.

[Rinya]

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

[Vintik]

Вот только и остаётся наверно L2OverIP в таком случае. Будем пробовать. Но вы наверно знаете что на нём ограничение сильнее чем на "стандартной" технологии. А вот про ограничение "только два" - это пугает, они хотели так 1 соединять с 3-мя, (и по второму каналу ещё так же). Один коллега и вовсе уверял сразу, что HW не умеет на канальном и точка (наверно давно не обновлял информацию).

Где написано что такие ограничения и какая сейчас макс. версия? Возможно им стоит обновиться до 4.6 и там всё "круче"?

И если у вас была практика, то как вы можете подтвердить (опровергнуть): 

Примечание. При использовании технологии L2OverIP рекомендуется, чтобы 
общее число IP-адресов в объединяемых сегментах не превышало 252. 

Разработчики ответили это рекомендация, т.е. если больше то стабильная работа не гарантируется.

[Vintik]

Проверил L2OverIP - по моему понял почему вы сказали только два, там же прописывается локальный* и на который отправлять, и он реально виртуальный.

Т.е. если надо соединить 1 с 3, то ед вариант думал использовать ещё 2 интерфейса (вроде благо есть), но всё равно это не то.

[Vintik]

В док. на HW версии 4.1.1 видно, что разработчики достаточно хорошо увеличили функционал L2OverIP. Ограничение на "одно" подключение убрали и нет необходимости задавать тунелирование, но почему то с дисками пришли обновления даже старее чем в самих координаторах:

На дисках: HW 1000 - hw1000_vipnet_3.5-1323;  HW 2000 - hw2000_vipnet_3.5-737

На HW показывает: HW 1000 - 3.5 (1330);  HW 2000 - 3.5 (741)  Координатор 3.7.3 (6949 и 6950)

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

Хотел запросить обновление, пока покупка свежая, но посмотрел и понял, что нужна 1) " Расширенная ТП Совместная ", а так предосталяют если только найти ошибки. 2) 4-ю версию скорее всего не прислали и не пришлют, т.к. сертификатов на неё нет. Есть только версия 3 пока.

http://www.infotecs.ru/products/catalog.php?SECTION_ID=&ELEMENT_ID=10909

http://infotecs.ru/products/cert/

 

 

[Rinya]

по поводу рекомендаций " Примечание. При использовании технологии L2OverIP рекомендуется, чтобы 
общее число IP-адресов в объединяемых сегментах не превышало 252. " скажу следующее: у нас у одного заказчика используется данный функционал. с одной стороны (за одним координатором) число адресов превышает 252, с другой (за другим координатором) немного меньше. работает уже полгода примерно)))

По поводу соединить 1 с 3 филиалами в версии 3 не получится, и то что " Т.е. если надо соединить 1 с 3, то ед вариант думал использовать ещё 2 интерфейса (вроде благо есть), но всё равно это не то. " нельзя реализовать, так как функционал поднимается не на интерфейсе а в самом софте.

Хороший вопрос по поводу дисков. мне тоже интересно почему на железе приходит версия выше чем на диске.

А по поводу обновиться до версии 4, из своей практики скажу следующее. Этим летом, как раз у заказчика где внедряли сеть и использовали функционал L2OverIP, задались таким же вопросом. Зданий было несколько, но функционал поддерживал только одно соединение. связались с разрабами (благо был сертификат) с вопросом как реализовать связь один со многими, нам ответили "Данный сценарий поддерживается в релизной версии прошивки. Необходимо обновить текущую прошивку." и выслали резил. HW 1000  4.1.3_(1595).Установилось все нормально, но работать не хотело. Толи при логоне, толи после запуска иплира (точно не помню) выдавало ошибку, типа платформа не поддерживается.  

Platform: HW1000 Q4
Version: 3.5 (1330)

Опять написали в саппорт и получили ответ: " На данной платформе максимально возможная версия - 3.5. Функционал с несколькими сегментами l2overip будет доступен для этой платформы после релиза версии 4.2 "  Информация от июня 2016 года. 

У заказчика решили вопрос другим методом. Больше данным вопросом пока не занимались))))

 

[Vintik]

Спасибо за практический ответ, это очень полезный опыт!

А то тут тоже надеемся на, а про разные Q я так же сомневался... Отмечу это, чтоб потом сюрпризов снова не было, хотя они будут, но чтоб уже были готовы хотя бы морально к ним. 

Про 252 понял, как писал Инфотекс тоже не отрицает, что будет работать, но гарантии стабильности падают.

По соединению подтверждаю - только одно. Думал вдруг интерфесами можно не вышло - ограничено портами 1 и 0 и всё тут. Пытался по не правильному пути даже идти, указал на двух удалённых одни и теже заначения IP, в надежде что они же физически в разных сегментах, вдруг HW2000 по вирт подумает, что не и ладно что IP одинаковые...))) И на удивление на ней на поту даже появились МАК адреса от второй HW, но дальше этого не прошло.. т.к. а второй HW не как не появлялись МАК адреса. Фокус не удался.

=====

А версия кстате точно такая же 1000-ка а 2000 Q3

Вот именно такого результата я и опасаюсь, т.к. это не исключено. Очень надеюсь что с июня они доработали билд или сборку 4.2 (где сказали даже ОСПФ должен работать теперь) и всё же то что пишут и обещают клиентам отлично будет работать.

На счёт версии 3,5 и L2 там - понятно, это там он больше как тестовый даже можно назвать, но в принципе работает.

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

Надеюсь просто подкину ЛЗШ и он нормально всё это слопает.

Спасибо.

 

[Rinya]

по обновлению с помощью ЛЗХ архива ничего не скажу, так как обновляли железки с влешки локально, ЦУС был у клиента, а у нас только ДСТ и все. и стенд для проверки собирали в офисе.

Ну я считаю что все должно пройти гладко

[Vintik]

8 минут назад, Rinya сказал:

по обновлению с помощью ЛЗХ архива ничего не скажу, так как обновляли железки с влешки локально, ЦУС был у клиента, а у нас только ДСТ и все. и стенд для проверки собирали в офисе.

Ну я считаю что все должно пройти гладко

 

И после всего вы в это верите?   Так я тоже про локально говорю :-) Но видно не так прочитал.. надо перечитать. Читал что надо на флешку кинуть этот архив.. потом командой админа "апдэйет" - и у меня лично он из 2-х обновлений (специально проверял, что пишут если их там много он найдёт свои) 2000 и 1000 он нашёл 1000. Дальше не пошёл, т.к. уже вы знаете - на дисках версии старее. Где я потом возьму билд 3.5 (1330) обратно. А как с помощью ISO не понял, т.к. дисковода нет, а флешку надо как то делать получается загрузочной. По практике знаю не всегда успешно так получается сделать. 

[Rinya]

как вернуть после обновления на версию  3.5 (1330) - вот честно не помню и найти теперь не могу, но где то здесь на форуме была тема и там кто-то описал как снимали образ с железки с помощью какой-то софтины, мы собственно этим способом то и воспользовались))) но вот найти снова не могу.

[Vintik]

А зачем обратно? 4-я версия же работоспособная? Или вы про то, что там L2 даже в том виде что есть не работает?

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

А так как вариант я думал обновляется только интерпритатор, т.е. подкинуть обратно LZH с того же диску (ну будет там на 1330 а 1328, ну что уж теперь) или обновления обратно не пойдут - вот вы про что наверно предупреждаете да?

[Rinya]

5 минут назад, Vintik сказал:

А так как вариант я думал обновляется только интерпритатор, т.е. подкинуть обратно LZH с того же диску (ну будет там на 1330 а 1328, ну что уж теперь) или обновления обратно не пойдут - вот вы про что наверно предупреждаете да?

Обратно подсунуть ЛЗХ, если честно не пробовали. У нас просто были железки в кластере в добавок ко всему, а в кластере желательно чтобы версии были одинаковые.

[Vintik]

Понятно, если так то да. Жалко что т.п. вам отправляла обновление и "тихо" надеялась на чудо или как объяснить, что только после того как у вас не получилось, они поняли ошибку. Пока у вас есть т.п. вы запросили обновление? Думаю то что вы нашли другое решение это хорошо, но то что заявляется в листе сравнения с там же Континентом и должно работать - это желательно реализовывать, а то вот так не красиво получается.

Будем надеяться.