Комментарии 29
ЯННП. На стороне Джуна у вас «белый» адрес 1.1.1.1, но при этом сорс и дестинейшен туннеля в 172.16.0.0/12… А на стороне микротика вообще белого адреса нет :\
Вы пропустили часть, в которой был поднят IPsec, внутри которого уже бегает gre. Тому вполне хватает одного белого адреса.
Зачем тогда GRE? Если IPSEC в туннельном режиме уже есть и делает практически то же самое.
Чтобы преподнести поддержку GRE как нечто крайне крутое и недостающее всем пользователям в мире наверное.
IPsec на стороне Микротика шифрует весь трафик, соответственно либо надо сеть бить 192.168.0.0/17, либо если нужна вся доступная сеть 192.168.0.0/16, то Микротик будет не доступен из локальной сети, по этому шифруем трафик 172.31.xxx.xxx
Вроде не пропустил, он есть.
Белого адреса нет, через Cloud Микротика не работает. Поэтому только через серый.
Keenetic 4G дешевле в два раза, умеет все то же самое, при этом еще и IKEv2 работает стабильно.
НЛО прилетело и опубликовало эту надпись здесь
Много провайдеров — конечно. Скрипты — да. Несколько подсетей — пожалуйста.
НЛО прилетело и опубликовало эту надпись здесь
Сначала определитесь с определением термина «балансировка», потом уже «вступайте в бой».
Выпускать конкретного клиента через конкретный WAN (любой) — это пара кликов в Web-интерфейсе. Есть экспериментальная опция для качающих торренты, которая включает ECMP-роутинг и позволяет грузить все каналы на полную, но она ломает работу с некоторыми ресурсами и не рекомендуется для обычных пользователей.
Ну и документация могла немного устареть.
Выпускать конкретного клиента через конкретный WAN (любой) — это пара кликов в Web-интерфейсе. Есть экспериментальная опция для качающих торренты, которая включает ECMP-роутинг и позволяет грузить все каналы на полную, но она ломает работу с некоторыми ресурсами и не рекомендуется для обычных пользователей.
Ну и документация могла немного устареть.
Это устройства разных классов, сравнивать их бессмысленно.
Да, разных, никто не спорит. Но все, что сделал автор (тут вроде обсуждение статьи идет, а не потенциальных ТТХ), можно было сделать на устройстве в 2 раза дешевле и с большим выхлопом.
По моему опыту Keenetic через несколько лет использования начинает глючить все сильнее… С микротиком такого не наблюдал.
Да, кинетик последнее время стал уметь многое, что раньше мог только Микротик/ZyWall/DFL, т.е. устройства, изначально заточенные не под SOHO, а под вполне себе средний бизнес с филиальной сетью и т.д. А ешё на него можно поставить какой-нибудь *WRT и получить ещё больше возможностей (включая установку доп. пакетов).
Но при этом по функциональности микротик до сих пор сильно его опережает. Плюсом к этому, какой-нибудь hAP mini умеет ровно столько же (по функциям), сколько самый мощный CCR. И конфиг переносится элементарно, т.е. проблем с апгрейдом железки не возникает.
При всём уважении к кинетику, как говорится.
Но при этом по функциональности микротик до сих пор сильно его опережает. Плюсом к этому, какой-нибудь hAP mini умеет ровно столько же (по функциям), сколько самый мощный CCR. И конфиг переносится элементарно, т.е. проблем с апгрейдом железки не возникает.
При всём уважении к кинетику, как говорится.
Конкретно этот Микротик имеет аппаратную поддержку IPSec, соответсвенно не нагружается cpu
Usb модемы имели свойство глючить через 1-2 дня работы. И пока руками не ребутнешь — не заработает интернет. Причем обычная перезагрузка роутера не помогает, нужно обязательно обесточить модем.
Сам недавно занимался подобной настройкой: Juniper с NetGate-ом подружил по IP-sec. Была в наличии сетка из Juniper-ов с VPN-ками дефлотно настроенными, и в неё добавили еще одну удаленную точку с NetGate в качестве шлюза. Я не сетевик ни разу, обычный админ самоучка. И для меня было малость трудновато перейти от стандартного Juniper-овского подхода по созданию VPN к общему с указанием ключей, приветствий, шифрований 1 и 2 фазы, количеством байт проверки и т.д… Кхм, я даже подумывал статью запилить на эту тему, но выглядеть она будет как у автора этой статьи, то есть очень коротко, но может быть полезной как справочный материал.
Навскидку, у меня несколько вопросов:
1. зачем использовать aggressive вместо main?
2. df-bit copy — не самая удачная идея на туннельных интерфейсах. Во избежание дропов я бы всё-таки скидывал бит dont-fragment
3. Я так и не понял смысла натягивать gre поверх ipsec. Даже если принять во внимание, что микротик не умеет полноценный route-based ipsec, ваше объяснение выглядит немного непонятно.
Если за Juniper сидит вся оставшаяся /16, и трафик к ней нужно добавить в ipsec policy — то на микротике это довольно легко обходится грамотным составлением policy и роутингом (т.е. у вас ipsec encapsulation просто не возникнет: wiki.mikrotik.com/wiki/Manual:Packet_Flow)
4. Ещё есть вопросы, зачем использовать vlan.0 вместо routed-портов, зачем вы разрешаете ospf, если его не используете (или используете?) и почему у вас в конфиге Juniper режим v2-only, если IKEv2 вы использовать не рекомендуете. Но это уже придирки. Наверное :)
1. зачем использовать aggressive вместо main?
2. df-bit copy — не самая удачная идея на туннельных интерфейсах. Во избежание дропов я бы всё-таки скидывал бит dont-fragment
3. Я так и не понял смысла натягивать gre поверх ipsec. Даже если принять во внимание, что микротик не умеет полноценный route-based ipsec, ваше объяснение выглядит немного непонятно.
Если за Juniper сидит вся оставшаяся /16, и трафик к ней нужно добавить в ipsec policy — то на микротике это довольно легко обходится грамотным составлением policy и роутингом (т.е. у вас ipsec encapsulation просто не возникнет: wiki.mikrotik.com/wiki/Manual:Packet_Flow)
4. Ещё есть вопросы, зачем использовать vlan.0 вместо routed-портов, зачем вы разрешаете ospf, если его не используете (или используете?) и почему у вас в конфиге Juniper режим v2-only, если IKEv2 вы использовать не рекомендуете. Но это уже придирки. Наверное :)
1. При aggressive режиме, тунель поднимается более активнее.
2. df-bit copy, если не включать, то на удаленных точках периодически перестают сервисы такие как SMB и SIP, перестает пускать на сетевые «шары», происходит это достаточно рандомно, поэтому ставим этот параметр по умолчанию чтобы избежать проблем.
3. Натягивать GRE по верх IPSec, мы не хотели, проблема в следующем, когда создаете IPSec Policies, вы шифрует указанные сети. При указании вашей сети в параметре Src. Address 192.168.152.0/24 а Dst. Address указать 192.168.0.0/16 то вы не сможете получить доступ к микротику по адресу 192.168.152.1. Поэтому попробовали через GRE с использованием подсети которая находится за пределами этого диапазона, а с помощью маршрутизации заворачиваете необходимый трафик с GRE.
4. OSPF у нас используешься между Juniper и Juniper. Vlan.0 так повелось что это была изначально деволтовая конфигурация и в принципе не видим пока смысла отказываться от неё.
IKE2 пробовали но когда приохотит разрыв туннеля, то он почему то подниматься.
2. df-bit copy, если не включать, то на удаленных точках периодически перестают сервисы такие как SMB и SIP, перестает пускать на сетевые «шары», происходит это достаточно рандомно, поэтому ставим этот параметр по умолчанию чтобы избежать проблем.
3. Натягивать GRE по верх IPSec, мы не хотели, проблема в следующем, когда создаете IPSec Policies, вы шифрует указанные сети. При указании вашей сети в параметре Src. Address 192.168.152.0/24 а Dst. Address указать 192.168.0.0/16 то вы не сможете получить доступ к микротику по адресу 192.168.152.1. Поэтому попробовали через GRE с использованием подсети которая находится за пределами этого диапазона, а с помощью маршрутизации заворачиваете необходимый трафик с GRE.
4. OSPF у нас используешься между Juniper и Juniper. Vlan.0 так повелось что это была изначально деволтовая конфигурация и в принципе не видим пока смысла отказываться от неё.
IKE2 пробовали но когда приохотит разрыв туннеля, то он почему то подниматься.
2. Это решается корректным выставлением tcp-mss и mtu на обеих сторонах.
3. А зачем вам 152.1? Если для управления, то можно поднять lo-интерфейс с любым адресом и настроить роутинг, GRE ради этого городить не обязательно. Опять же, я бы разобрался с ipsec policy и тем, почему недоступен этот адрес.
4. Просто если у вас в конфиге есть ospf, то надо, наверное, описывать его на схеме, ну или удалять из примеров, чтобы не путать :)
Я понял, почему вы отказались от ikev2, но почему в конфиге указано ike v2-only?
3. А зачем вам 152.1? Если для управления, то можно поднять lo-интерфейс с любым адресом и настроить роутинг, GRE ради этого городить не обязательно. Опять же, я бы разобрался с ipsec policy и тем, почему недоступен этот адрес.
4. Просто если у вас в конфиге есть ospf, то надо, наверное, описывать его на схеме, ну или удалять из примеров, чтобы не путать :)
Я понял, почему вы отказались от ikev2, но почему в конфиге указано ike v2-only?
2. да, эти параметры выставлены, когда создается туннель между Junuper SRX и Juniper SRX, не знаю с чем связанно, но без df-bit copy, туннель но сетевые «шары» периодический отваливаются, туннель между Juniper SSG, NS и Juniper SRX, таких проблем нет. Хотя и в первойм и втором случае параметры выставлены ха обои концах.
3. С IPSec полиси достаточно хорошо разобрались, 152.1 это адрес самого Mikrotik а, и он нужен нам как администраторам, в целом вы правы он не нужен простым обывателям, без него прекрасно все работает.
4. Это мое допущение, прошу прощения. Я достаточно моложавый для таких статей.
V2-Only, у нас работало в это режиме, на стороне Mikrotik, мы изменили параметр а на стороне Juniper забыли.
3. С IPSec полиси достаточно хорошо разобрались, 152.1 это адрес самого Mikrotik а, и он нужен нам как администраторам, в целом вы правы он не нужен простым обывателям, без него прекрасно все работает.
4. Это мое допущение, прошу прощения. Я достаточно моложавый для таких статей.
V2-Only, у нас работало в это режиме, на стороне Mikrotik, мы изменили параметр а на стороне Juniper забыли.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создание IPSec GRE туннеля между Mikrotik hEX S и Juniper SRX через USB Модем