EoIP на Mikrotik⁠⁠

Я не настоящий сетевик, пока только учусь, и вот в процессе учёбы узнал про фичу микрота, которая очень быстро умеет пакетики слать между двух сетей, не напрягая особо проц девайса. По разным мануалам собирал на коленке сетку из двух микротов для объединения сетей 192.168.10.0 и 192.168.15.0. На коленке в одной сетке работает ок. Пытался масштабировать на точки, соединенные по интернет и вот фиг. В мануалах обычно рассматриваются сети типа вот таких:

где чудесно все работает в сетях на последнем октете. А мне надо поженить *15.0 и *10.0 И вот они не хотят жениться. Канал устанавливается, пинги от микрота к микроту идут, а вот от, например 192.168.15.59 к 192.168.10.100 - нет. Или могут идти, но только в одну сторону, а ресурсы типа http- не работают. Может есть волшебная пилюля? Настраивал по мануалам отсюда https://настройка-микротик.укр/nastrojka-eoip-mikrotik-bystr... и отсюда https://vedernikoff.ru/mikrotik-ipsec-и-eoip-объединяем-офис...

UPD: между офисами канал 100, один провайдер.

Лига Сисадминов

1.6K поста17.7K подписчиков

Добавить пост

Правила сообщества

Мы здесь рады любым постам связанным с рабочими буднями специалистов нашей сферы деятельности.

Вы смотрите срез комментариев. Показать все

0x73

10 месяцев назад

eoip вам не нужен. На вкладке интерфейсов добавьте gre тоннель с ipsec с обеих сторон. Если конфиг дефолтный, добавьте gre интерфейсы в список LAN. На каждом микроте надо добавить маршрут на удалённую сеть через соответствующий gre интерфейс.

раскрыть ветку (25)

mal333

10 месяцев назад

ipsec сожрет полосу и загрузит проц. Правда, в сторону gre тоннеля я еще не смотрел. Конфиг уже не дефолтный, и поэтому, подозреваю, понадобится что-то менять в NAT, курить маны и все такое. EoIP был выбран,из описания, легкости настройки и работы win-сетей, а тут внезапно такое.

раскрыть ветку (24)

MikaelRain

10 месяцев назад

NAT используется для выхода во вне. Если у вас белые ip (а GRE только на них можно построить, вроде как), то никакой nat вам помехой не будет. Туннели идут в обход nat и строятся напрямую между белыми ip. А дальше трафик маршрутами заворачивается в туннель и всё

раскрыть ветку (2)

mal333

10 месяцев назад

Я так понимаю, чтобы обойти nat надо правило добавить. Но вот какое пока не знаю. Адреса бело-серые, но маршруты есть и так то пофиг, микроты поднимают туннель нормально.

раскрыть ветку (1)

MikaelRain

10 месяцев назад

У вас в nat указан dst интерфейс. Всё что идет не туда в нат не попадет.

0x73

10 месяцев назад

Кстати: https://wiki.mikrotik.com/wiki/Manual:Interface/EoIP

The EoIP protocol encapsulates Ethernet frames in GRE (IP protocol number 47) packets (just like PPTP) and sends them to the remote side of the EoIP tunnel.

Так что overhead с eoip будет еще больше..

GRE tunnel adds a 24 byte overhead (4-byte gre header + 20-byte IP header).

ipip - это просто +заголовок ip (20byte)

Ipsec к этому всему еще 20 с чем-то байт добавит.

Если у вас там не 100% загрузка 100мбит, то и не заметите особо.

раскрыть ветку (2)

mal333

10 месяцев назад

Где то на просторах чел тестил скорости на разных способах объединения, EoIP показал наивысшую. И да, мне надо быстро - толстый клиент 1с.

раскрыть ветку (1)

0x73

10 месяцев назад

Вопрос как тестил и что тестил. Если eoip это целый фрейм L2 упакованный в gre, то он не может быть быстрее чем gre :) - байтов-то больше стало. Если пакет мелкий, то он просто так и уйдет одним пакетом, а если исходный был 1500, то он уже не пролезет и будет разбит на два, а на той стороне собран обратно. И если у gre mtu стоит за минусом оверхеда, то у eoip по дефолту стоит 1500.

0x73

10 месяцев назад

Эээ. У вас там lite что ли? Все свежие микроты aes аппаратно умеют. Гонять нешифрованый трафик через инет - ну такое себе.

Eoip нужен если вы хотите объединить два ethernet сегмента в один. Именно на уровне L2. У вас же задача просто обеспечить маршрутизацию между двумя разными подсетями. Именно для этого gre и сделан - generic route encapsulation. Если конфиг уже сильно перепилили (именно - убрали дефолтные правила), то вам надо в forward разрешить трафик в gre туда и обратно, в NAT поставить accept (что бы не натил) и в маршрутах добавить 192.168.xx.0/24 через gre.

