L2TP изначально предполагает клиент-серверную топологию сети, то есть где есть одна центральная точка, к которой подключаются остальные. у такого подхода есть большой минус, о котором я рассказал в ролике. у GRE перед IPIP есть как плюс, так и минус. плюс в том, что GRE поддерживает передачу multicast трафика. к примеру, мы можем настроить OSPF (динамическая маршрутизация), который работает по multicast. но в нашем случае в этом не было надобности, так как маршруты прописывались вручную. минус GRE в том, что у него оверхед 24 байта, а у IPIP 20 байтов. это означает, что IPIP немного менее прожорлив к трафику, чем GRE. следовательно, больше трафика пройдет через IPIP, чем через GRE. но опять же, это несущественно.
Очень интересно было бы увидеть резервирование VPN , то есть, возьмем пример: Есть объект/ы (магазин/ы) и когда у клиента один ISP1 оператор связи, а на базе (центральный узел) их два ISP1 / ISP2 операторов связи. В случае, если на базе падает один ISP1, то клиент, смог бы подключиться ко второму ISP2 оператору связи на базе. В основном по такой схеме работают магазины. Можете подсказать или показать, как правильно можно реализовать задачу. Спасибо!!
к сожалению, протоколы динамической маршрутизации в 7-й версии излишне усложнили, добавив необходимость анонсирования префиксов через написание фильтров с помощью скриптового языка. думаю, начинающим или даже средним пользователям это будет настроить куда сложнее, чем ручные маршруты. но да, в планах есть такой ролик тоже. спасибо!
Спасибо, видео пока закинул в закладки. И вопрос: про WireGuard можете записать ролик, может быть немного расскажете в чем отличия, преимущества/недостатки от IPsec.
@@loskiq По возможности - сделайте часть видео для подключения (винда-микрот), а не только (микрот-микрот). Чтобы извне можно было подключаться к главной сети
Автору спасибо хоть за то, что показал, как это можно реализовать средствами mikrotik-a, как рабочий процесс. Конечно, автор не упомянул о сервисах офисных, но это не в этом суть. Все мы, знаем или предполагаем, что все сервисы, в основном находятся в облаке. В основном, это программисты так работают в арендованном офисе, и когда им нужно обменяться данными "как по обычной открой папке в локальной сети" не используя ftp, но находящиеся в разных регионах. Схема автора, самая то. А вот по поводу сервисов, даже эта схема подходит, как одно из этапов следующего планирования, с отказоустойчивой кластеризацией серверов и резервирование VPN как клиент --->> сервер. Агрегация каналов не каждый сможет, и не везде надо и то, это только в крупных компаниях, где агрегация схемы необходима.
Респект-тебе ,что поделился своими знаниями , сейчас к сожалению мало молодежи владеющей техническими знаниями
Самые лучшие видео по микротикам. Было бы замечательно если бы сделали видео по маршрутизации между Vlan на микротиках.
Да, тема vlan'ов еще не раскрыта конечно, про них бы послушать
есть документация, там все есть
Класс !!! А можете пожалуйста как нибудь, сделать видео по отказаустойчивости WAN, то есть задействовать два провайдера.
да, уже есть в планах!
Интересный формат подачи видео, очень приятно слушать вас. Есть вопрос кстати, почему выбрали IPIP вместо GRE или L2TP?
L2TP изначально предполагает клиент-серверную топологию сети, то есть где есть одна центральная точка, к которой подключаются остальные. у такого подхода есть большой минус, о котором я рассказал в ролике.
у GRE перед IPIP есть как плюс, так и минус.
плюс в том, что GRE поддерживает передачу multicast трафика. к примеру, мы можем настроить OSPF (динамическая маршрутизация), который работает по multicast. но в нашем случае в этом не было надобности, так как маршруты прописывались вручную.
минус GRE в том, что у него оверхед 24 байта, а у IPIP 20 байтов. это означает, что IPIP немного менее прожорлив к трафику, чем GRE. следовательно, больше трафика пройдет через IPIP, чем через GRE. но опять же, это несущественно.
@@loskiq Благодарю за пояснение
GRE туннели не сразу понимают, если инет пропал и долго возвращаются к жизни. IPIP этого лишен?
Очень интересно было бы увидеть резервирование VPN , то есть, возьмем пример: Есть объект/ы (магазин/ы) и когда у клиента один ISP1 оператор связи, а на базе (центральный узел) их два ISP1 / ISP2 операторов связи. В случае, если на базе падает один ISP1, то клиент, смог бы подключиться ко второму ISP2 оператору связи на базе. В основном по такой схеме работают магазины. Можете подсказать или показать, как правильно можно реализовать задачу. Спасибо!!
Никто default не трогает. при очередном обновлении он может быть "исправлен" mikrotik и у тебя ляжет сеть :(
Спасибо! Есть ли возможность внешнему пользователю, допустим из дома подключиться к офису не имея mikrotik, при этом пробросить свою локальную сеть?
Молодец, теперь молодым покажи как будет работать OSPF.
к сожалению, протоколы динамической маршрутизации в 7-й версии излишне усложнили, добавив необходимость анонсирования префиксов через написание фильтров с помощью скриптового языка. думаю, начинающим или даже средним пользователям это будет настроить куда сложнее, чем ручные маршруты. но да, в планах есть такой ролик тоже. спасибо!
Спасибо, видео пока закинул в закладки. И вопрос: про WireGuard можете записать ролик, может быть немного расскажете в чем отличия, преимущества/недостатки от IPsec.
такое видео уже готовится. будем также объединять локальные сети, но уже с помощью WireGuard
3 года на WireGuard + OSPF полёт нормальный)
@@loskiq По возможности - сделайте часть видео для подключения (винда-микрот), а не только (микрот-микрот). Чтобы извне можно было подключаться к главной сети
Ну, не совсем ясно, а если офис 1 отрубился и все сервисы, почта, ERP, базы каки нить, отвалились, смысл двум офисам друг друга видеть?
А если не отвалился? То работает телефония, фтп, принтеры под контролем на той стороне и т.п.
@@ProficusLets А я про что? Если все сервисы централизованы, то беда у всех, а если распределены, есть некоторый геморрой.
Автору спасибо хоть за то, что показал, как это можно реализовать средствами mikrotik-a, как рабочий процесс. Конечно, автор не упомянул о сервисах офисных, но это не в этом суть. Все мы, знаем или предполагаем, что все сервисы, в основном находятся в облаке. В основном, это программисты так работают в арендованном офисе, и когда им нужно обменяться данными "как по обычной открой папке в локальной сети" не используя ftp, но находящиеся в разных регионах. Схема автора, самая то. А вот по поводу сервисов, даже эта схема подходит, как одно из этапов следующего планирования, с отказоустойчивой кластеризацией серверов и резервирование VPN как клиент --->> сервер. Агрегация каналов не каждый сможет, и не везде надо и то, это только в крупных компаниях, где агрегация схемы необходима.
Микрота)