Ну как бы об этом и речь. Это как бы транспортный режим

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

Тем более между двумя микротами

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

Нат + дин айпи на 3g модеме, где провайдер режет gre

ovpn либо l2tp/ipsec

либо просто l2tp, если шифрование не принципиально

Ну как бы да, но и sstp тоже можно)

не, можно конечно. но в мне в sstp не нравится привязка к сертам (как и в ovpn, но там сервер можно от сертов отучить)

не, можно конечно. но в мне в sstp не нравится привязка к сертам (как и в ovpn, но там сервер можно от сертов отучить)

Выпустил один раз голове серт и работаешь. Что не так?

а клиентам?

Логин и пароль

А микроте уже научился sstp без сертов на клиентской стороне? не знал, простите

А микроте уже научился sstp без сертов на клиентской стороне? не знал, простите

Дак вроде с первых релизов.

Это же классика клиент-сервера

У меня в свое время он не завёлся без сертов. Оно тогда как раз только-только появилось, я посмотрел, покрутил и забил. Вернулся на l2tp) Ну или ovpn

У меня в свое время он не завёлся без сертов. Оно тогда как раз только-только появилось, я посмотрел, покрутил и забил. Вернулся на l2tp) Ну или ovpn

Все бывает. Sstp же долго без нормальных спек жил. Это ж майкрософт

угу

А так он более чем годный так как его dpi системы не "видят"

Просто я обычно строю vpn с возможностью быстро смигрировать клиента или сервер с микрота на что-нибудь ещё

Максимально прозрачно

Поэтому обычно либо ovpn либо l2tp/ipsec

А так он более чем годный так как его dpi системы не "видят"

ну ovpn на 443 порту тоже может https притворяться ;)

ну ovpn на 443 порту тоже может https притворяться ;)

И да и нет. Sstp по заголовкам очень на https похож. Его в трафике сложнее опознать

Но это все полемика

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

какая максимальная мощность на hap ac lite? в capsman забить чуть ослабленно, пересекаются 2 точки, разведенные по разным каналам

6.38.3 ставить можно? щас везде 6.38.1 (посоветуйте что по централизации обновлений и бекапов почитать)

6.38.3 ставить можно? щас везде 6.38.1 (посоветуйте что по централизации обновлений и бекапов почитать)

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

Бэкапы я забираю экспортом через ssh и в гит.

Текстовые удобно и хорошо

Бинарные для восстановления юзеров/паролей/сертов

да свежа еще история с 37 веткой, всё протестил, всё ок, а потом глюки через несколько дней начались

Ну я на ответственных железках раньше недели не накатываю

После начала тестирования на малой группе

Ребята два вопроса . 1) кто настраивал Микротик на amazon aws 2) mikrotik и lacp

Ребята два вопроса . 1) кто настраивал Микротик на amazon aws 2) mikrotik и lacp

2) в чём вопрос?

2) в чём вопрос?

Какие параметры на микротике выставлял, в винде lacp настроен

Какие параметры на микротике выставлял, в винде lacp настроен

покажи как в винде настроил и я скажу как настроить в МК =)

покажи как в винде настроил и я скажу как настроить в МК =)

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

Айписек в туннельном режиме нужно уничтожить

не, спасибо

не, спасибо

не понятна реплика. Активно юзаете?

Да.

ну как бы ваше право. Кто-то кактусы ест и не жалуется

Ну а вы предлагаете это право забрать =)

Ну а вы предлагаете это право забрать =)

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

А что в нём не так с точки зрения архитектуры? Вы имеете в виду, что он работает как вторая "теневая" таблица маршрутов?

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

Да собственно даже туннельный ipsec вполне применим. Просто микротик не научился в route based ipsec =) Из этого и проблемы. Но если не надо заморачиваться с балансировкой или failover - имеет право на жизнь

А что в нём не так с точки зрения архитектуры? Вы имеете в виду, что он работает как вторая "теневая" таблица маршрутов?

и в этом и в механике определения "мёртвых пиров" и к готовности работать с динамическими или серыми IP адресами и в механике взаимного создания правил