Хотя я не очень понимаю, зачем люди сносят дефолтный конфиг - он хорош из коробки. Есть лист WAN - там все вражеские интерфейсы. Есть лист LAN - там все дружественные. Для большинства - этого достаточно. Если надо какие-то особенные правила - добавляете к существующим. По сути - надо только добавлять в input или в nat (dst-nat для проброса внутрь).

ps: нагрузка на микрот при двух gre/ipsec с трафиком по 10Мбит каждый

раскрыть ветку (17)

xigny

10 месяцев назад

Здравствуйте. Прошу прощения за беспокойство. Не могли бы и мне подсказать? Три офиса связаны по ipsec с галкой тунель. Дополнительно подняты l2tp server для внешних сотрудников.
Проблема в том, что внешний сотрудник, подключившись через l2tp, видит только сеть того офиса, куда подключился. А хотелось бы видеть все сети офисов.
Правильно ли я понимаю, что в рамках ipsec задачу не решить и надо переделать тунели на gre или l2tp, например?

раскрыть ветку (10)

0x73

10 месяцев назад

Добрый. Надо бы посмотреть, что в policy ipsec указано, там пишется, какой трафик должен попадать в тоннель. Возможно адреса клиентов l2tp не попадают? Второй момент - какие сети используются? Если не 10/8, то винда добавляет маршрут только на ту сетку, из которой ей выдали адрес. Подключитесь, посмотрите route print.

Вообще, с gre/ipsec несколько проще, т.к. вы получаете полноценный интерфейс с адресом, через который можно строить обычные маршруты. С ipsec несколько сложнее, т.к. отдельного интерфейса по сути нет, есть только правило, по которому трафик шифруется или нет. Если у вас клиенты на вин10, посмотрите в сторону sstp - с ним значительно проще, чем с l2tp. Но с маршрутами все равно надо разобраться. Если можете - нарисуйте схему с внутренними адресам, что бы было понятно - так проще разобраться.

раскрыть ветку (8)

xigny

10 месяцев назад

Сети 172.16.0/24, 172.16.2.0/24, 172.16.101.0/24.
В полиси указаны эти сети.
Для клиентов l2tp выделен пул 10.10.3.10-10.10.3.50
На скрине там, где IP замазан, это внешний IP микрота, куда подключился.
Спасибо!!!

раскрыть ветку (7)

0x73

10 месяцев назад

Судя по второму маршруту 0.0.0.0 с метрикой 46 - стоит галка "весь трафик в vpn". Значит надо искать в микротах. Остальные роутеры про сеть 10.10.3.0/24 знают? У них есть маршрут на эту сеть через центральный микрот?

На центральном микроте смотрите forward, что бы из 10.10.13.0 было разрешено в 172.16.x.0, в nat этот трафик не должен попадать под masq - должно быть правило accept. То же самое и на остальных микротах.

Запускайте на клиенте ping -t на адрес микрота в другой сети и смотрите сниффером с фильтром icmp по всем интерфейсам - куда этот пакет уходит и где не проходит.

раскрыть ветку (6)

xigny

10 месяцев назад

А по добавлению маршрута мне не ясно что будет шлюзом. Внутренний IP микрота? Ipsec же не создаёт интерфейс.
Ipsec же сам делает маршруты к внутренним сетям.
Поэтому мне не ясно куда заворачивать обратный маршрут.

раскрыть ветку (3)

0x73

10 месяцев назад

Хм. С Ipsec чуть иначе. Я им не пользуюсь site2site, поэтому запамятовал. Там надо прописывать policy для сетей. Т.е. src=10.10.13.0/24 dst=172.16.2.0/24 action=encrypt.

Вот подробно описаны все действия:

https://mikrotik.wiki/wiki/VPN:IPsec_(аутентификация_с_помощью_пароля)

Если посмотреть на схему работы ipsec

то видно, что пакет сначала проходит этап маршрутизации, потом проверяется, попадает ли он под ipsec и если да - шифруется и повторно маршрутизируется. По идее, в данном случае достаточно любого маршрута, под который будет подпадать пакет, что бы он прошел первый этап и попал под ipsec policy. Скорее всего, дефолтного 0.0.0.0 будет достаточно. Потом пакет зашифруется, к нему добавится новый заголовок и он уже через роутинг уйдет на адрес удаленного роутера (внешний) в соответствии с sa адресами в policy.

Надо еще убедиться, что в forward разрешено прохождение пакетов src=10.10.13.0/24 dst=172.16.2.0/24 и обратно и по идее всё должно заработать.

раскрыть ветку (2)

xigny

10 месяцев назад

