Как правильно использовать шлюз из локальной сети с роутингом трафика на микротик?
Имеется сеть из mikrotik 192.168.1.1, подключенного к интернету, компьютер 192.168.1.2 и linux сервер 192.168.1.3. На сервере поднят и работает tun0, с настроенными маршрутами. Если на компьютере задать в качестве шлюза адрес сервера 192.168.1.3 - все работает. Так же частично удалось реализовать схему через микротик, когда шлюзом на компьютере установлен 192.168.1.1, через таблицу mangle и маркировку трафика по ip источника, и последующим роутом на адрес сервера. Но в этом случае, интернет на компьютере работает плохо, половина сайтов не открывается. Как правильно использовать шлюз сервера из локальной сети на микротике?
Дополнено:
Задача состоит в том, чтобы трафик роутился микротиком, а сервер использовался как шлюз, но не по умолчанию для всего трафика.
То есть вы хотите, чтобы на станции шлюзом был микротик, он пересылал пакеты на linux, тот пересылал пакеты обратно на mikrotik, и только теперь пакеты шли в интернет, так? и всё это в одной подсети и одном вилане? Вам не кажется, что такая схема, мягко говоря, странненькая?
С моей точки зрения при такой постановке задачи разумнее добавить на linux ещё одну сетевую и врезать его между сетью и mikrotik. Соответствено у станции шлюзом будет linux, у того mikrotik, схема линейная и без заморочек.
Как вариант того же без перекоммутации - выделить под канал linux-mikrotik для трафика в интернет отдельный VLAN (а ещё лучше - отдельный линк, но мы решили обойтись без перекомутации), с отдельной подсетью. То есть станция обращается к микротику, тот маршрутизирует по нужным правилам либо сразу в инет, либо на linux (пока всё можно в рамках дефолтного VLAN и 192.168.1.х, хотя я бы уже ушёл как минимум в другую подсеть), тот обрабатывает и пересылает обратно на микротик (но через другой интерфейс, виртуальный, уже в другой подсети и в другом VLAN, который, к слову, тегованный), и наконец микротик маршрутизирует в интернет.
Ну и надо понимать, что один и тот же трафик по одному и тому же кабелю должен пробежать трижды, а потому нужен или широкий и гарантированный (ещё лучше - выделенный, но опять же мы без перекоммутации) канал между микротиком и линухом, или аппетиты у станций подрезать.
Тут есть два сравнительно простых варианта:
1. Разнести компьютер и linux-сервер по разным подсетям (можно в одном и том же физическом сегменте), чтобы маршрутизация на микротике могла работать полноценно
2. Если нужно сохранить ip-адресацию, то на микротике нужно делать маскарадинг трафика (правило SNAT с action=MASQUERADE), который идет с ПК и далее маршрутизируется через linux-сервер. Тогда через микротик будет проходить не только исходящий трафик с ПК, но и ответный, и с хорошей вероятностью это устранит проблемы
хотите, чтобы на станции шлюзом был микротик, он пересылал пакеты на linux, тот пересылал пакеты обратно на mikrotik, и только теперь пакеты шли в интернет, так? и всё это в одной подсети и одном вилане? Вам не кажется, что такая схема, мягко говоря, странненькая?
Да так и хочу, только одно уточнение назад от сервера пакеты уже будут идти через tun, поднятом на сервере. Моя реализация кажется странной, поэтому спрашиваю, как сделать правильно.
С моей точки зрения при такой постановке задачи разумнее добавить на linux ещё одну сетевую и врезать его между сетью и mikrotik. Соответствено у станции шлюзом будет linux, у того mikrotik, схема линейная и без заморочек.
К сожалению, этот вариант невозможен, на сервере только один физический lan порт.
Как вариант того же без перекоммутации - выделить под канал linux-mikrotik для трафика в интернет отдельный VLAN (а ещё лучше - отдельный линк, но мы решили обойтись без перекомутации), с отдельной подсетью.
Не имею опыта работы с vlan, пробую, но ничего не выходит - роутер с сервером не видят друг друга. Но не будет ли эта схема, схожей с организацией тоннеля, с целью разграничения подсетей? Тут я подробнее описал, но не смотря на то, что шлюзом указан адрес из подсети тоннеля, пакеты уходят по адресу сервера напрямую.
1. Разнести компьютер и linux-сервер по разным подсетям
Как это реализовать, с учетом того, что роутер с сервером соединены одним физическим каналом, и важно чтобы сервер так же был доступен по своему основному адресу 192.168.1.3 и работал как прежде?
2. Если нужно сохранить ip-адресацию, то на микротике нужно делать маскарадинг трафика (правило SNAT с action=MASQUERADE),
Так, NAT - srcnat - src address 192.168.1.2 src destination 192.168.1.3, action - masquerade? А как его дальше маршрутизировать? Я правильно понимаю, что суть завключается в том, чтобы пакеты на сервер приходили не с ip адреса компьютера, а ip роутера 192.168.1.1?
только одно уточнение назад от сервера пакеты уже будут идти через tun, поднятом на сервере.
Какая разница? туннель - он на более высоком уровне модели, то есть не на уровне физического трафика в кабеле, а уже на уровне программного обеспечения внутри устройства.
пробую, но ничего не выходит - роутер с сервером не видят друг друга.
Значит, с одной стороны порт в транковом режиме (tagged), а с другой в клиентском (untagged). Во всяком случае, это наиболее вероятная причина.
К сожалению, этот вариант невозможен, на сервере только один физический lan порт.
Ага, и слота на матери нет, в который можно вставить сетевую карту... микросервер, что ли?
схема, схожей с организацией тоннеля, с целью разграничения подсетей?
Туннель - для разделения подсетей? вы серьёзно? нет, оно может быть так, но это будет побочный эффект, а совсем даже не целевой.
Так, NAT - srcnat - src address 192.168.1.2 src destination 192.168.1.3, action - masquerade? А как его дальше маршрутизировать? Я правильно понимаю, что суть завключается в том, чтобы пакеты на сервер приходили не с ip адреса компьютера, а ip роутера 192.168.1.1?
Не совсем так. 192.168.1.3 - это адрес шлюза, а destination - это весь трафик, который через него маршрутизируется. Поэтому такой трафик можно описать либо с помощью dst-address-list, куда будут включены все подсети, маршрутизируемые через 192.168.1.3, либо с помощью connection mark/routing mark (если трафик маркируется в IP Firewall / Mangle), либо просто указав out interface = интерфейс микротика с адресом 192.168.1.1 (этот вариант кривоват, но будет работать, если дополнительный шлюз в сети только один)
в том что это уже как раз другая подсеть и тут, никаких проблем нет
Ага, и слота на матери нет, в который можно вставить сетевую карту... микросервер, что ли?
а почему нет, вам не кажется перебором добавление сетевых карт и смена архитектуры сети? Наверняка, все решается в пару команд и правил.
Туннель - для разделения подсетей? вы серьёзно? нет, оно может быть так, но это будет побочный эффект, а совсем даже не целевой.
конкретно в моем случае и есть целевой, чтобы хотя бы понять, будет оно так работать или нет. Тоннель поднят, другая подсеть получена - не сработало. Понятно, что использование тоннеля, даже без шифрования не лучшая идея, хотя бы из-за накладных расходов, особенно, если существуют нормальные решения.
тут поднят GRE тоннель до сервера на подсети 192.168.3.0/24. Но трафик идет в обход этого правила, причем судя по всему на 192.168.1.3, несмотря на то, что в роуте явно указан 192.168.3.3.
ganzales, а сервер в подсети 192.168.3.0/24 - это тот же линукс-сервер с ip 192.168.1.3? Если да, нужно, чтобы через туннель пошел и ответный трафик, т.е. маршрутизация должна быть настроено и на другом конце туннеля. Если исходящий и входящий трафик ходят по разным маршрутам, то возможны разнообразные побочные эффекты, которые скорее всего и возникли у вас, а маскарадинг позволяет обойти эту проблему. Т.е. вам нужно в out-interface= подставить тот интерфейс, через который будет идти трафик, маршрутизируемый через линукс-сервер, либо настраивать и микротик, и линукс-сервер так, чтобы асимметричного прохождения трафика не было.
Дмитрий, разобрался вроде худо-бедно, из-за череды глюков полез в дебри. С толку сбили трассировка, которая судя по всему показывает узел, а не фактический адрес, из-за чего я считал что трафик идет на локальный адрес, а не тот который указан в маршруте, и глючное соединение по tun, которое само по себе периодически отваливалось. Из-за этих двух вещей перекопал пол интернета, убил кучу времени, а решение было мной рассмотрено еще в самом начале, вот оно
Пробую поднимать тоннель от микротика до сервера, например IPIP, с подсетью 192.168.2.0/24, и использовать в качестве шлюза адрес сервера из тоннеля 192.168.2.3 - трафик по прежнему идет на 192.168.1.3 (проверяю трассировкой)
Undefiend, может не совсем вас понял. Я так и делаю, создаю делаю правила и перенаправляю трафик на шлюз, которым является локальный сервер. Если поднять tun уже на самом микротике, и использовать его в качестве шлюза все работает без проблем. Пробую поднимать тоннель от микротика до сервера, например IPIP, с подсетью 192.168.2.0/24, и использовать в качестве шлюза адрес сервера из тоннеля 192.168.2.3 - трафик по прежнему идет на 192.168.1.3 (проверяю трассировкой) и все работает плохо. Похоже проблема в том, что сервер находится в одной подсети с роутером и трафик с роутера уходит на сервер, а потом обратно на роутер, т.к. он подключен к интернету, хоть и через tun, но видимо часть трафика идет напрямую, может образуется какая-то петля или что-то типа того. Это что-то из базовых настроек сетей, как мне кажется.