Да собственно даже туннельный ipsec вполне применим. Просто микротик не научился в route based ipsec =) Из этого и проблемы. Но если не надо заморачиваться с балансировкой или failover - имеет право на жизнь

а кто научился?

Да собственно даже туннельный ipsec вполне применим. Просто микротик не научился в route based ipsec =) Из этого и проблемы. Но если не надо заморачиваться с балансировкой или failover - имеет право на жизнь

> Но если не надо заморачиваться с балансировкой или failover - имеет право на жизнь Об этом и говорю.

Да собственно даже туннельный ipsec вполне применим. Просто микротик не научился в route based ipsec =) Из этого и проблемы. Но если не надо заморачиваться с балансировкой или failover - имеет право на жизнь

и что значит не заморачиваться? В каких инстанциях использвание IPSec в туннельном оправдано и в сравнении с чем? Например с тем же l2tp+ipsec?

и в этом и в механике определения "мёртвых пиров" и к готовности работать с динамическими или серыми IP адресами и в механике взаимного создания правил

Во всём том, что вы перечислили, как помогает конкретно транспортный режим?

и что значит не заморачиваться? В каких инстанциях использвание IPSec в туннельном оправдано и в сравнении с чем? Например с тем же l2tp+ipsec?

Ну, в сравнении с L2TP — например, меньше оверхед, и не всегда VPN нужно запихивать в тот же широковещательный домен.

Во всём том, что вы перечислили, как помогает конкретно транспортный режим?

в пирах тебе не нужно их детектить, так как смерть пира не влияет на транспорт, просто начинает работать соседний туннель, динамические IP будут работать по той же причине, просто рядом поднимется другой туннель с другими параметрами и не займёт таблицу серой маршрутизации готовыми (временно живыми) правилами и тд

Ну, в сравнении с L2TP — например, меньше оверхед, и не всегда VPN нужно запихивать в тот же широковещательный домен.

в смысле а туннельный IPSec каким образом с широковещательным доменом то поможет? ОО

в смысле а туннельный IPSec каким образом с широковещательным доменом то поможет? ОО

Никак, я об этом и говорю. Это не везде нужно, а оверхед на L2 есть.

Никак, я об этом и говорю. Это не везде нужно, а оверхед на L2 есть.

тогда щас не понял кто заставил тебя использовать l2 именно как l2 туннель? поднимаешь l3 и делаешь нормальную прозрачную для понимания маршрутизацию

в пирах тебе не нужно их детектить, так как смерть пира не влияет на транспорт, просто начинает работать соседний туннель, динамические IP будут работать по той же причине, просто рядом поднимется другой туннель с другими параметрами и не займёт таблицу серой маршрутизации готовыми (временно живыми) правилами и тд

А, т. е. вы сравниваете туннельный IPsec с транспортным, поверх которого пущен ещё какой-то протокол динамической маршрутизации?

тогда щас не понял кто заставил тебя использовать l2 именно как l2 туннель? поднимаешь l3 и делаешь нормальную прозрачную для понимания маршрутизацию

Тогда это просто оверхедно.

А, т. е. вы сравниваете туннельный IPsec с транспортным, поверх которого пущен ещё какой-то протокол динамической маршрутизации?

эээмм а каким образом транспортный IPSec можно использовать без туннеля?

Тогда это просто оверхедно.

всмысле чем? тем что нужно ложить пакет в пакет? Дак вы в ipsec тоже самое делаете.

эээмм а каким образом транспортный IPSec можно использовать без туннеля?

Туннель != туннель и динамическая маршрутизация поверх него.

всмысле чем? тем что нужно ложить пакет в пакет? Дак вы в ipsec тоже самое делаете.

Я про то, что в L2TP больше информации лишней в пакете оказывается.

Туннель != туннель и динамическая маршрутизация поверх него.

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

Я про то, что в L2TP больше информации лишней в пакете оказывается.

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

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

Например, как?

ERROR: S client not available

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

В самом простейшем. Топология "звезда", пять роутеров.

Например, как?

два канала, два статических маршрута с двумя шлюзами. Как бы всё.

В самом простейшем. Топология "звезда", пять роутеров.

один канал в центре?

два канала, два статических маршрута с двумя шлюзами. Как бы всё.