Фишка то как раз в том, что в полиси это и указано, а маршрут есть только дефолтовый нули в провайдера. И при этом маршрутизация между внутренними сетями есть.
Даже если на обоих концах добавляю обратные маршруты от vpn pool в хоть в бридж, хоть в провайдера, при этом файрволе разрешая сети ( в нат тоже) - увы...
Толи руки кривые, толи все-таки стоит переделать с ipsec на gre/l2tp, дабы было проще и были транзитные интерфейсы, в которые можно явно заворачивать трафик.
Спасибо Вам!!!

раскрыть ветку (1)

0x73

10 месяцев назад

Вообще должно работать и с ipsec. Policy для 10.10.13.0/24 с обоих сторон указаны? Не знаю, сложно так что-то понять, когда не видишь перед собой. А на микроте, куда подключаются vpn юзеры, из сети 10.10.13.0 (и интерфейсов) разрешен forward в другие сети? Может какое-то правило режет этот трафик?

Но как я говорил, с чистым ipsec имеется некоторая сложность. Поднимите один gre/ipsec тоннель и попробуйте пустить трафик - тогда будет понятно, дело в ipsec или где-то firewall режет.

xigny

10 месяцев назад

Верно, весь в vpn.
Про сети vpn другие не знают, маршрутов нет. Буду пробовать. Спасибо.
Меня просто смутило то, что ранее невозможно маршрутизировать, сказали, что надо переделывать из-за того, что ipsec с галкой тунель.
Спасибо!

раскрыть ветку (1)

0x73

10 месяцев назад

Про сети vpn другие не знают, маршрутов нет.

Это ключевой момент. Им приходит пакет от 10.10.3.x, а куда на него ответить - они не знают, поэтому ответ идет по дефолтному маршруту провайдеру, который его благополучно дропает.

Меня просто смутило то, что ранее невозможно маршрутизировать, сказали, что надо переделывать из-за того, что ipsec с галкой тунель.

Не очень понял, что имелось ввиду. Разница между transport/tunnel описана тут:

https://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Transport_mod...

Главное отличие - пустят ли промежуточные роутеры оригинальный ip заголовок? Т.е. с вашими локальными адресами. В 99% случаев - нет. Значит, если вы хотите шифровать не только трафик между двумя микротами (т.е. трафик, источником и получателем которого является сам микрот, а не кто-то другой), а еще и транзитный - то надо включить tunnel mode - тогда транзитный пакет целиком упаковывается в ipsec и так же вынимается на другой стороне. Не забывайте, если используете какие-то правила фильтрации, у таких пакетов интерфейс будет тот же, что и у публичного ip на который он пришел/ушел. Т.е. пакет с локальным адресом, но интерфейс - wan. В общем ipsec та еще трава :) Поэтому я рекомендую использовать gre/ipsec тоннель - так проще и понятней.

0x73

10 месяцев назад

Вспомнил, почему я перестал использовать l2tp:

At this point (when L2TP client is successfully connected) if you will try to ping any workstation from the laptop, ping will time out, because Laptop is unable to get ARPs from workstations. Solution is to set up proxy-arp on local interface

Когда на основном бридже включен proxy-arp, он начинает отвечать на все arp запросы несуществующих адресов. Жутко бесит :) И еще некоторые железки/софтины при назначении им адреса проверяют его занятость путем arp запроса - а тут наш микрот своим маком отвечает.

mal333

10 месяцев назад

аха, hAP lite.. но буду посмотреть как вертеться будет, уже завтра. Там не то, чтобы прям интернет, в пределах одного прова.

раскрыть ветку (5)

0x73

10 месяцев назад

Если lite, то печалька. Ему от ipsec поплохеет сильно. Даже 2011 не вытягивает. Так что или gre или ipip без шифрования. Не забудьте еще в mangle postrouting добавить правило (если нет) clamp tcp mss to pmtu.

А вообще поищите - полно гайдов mikrotik gre site to site типа такого: https://mikrotik.wiki/wiki/VPN:GRE_и_IPsec_(быстрая_настройка,_аутентификация_с_помощью_пароля)

Только ipsec не надо включать (хотя - проверьте, вдруг у вас там немного трафика и hap потянет).

Вообще, для таких вещей лучше купить rb4011 - оптимально по деньгам/скорости.

раскрыть ветку (4)

k1aus

10 месяцев назад

Для чего это правило нужно?

раскрыть ветку (2)

0x73

10 месяцев назад

Поскольку обычно на ether стоит mtu 1500, а в тоннеле меньше (в случае с gre - 1476) то это правило меняет MSS в проходящих tcp сессиях на значение pmtu (в нашем случае 1476) что бы не было фрагментации.

https://habr.com/ru/articles/702482/

https://notes.networklessons.com/mtu-adjusting-the-mss-for-t...

раскрыть ветку (1)

k1aus

10 месяцев назад