Трассировка через координаторы

[diis]

Добрый день!
Не появилась ли в 4 версии ViPNet трассировка маршрутов через координаторы с отображением IP-адресов? Пытаюсь распутать сложную ситуацию, без трассы непонятно как справляться.

[azz]

А журнал ip пакетов вам не помогает?

[zero]

  16.10.2018 в 09:07, diis сказал:

Не появилась ли в 4 версии ViPNet трассировка маршрутов через координаторы с отображением IP-адресов?

Расширить  

И не появится. Журнал пакетов и конфигурации iplir с узлов обычно бывает достаточно.

[diis]

Ну да... Можно и воду дуршлагом черпать... В ситуации, когда трафик улетает неведомо куда, бродить по координаторам и искать пакеты в журналах вместо одной команды  trace - это хорошо и правильно, конечно.

[volosnikov]

Какие-то видимо трудности в поддержке TTL в данном случае у разработчиков...
Можно разрешить пинг координатора из незащищенной сети (да и не только пинг), а вот виндовый трейс через icmp - не прожевывается увы.

И это действительно утомляет иногда.

[zero]

 Ну допустим штатный tracert бы работал. Что-бы он показывал? Виртуальные адреса хопов, через которые проходил трафик. Причем эти адреса сильно зависели бы от того, как видят друг друга узлы, через которые он прошел. 192.168.1.1 - 11.0.1.251 - 11.0.1.10 - 10.0.1.2  и т.д.

 Чтобы понять что это за узлы придется на каждый промежуточный все равно заходить и смотреть в конфиге. Слабое утешение.

Так Вам сразу проще так сделать, посмотрите конфиги, журналы, может и сразу поймете куда трафик "улетает".

 Идея сделать все просто и красиво понятна, если бы её было также просто реализовать, то это было бы давно сделано.

[R.Sheyn]

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

Допустим при полном туннеле трафик шифруется и инкапсулируется, обратный же процесс происходит только на конечном координаторе, который выплевывает трафик в свой туннель. Как вы себе представляете ответы промежуточных устройств? Ведь к ним приходит зашифрованный udp пакет. То что внутри него, какой-то продовый трафик, icmp или еще что-то им неведомо. Очевидно, что тут нужно городить целую новую систему, какие то флаги в заголовок добавлять итд итп.

[diis]

Спасибо за разъяснения,  коллеги, я действительно упускаю сложности. Моя проблема мне стала понятна: в пути между координаторами есть роутер, который пытается раскидывать трафик в разные стороны, а зашифрованные пакеты он не понимает куда отправлять и конечно отправляет не туда. Будем думать с админом роутера

[volosnikov]

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

[zero]

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

Как уже было написано стандартными утилитами проблему трассировки в защищённой сети решить невозможно. Нужна своя отдельная экосистема, затрагивающая всю линейку продуктов. Это глубокие доработки с совсем неявным эффектом.

 В большинстве случаев уже имеющиеся средства позволяют быстро и эффективно  находить проблемы, что кстати подтверждает и текущая ветка форума:

  16.10.2018 в 13:17, diis сказал:

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

Расширить  

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

[cypma4]

Вот официальный ответ от поддержки,

> по требованию регулирующих органов ПО HW не поддерживает работу утилиты tracert.

> В текущих версиях программного обеспечения такая возможность не заложена.

[volosnikov]

  29.10.2018 в 09:40, cypma4 сказал:

по требованию регулирующих органов ПО HW не поддерживает работу утилиты tracert.

Расширить  

Улыбнуло, спасибо!

А traceroute? tracepath? )))

[cypma4]

  29.10.2018 в 09:45, volosnikov сказал:

Улыбнуло, спасибо!

А traceroute? tracepath? )))

Расширить  

я думаю аналогично

[zero]

  29.10.2018 в 09:40, cypma4 сказал:

по требованию регулирующих органов

Расширить  

Имеется виду, что любая штатная утилита из состава ОС будет передавать данные в открытой части ip-пакета, т.е. информация о трассировке (топологии) защищённой сети может быть доступна злоумышленнику.

[KIV]

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

[R.Sheyn]

  31.10.2018 в 05:08, KIV сказал:

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

Расширить  

Вы из любого випнет клиента в режиме администратора можете посмотреть журнал пакетов любого связанного узла. Чем не централизация?

[zero]

  31.10.2018 в 05:08, KIV сказал:

централизованное хранение журналов пакетов с нескольких координаторов помогло бы избавиться

Расширить  

Механизм передачи журнала пакетов на удаленный узел по протоколу CEF будет реализован в следующих версиях HW. Сейчас он уже реализован в xFirewall.

[KIV]

  31.10.2018 в 07:12, zero сказал:

Механизм передачи журнала пакетов на удаленный узел по протоколу CEF будет реализован в следующих версиях HW. Сейчас он уже реализован в xFirewall.

Расширить  

Вот это круто.

  31.10.2018 в 06:40, R.Sheyn сказал:

Вы из любого випнет клиента в режиме администратора можете посмотреть журнал пакетов любого связанного узла. Чем не централизация?

Расширить  

Да неудобно это. Сначала к одному подключится посмотреть, потом к другому. 

[R.Sheyn]

  31.10.2018 в 17:03, KIV сказал:

Да неудобно это. Сначала к одному подключится посмотреть, потом к другому. 

Расширить  

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

[KIV]

  01.11.2018 в 04:01, R.Sheyn сказал:

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

Расширить  

Ну как минимум хочу чтобы была возможность делать поиск со след критериями: адрес источника, адрес назначения, диапазон времени и координаторы в журналах которых мы ищем проходящий пакет. А вы видите это как журналов пакетов и дальше как хотите так и ищите?

[R.Sheyn]

Ну я так и понял, вы хотите, чтобы еще и аналитику за вас проводил. Много хотите)

[KIV]

21 век - имею право. 

[R.Sheyn]

  02.11.2018 в 16:49, KIV сказал:

21 век - имею право. 

Расширить  

Думаю максимум, что инфотекс сделает, это как уже писали выгрузку. А вот аналитику придется все-таки проводить сторонними средствами. Очевидно, что затрат человекочасов эта сомнительная перспектива не окупит. Да оно и не нужно. Удобно? Да. Жизненно необходимо? Нет.

[zero]

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

[KIV]

Коллеги, надеюсь вы видели такие продукты как SmartLog от CheckPoint, или Pamorama от PaloAlto. Ну ведь очень удобная штука. Последняя продается за отдельные деньги, у ЧП другая концепция, но тоже монетизированная. Я глубоко убежден, что сети в которых используется несколько 10ов координаторов смогут позволить себе платный, вендорский софт для хранения и обработки журналов.