Ну и данные пойдут по тому, где метрика меньше. А когда он упадёт, что будет?

один канал в центре?

В смысле?

Ну и данные пойдут по тому, где метрика меньше. А когда он упадёт, что будет?

если метрика одинаковая данные будут разбалансированны 50 на 50. Прочтите матчасть

В смысле?

резервирование внешнего канала для центра звезды не практикуете? Двойная звезда или типо того? м?

Ну и данные пойдут по тому, где метрика меньше. А когда он упадёт, что будет?

когда один канал упадёт, детектинг мёртвого роута выключает его и данные спокойно идут по оставшемуся маршруту. искать по слову ECMP - Equal Cost Multi-Path

Ну и данные пойдут по тому, где метрика меньше. А когда он упадёт, что будет?

и работает это не по таймаутам 120 секунд, а мгновенно, вплодь до нескольких милисекунд.

если метрика одинаковая данные будут разбалансированны 50 на 50. Прочтите матчасть

А, вот как. Возможно, вы меня не так поняли — я не пытаюсь спорить. Напротив, я пытаюсь понять, где конкретно я не знаю каких-то преимуществ одного над другим.

резервирование внешнего канала для центра звезды не практикуете? Двойная звезда или типо того? м?

Нет. Говорю же, случай простейший. Никакого резервирования нет, это песочница из домашних сетей.

А, вот как. Возможно, вы меня не так поняли — я не пытаюсь спорить. Напротив, я пытаюсь понять, где конкретно я не знаю каких-то преимуществ одного над другим.

ну как бы я и показываю ущербность использования туннельного IPSec в сравнени с связкой транспорта с любым туннелем.

и что значит не заморачиваться? В каких инстанциях использвание IPSec в туннельном оправдано и в сравнении с чем? Например с тем же l2tp+ipsec?

Ну вот у меня например ipsec на джунипере в туннельном режиме прекрасно бегал к заказчикам. И мёртвые пиры опознавались (dead-peer-detection же?), и ospf ловил состояния интерфейсов и перестраивал маршруты нужным образом с основного туннеля на резервный. И всё это поверх голого интернета, никаких gre, l2tp/ipsec и т.д.

Нет. Говорю же, случай простейший. Никакого резервирования нет, это песочница из домашних сетей.

ну как бы песочницы они у каждого свои =) проводить паралели с боевыми системами, даже с простыми, странно

Ну вот у меня например ipsec на джунипере в туннельном режиме прекрасно бегал к заказчикам. И мёртвые пиры опознавались (dead-peer-detection же?), и ospf ловил состояния интерфейсов и перестраивал маршруты нужным образом с основного туннеля на резервный. И всё это поверх голого интернета, никаких gre, l2tp/ipsec и т.д.

напомните стоимость этой железки, чёт запамятовал

Так мы обсуждаем туннельный ipsec, или его ущербность в микроте?

А так SRX100H2 стоит меньше 500 баксов, емнип

На авито ещё дешевле найти можно

Так мы обсуждаем туннельный ipsec, или его ущербность в микроте?

он ущербен не только на микротике =)

Причём всё, что я выше описал, он умеет

Причём всё, что я выше описал, он умеет

отлично же =) скорость перестроения в DPD у него какая была, очень интересно =)

он ущербен не только на микротике =)

Ну нормальные вендоры умеют в route based ipsec, тем самым нивелируя проблемы с маршрутизацией

или вы не проверяли и оно падало и потом кто-то руками поднимал?

отлично же =) скорость перестроения в DPD у него какая была, очень интересно =)

DPD потому что пир с той стороны не мой.

DPD потому что пир с той стороны не мой.

и как по скорости реакции на аварию было?

Не замерял

секунд на 15-20 ложилась связь, не меньше же?

Если с обеих стороны ваши железки, никто не мешает между ними поднять ospf с bfd, и будет переключаться моментом

Если с обеих стороны ваши железки, никто не мешает между ними поднять ospf с bfd, и будет переключаться моментом

ну как бы мешает время жизни IPSec cессии

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

и на время таймаута невозможно рядом поднять другой туннель не грохнув их

ну как бы мешает время жизни IPSec cессии

Вы смысл route based ipsec вообще понимаете?