метрика на маршрутах

[Владимир320]

Неожиданный глюк. Есть два дефолтных шлюза с разными метриками, один дефолт провайдерский, чтобы все работало типо, второй дефолт в тонель, т.к. мне нужно весь трафик от  172.17.17.0 завернуть в тонель:

dst 0.0.0.0/0 1.1.1.1 10 внешник от провайдер

dst 0.0.0.0/0 10.10.10.10 1 тонель

172.17.17.0 /24 просто локалка

 

ну и сама железка мне должны быть доступна по внешнику 1.1.1.1. Ведь все должно работать при такой маршрутизации?

 

[fork]

с такой метрикой у вас весь трафик уйдет в туннель

 

я бы в вашей схеме рекомендовал один из вариантов:

1. локалку поместить в отдельный VRF и уже из VRF строить туннель

2. использовать PBR

3. использовать специфик роут а не 0.0.0.0/0 в сторону 10.10.10.10

Edited June 28, 2021 by fork

[Владимир320]

13 часов назад, fork сказал:

с такой метрикой у вас весь трафик уйдет в туннель

 

я бы в вашей схеме рекомендовал один из вариантов:

1. локалку поместить в отдельный VRF и уже из VRF строить туннель

2. использовать PBR

3. использовать специфик роут а не 0.0.0.0/0 в сторону 10.10.10.10

 

так мне и нужно все отправлять в тоннель, чтобы инет работал через тоннель

 

в общем проверил, работает. Провайдерский дефолт с метрикой 10, дефолт в тоннель метрика 1, все отлично работает

[VolanD666]

12 минут назад, Владимир320 сказал:

так мне и нужно все отправлять в тоннель, чтобы инет работал через тоннель

Ну тогда пропишите специфический маршрут до другого конца туннеля через провайдера, зачем вам через него дефолт?

 

13 минут назад, Владимир320 сказал:

в общем проверил, работает. Провайдерский дефолт с метрикой 10, дефолт в тоннель метрика 1, все отлично работает

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

[Владимир320]

9 минут назад, VolanD666 сказал:

Ну тогда пропишите специфический маршрут до другого конца туннеля через провайдера, зачем вам через него дефолт?

 

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

что тут корявого?

[VolanD666]

1 минуту назад, Владимир320 сказал:

что тут корявого?

У вас два дефолта из которых должен работать один с наименьшей метрикой. Так маршрутизация должна работать. То что это работает сайчас, это странно и в будущем может принести проблемы. Я бы так не делал.

[Владимир320]

вполне обычная тема, дефолт отправлять в тоннель, но чтоб работал тоннель, нужен второй дефолт к провайдеру. Провайдерский дефолт делаю с метрикой 100, дефолт в тонель метрика 1. Прекрасно поднимается тонель и все работает. Для внешнего адреса дефолтный роут с метрикой 100 вообще не играет никакой роли так как дефолтный шлюз это л2, то есть преоритет. Понимаете?  

 

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

[VolanD666]

1 час назад, Владимир320 сказал:

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

Выбор лучшего маршрута происходит согласно метрике и маршрутизатору должно быть все равно для чего вам этот дефолт. Поэтому когда вы делаете два дефолта один с метрикой 1, а другой с метрикой 100 по хорошему весь трафик должен идти через первый роут, так как он лучше. Почему у вас сейчас туннель работает, я не могу сказать. Может это фича микротика. Но я бы не стал рассчитывать, что он не отвалится в будущем или что при обновлении это поведение не изменится.

 

А в таблице маршрутизации у вас оба маршрута активны?

[Владимир320]

11 минут назад, VolanD666 сказал:

Выбор лучшего маршрута происходит согласно метрике и маршрутизатору должно быть все равно для чего вам этот дефолт. Поэтому когда вы делаете два дефолта один с метрикой 1, а другой с метрикой 100 по хорошему весь трафик должен идти через первый роут, так как он лучше. Почему у вас сейчас туннель работает, я не могу сказать. Может это фича микротика. Но я бы не стал рассчитывать, что он не отвалится в будущем или что при обновлении это поведение не изменится.

 

А в таблице маршрутизации у вас оба маршрута активны?

Для примера у меня внешник 7.7.7.2, дефолтный шлюз 7.7.7.1, то когда у меня src 7.7.7.2, то я улечу на 7.7.7.1 при любой метрике. Я когда у меня src из локальной сети, к примеру 172.16.100.0/24, то тут уже будет выбираться наилучший маршрут исходя из метрики.

Если я ошибаюсь, поправьте. 

