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

Пробовал еще маркировать траффик на интерфейсе pptp, и роутить его на нужный мне интерфейс, но подключается все равно через первый канал...

evgeniy.milovanov писал(а): ↑01 ноя 2020, 17:20 Не совсем понял, со стороны клиента нет белых ip, соединение на интерфейсе через pppoе

Но дефолтный то gateway то у него все равно есть, правильно?

/ip route print что показывает?

xvo писал(а): ↑01 ноя 2020, 18:11 Но дефолтный то gateway то у него все равно есть, правильно?

/ip route print что показывает?

Есть подозрение, что мы с Вами говорим про разные вещи. Я походу слишком неудачно описал вопрос. Давайте все упростим, микротик - ether1 это первый провайдер (выдает адреса по dhcp), ether3 второй провайдер подключение pppoe, соответственно на порту висит pppoe клиент (логин пароль и больше ничего).
Создаю pptp на адрес сервера, подключаемся через ether1 по умолчанию. Что бы соединение ушло через pppoe интерфейс ip-routes где dst.address это адрес pptp сервера (белый ip микротика на котором поднят сервер) и гейтвей pppoe интерфейс. При такой маршрутизации и возникает проблема которую я описал.
Указать шлюз в виде ip я не могу, я его не знаю:) для pppoe то в рамках сети провайдера не нужно дополнительно ничего, я адресацию у себя на порту могу какую угодно прописать, но в сервер я все равно попаду ж...

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

Честно сказать, больше никаких конкретных идей больше нет.
Только шерстить весь конфиг на предмет каких-то аномалий.

Но с другой стороны, насколько всё это вообще важно?
Держать винбокс открытым наружу в любом случае плохая идея, а через туннель у вас все ок.

xvo писал(а): ↑01 ноя 2020, 20:37 Но с другой стороны, насколько всё это вообще важно?
Держать винбокс открытым наружу в любом случае плохая идея, а через туннель у вас все ок.

Ну в целом это не столь важно, конкретно в моем случае... Винбокс приходится держать открытым наружу, в него к стати практически не ломятся.

Но саму проблему я решил... Кто будет искать может полезно будет, в особенности у кого кастомные фаерволы, смотрим что куда "разрешили-запретили" и в любых непонятных ситуациях выключайте фасттрек:) Его отключение и решило проблему затупов при маршрутизации через второй канал... Сама фишка конечно полезная но в целом влияет на большое количество манипуляций в routerOS.
Спасибо Вам за отклик на вопрос:)

evgeniy.milovanov писал(а): ↑01 ноя 2020, 23:22 Но саму проблему я решил... Кто будет искать может полезно будет, в особенности у кого кастомные фаерволы, смотрим что куда "разрешили-запретили" и в любых непонятных ситуациях выключайте фасттрек:) Его отключение и решило проблему затупов при маршрутизации через второй канал...

Интересно, хотя и всё-таки не до конца понятно.
Вы во второй канал отправляете без участия mangle, без участия ipsec, просто обычным маршрутом в основной таблице - с чего вдруг fasttrack должен что-то ломать?!
Видимо что-то у вас в конфигурации firewall'а все-таки сильно нестандартное.

xvo писал(а): ↑01 ноя 2020, 23:32 Интересно, хотя и всё-таки не до конца понятно.
Вы во второй канал отправляете без участия mangle, без участия ipsec, просто обычным маршрутом в основной таблице - с чего вдруг fasttrack должен что-то ломать?!
Видимо что-то у вас в конфигурации firewall'а все-таки сильно нестандартное.

В принципе он не ломает ничего, все работает, все пингуется хорошо, внутри тунеля тоже нет никаких затупов, но если открыть тем же винбоксом морду микротика по ip из своей сети, то пока он отобразит хотя бы список интерфейсов можно было перекурить сходить... Есть маршруты в которые раскидывают трафик внутренней сети и "гостевой", через маркировку, никаких проблем не было... Файервол тоже стандартный, ничего особенного, возможно за время всех изменений в конфиге, что то пошло не так.
Я замечал уже за микротами за время работы, что одна и та же модель, стандартные настройки, а после установки на обьектах ведут себя по разному, приходится уже править или сбрасывать повторно, что бы получить нужный результат)

Если у вас таки mangle что-то маркирует, то не удивительно что наличие fasttrack'а имеет прямое значение.
Так же будет не удивительно, если у вас они на самом деле все ходят совсем не через того провайдера, через которого вы предполагаете.

xvo писал(а): ↑02 ноя 2020, 00:49 Так же будет не удивительно, если у вас они на самом деле все ходят совсем не через того провайдера, через которого вы предполагаете.

Все бегает правильно. Траффик идёт через нужный интерфейс, celler id на второй стороне совпадает с адресом выданным провайдером. К моему удивлению перестраивает таблицу маршрутизации если отключить второй канал, хотя явно это не указывается нигде. А при его подключении возвращает все согласно правилам. Сама процедура занимает секунд 30. В целом то что нужно было получено:)