Russian Users MikroTik | Форум пользователей MikroTik

Добрый день, камрады. Требуется совет бывалых по настройке роутинга. Задача - объединение офисов за GW-1, GW-2, GW-4 плюс перенаправляение части трафика наружу через соответсвующие роутеры. GW-3 - man in the middle (удачное расположение, благодаря чему скорость соединения между GW-2 и GW-4 получается выше, пинг меньше), то есть он просто перенаправляет трафик от одного роутера у другому.



Есть такая схема, адреса подсетей за роутерами прописаны в файлвол адрес листах (есть причина сделать так), в мангле трафик размещается (prerouting->mark routing) и в роутинге по этой метке заворачивается в vpn канал. На всех роутерах в NAT включен маскарад в wan и в vpn. И в этой схеме все работает почти прекрасно - пользователи за роутерами GW-2 и GW-4 (GW-1 пока не трогаю чтобы не усложнять) видят друг-друга, видят роутеры GW-2, GW-3, GW-4, трафик наружу идет через соответствующие роутеры корректно. Но маскарад доставляет определенную попа-боль, т.к. не виден ip адрес клиента.

Если выключить маскарад в VPN на GW-2 и GW-4 то вроде как ничего не меняется, все выглядит рабочим, тапки в меня не летят.

Если выключить маскарад в VPN на GW-3, то клиенты из разных подсетей сохраняют доступ друг к другу, но теряется доступ к роутеру на противоположной стороне (т.е. пользователи GW-2 видят GW-2 и GW-3, но не видят GW-4, соотвественно с GW-4 недоступен GW-2). И интернет-траффик наружу (который должен был пройти через sstp и выйти наружу на другой стороне) не идёт. Подскажите в какую сторону копать, чтобы и рыбу съесть и реальные адреса клиентов видеть.

Динамическую маршрутизацию не рассматривали? Можно будет убрать все NAT в туннелях и появятся адреса клиентов + если я понял вашу схему правильно то у вас там sstp через sstp, видимо делали из-за незнания как маршруты писать. Вот тут вроде неплохая подробная инструкция под OSPF https://mikrotiklab.ru/nastrojka/artga- ... u960147468. А дальше уже поверх этого делать статику для разных узлов в разных провайдеров (Route Rules/маркировка).

на самом деле между роутерами sstp + wg + ovpn + lt2p (не стал остальные рисовать чтобы не усложнять). роутеры в разных офисах в разных городах, доблестный роскомзапрет переодически блокирует что-то, что-то разблокирует, пока удается связь между офисами поддерживать. статью изучу, вопрос был скорее как обратные маршруты прописать корректно, чтобы ответы шли в те туннели, из которых приходят запросы но без маскарада (сейчас все vpn интерфейы собраны в одну группу и на эту группу стоит маскарад)

dinosaur, удобно использовать дополнительные профили ppp со своими подсетями для организации резервных каналов. Условно, первый профиль служит для выдачи учетных записей пользователям и одного из подключений маршрутизаторов входящих в сеть. Дополнительные профили нужны только для резервных соединений, на них не надо вешать пул выдаваемых адресов, используются только статические назначаемые вместе с профилем учетным записям. Каждый канал вешаем на отдельный профиль – на стороне клиента во всех vpn подключениях учетные записи должны быть из разных профилей сервера. Цель – обеспечить разные адреса сервера vpn в каналах для возможности организации маршрутов на стороне клиента. Подсети всех ppp профилей лучше держать рядом в одной общей подсети для упрощения оперирования в правилах.

На стороне сервера создаем маршруты с разным значением Distance в сеть клиента используя шлюзом выданный ему адрес и обязательно ставим Check Gateway – ping. На стороне сервера трафик будет уходить корректно только по действующему маршруту и в случае использования одного профиля, одного диапазона клиентских адресов.

На стороне клиента создаем симметричные маршруты в сеть сервера используя то же значение Distance и шлюзом указываем адрес сервера соответствующий профилю выдаваемого адреса. Так же ставим Check Gateway – ping. Трафик начнет уходить с клиента только по действующему маршруту. Если адрес сервера будет один для всех клиентских подключений, то трафик будет уходить одновременно по всем каналам и это будет нормально работать, возможно, такой вариант для кого-то будет предпочтительнее, но тут встает вопрос роста ошибок пакетов из-за разной скорости каналов.

При наличии маршрутов сетей друг в друга и разрешающих правил файрволла для каналов и удаленных сетей – маскарад не нужен.

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

Разобрался. Не прописал маркировку для цепочки output, поэтому ответы от роутера уходили в туманную даль. Но в принципе тот же самый эфект получился когда прописал в Routing -> Rules.