На микроте дефолтный роут с меньшей метрикой типо неактивным становится, это да, но он неактивный для лан сети!??

[VolanD666]

41 минуту назад, Владимир320 сказал:

Для примера у меня внешник 7.7.7.2, дефолтный шлюз 7.7.7.1, то когда у меня src 7.7.7.2, то я улечу на 7.7.7.1 при любой метрике. Я когда у меня src из локальной сети, к примеру 172.16.100.0/24, то тут уже будет выбираться наилучший маршрут исходя из метрики.

Если я ошибаюсь, поправьте. 

Маршрутизатор принимает решение о исходящем интерфейсе только на основе адреса назначение. То о чем вы говорите, называется PBR

 

41 минуту назад, Владимир320 сказал:

На микроте дефолтный роут с меньшей метрикой типо неактивным становится, это да, но он неактивный для лан сети!??

У таблицы маршрутизации поведение одно на всех и не зависит от сегментов сети.

 

Я предполагаю, что поведение может измениться после перезагрузки роутера или после выкл/вкл туннельного интерфейса

[Владимир320]

1 час назад, VolanD666 сказал:

Маршрутизатор принимает решение о исходящем интерфейсе только на основе адреса назначение. То о чем вы говорите, называется PBR

 

У таблицы маршрутизации поведение одно на всех и не зависит от сегментов сети.

 

Я предполагаю, что поведение может измениться после перезагрузки роутера или после выкл/вкл туннельного интерфейса

тоннель клался поднимался, перезагружался и работает норм. Тая схема работает на микроте. Сделал подобное на фортигейте и не работает

Edited June 29, 2021 by Владимир320

[reef]

Чудес не бывает, на микроте 100% настроен PBR ну или как так у микрота это называется "routing-mark" по другому это бы и не работало.

С разными " routing-mark " для дефолта в сторону ISP  и в сторону  VPN метрика может быть одинаковая, менять ее не имеет смысла.

[VolanD666]

9 часов назад, reef сказал:

Чудес не бывает, на микроте 100% настроен PBR ну или как так у микрота это называется "routing-mark" по другому это бы и не работало.

С разными " routing-mark " для дефолта в сторону ISP  и в сторону  VPN метрика может быть одинаковая, менять ее не имеет смысла.

Ну в том то и дело, что на Микроте как раз баывает такая история, что работает когда не должно. Правда потом после перезагрузки/обновления поведение менялось и приходилось делать по правильному.

[guеst]

по идее если вы при такой схеме обратитесь с глобала к внешнему белому ip, то ответ вам (без PBR) улетит по приоритетному дефолту, т.е. в тунель....

[Владимир320]

Никакой маркировки я не делал, может в микроте чёт и создаётся притакой схеме, да нам не отображается 

[lugoblin]

On 6/29/2021 at 2:44 AM, Владимир320 said:

вполне обычная тема, дефолт отправлять в тоннель, но чтоб работал тоннель, нужен второй дефолт к провайдеру.

Нет. Тема вполне обычная, но второго дефолта к провайдеру не надо, тем более с одинаковой метрикой..

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

 

Например, до создания туннеля:

default via 111.111.111.1

111.111.111.0/30 scope link src 111.111.111.2

Гейт провайдера 111.111.111.1, у нас 111.111.111.2, и мы с провайдером в сетке с маской 255.255.255.252.

 

После создания туннеля с сервером 222.222.222.1, добавляем для него очень специфичный маршрут:

default via 111.111.111.1

111.111.111.0/30 scope link src 111.111.111.2

10.10.10.1/32 dev ppp0

222.222.222.1 via 111.111.111.1

Внутри туннеля наш гейт 10.10.10.1, но пока Интернет работает как было.

 

После перенаправления траффика в туннель, через гейт 10.10.10.1:

default via 10.10.10.1

111.111.111.0/30 scope link src 111.111.111.2

10.10.10.1/32 dev ppp0

222.222.222.1 via 111.111.111.1

Траффик вне туннеля, до сервера VPN, подчиняется более специфичному маршруту. Всё остальное идёт по дефолтному.

 

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

default via 111.111.111.1 metric 100

111.111.111.0/30 scope link src 111.111.111.2

10.10.10.1/32 dev ppp0

222.222.222.1 via 111.111.111.1

default via 10.10.10.1 metric 50

 

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

default via 111.111.111.1

111.111.111.0/30 scope link src 111.111.111.2

10.10.10.1/32 dev ppp0

222.222.222.1 via 111.111.111.1

0.0.0.0/1 via 10.10.10.1

128.0.0.0/1 via 10.10.10.1