Pref source mikrotik что это

03.10.202305.07.2022 admin 0 Comments

Preferred source

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

Для начала нам необходимо выяснить, каким образом MikroTik выбирает себе IP адрес источника перед тем, как отправить пакет.

И так для понимания приведём простой пример.

Перед вами таблица маршрутизации моего домашнего маршрутизатора, я убрал из вывода протокол OSPF и именованные таблицы маршрутизации, чтобы не было простынки 400 маршрутов.

Когда вы назначаете IP адрес на интерфейс, RouterOS автоматически создаёт connected маршрут, до сети, которая высчитывается из адреса и маски, которую вы указали при назначении IP адреса, а также устанавливается параметр pref-src, который соответствует непосредственно назначенному IP адресу

Если у вас несколько IP адресов из одной подсети, то параметр pref-src будет назначен, самой первой записи IP адресу, обратите внимание ни самому низкому IP адресу, а к тому IP адресу, который был первый назначен на интерфейс.

Теперь попробуем запустить ping до адреса 10.255.200.1

Как видите ping прошёл, теперь взглянем на нашу таблицу маршрутизации и найдём наилучший маршрут для IP адреса 10.255.200.1

Так как при запуске ping мы явно не указали с какого IP адреса отправлять пакет, то ядро RouterOS выбрало наилучший маршрут для IP адреса назначения, и в данном маршруте указан параметр pref-src, именно такой IP адрес был использован при генерации пакетов.

Попробуем явно указать IP адрес, маршрут до которого на хосте 10.255.200.1 отсутствует.

Как видите, к нам не возвращается пакет, так как на хосте 10.255.200.1 маршрут до адреса 10.188.48.99 не соответствует интерфейсу до нашего маршрутизатора. По простому он улетает куда-то не туда.

А теперь попробуем сделать ping до хоста 8.8.8.8

Взглянем на таблицу маршрутизации и определим наилучший маршрут для адреса 8.8.8.8

Pref-source не указан, так какой IP адрес будет выбран тогда?

А здесь кроется маленький нюанс о котором многие забывают, а может и не знают.

Любое сетевое устройство когда выбирает из таблицы маршрутизации маршрут, всегда делает столько итераций поиска, сколько понадобится пока не найдёт интерфейс выхода. Именно для уменьшения нагрузки на процесс выбора маршрута необходимы параметры scope, но об этом в другой раз.

Итак, маршрут найден

MikroTik смотрит на поле pref-src если указано значение, то в пакете будет установлен адрес источника, но в нашем случае параметра нет.

Так как адрес шлюза не соответствует интерфейсу, то маршрутизатор повторяет процесс поиска маршрута, но уже не для адреса 8.8.8.8, а для адреса 10.188.48.1

И результат поиска будет

И в данном случае pref-src указан, адрес источника если на данный момент не установлен, будет указан как 10.188.48.99.

Так как маршрутизатор всегда опускается по цепочке до маршрута, который указывает на интерфейс, а такой маршрут connected заполняется автоматически на основании IP адреса назначенного на интерфейс, MikroTik всегда назначает какой-нибудь IP адрес на интерфейсе.

Например, если бы в нашем случае у нас было два IP адреса из одной сети, мы бы могли указать на дефолтом маршруте значение pref-src тот ip адрес, с которого необходимо отправлять трафик в интернет.

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

Если вы используете OSPF и у вас есть loopback адрес, и в свою очередь вы данные loopback адреса редистрибьютите в сеть OSPF, то вы можете сделать следующий lifehack

Естественно адрес 172.31.255.1 заменить на адрес loopback того маршрутизатора, на котором будет выполняться данная команда.

После данной команды не забудьте поставить правило выше discard-а, итого при той же трассировке вы в списке хопов будете видеть не внутренние адреса интерфейсов, а адреса loopback-ов, что значительно удобнее.

Источник

Pref source mikrotik что это

И так для понимания приведём простой пример.

Когда вы назначаете IP адрес на интерфейс, RouterOS автоматически создаёт connected маршрут, до сети, которая высчитывается из адреса и маски, которую вы указали при назначении IP адреса, а также устанавливается параметр pref-src, который соответствует непосредственно назначенному IP адресу

Теперь попробуем запустить ping до адреса 10.255.200.1

> /ping 10.255.200.1 SEQ HOST SIZE TTL TIME STATUS 0 10.255.200.1 56 64 4ms 1 10.255.200.1 56 64 4ms sent=2 received=2 packet-loss=0% min-rtt=4ms avg-rtt=4ms max-rtt=4ms

3 ADC 10.255.200.1/32 10.255.200.2 ipip-trm 0

Попробуем явно указать IP адрес, маршрут до которого на хосте 10.255.200.1 отсутствует.

> /ping 10.255.200.1 src-address=10.188.48.99 SEQ HOST SIZE TTL TIME STATUS 0 10.255.200.1 timeout 1 10.255.200.1 timeout 2 10.255.200.1 timeout sent=3 received=0 packet-loss=100%

А теперь попробуем сделать ping до хоста 8.8.8.8

> /ping 8.8.8.8 SEQ HOST SIZE TTL TIME STATUS 0 8.8.8.8 56 46 6ms 1 8.8.8.8 56 46 6ms sent=2 received=2 packet-loss=0% min-rtt=6ms avg-rtt=6ms max-rtt=6ms

Взглянем на таблицу маршрутизации и определим наилучший маршрут для адреса 8.8.8.8

0 A S 0.0.0.0/0 10.188.48.1 1

Pref-source не указан, так какой IP адрес будет выбран тогда?

А здесь кроется маленький нюанс о котором многие забывают, а может и не знают.

Итак, маршрут найден

0 A S 0.0.0.0/0 10.188.48.1 1

И результат поиска будет

1 ADC 10.188.48.0/22 10.188.48.99 ether1 0

И в данном случае pref-src указан, адрес источника если на данный момент не установлен, будет указан как 10.188.48.99.

> /routing filter add chain=ospf-in set-pref-src=172.31.255.1

Привет. Это короткая заметка про то, какие именно IP мы видим в любимом tracert/traceroute, и как это зависит от лейбла на коробках в аппаратных вашего ISP и его апстримов.
Думаю, все знают, что у маршрутизатора, как правило, множество IP-адресов (ну или хотя бы точно больше, чем 1). В условиях такого многообразия перед маршрутизатором ставится нелегкий выбор: какой именно из его IP-адресов необходимо выбрать в качестве источника сообщения ICMP TTL Exceeded, которое и является основой для вывода трассировки?
Если вы никогда ранее не задумывались над данным вопросом, то вот некоторые варианты, которые могут прийти в голову в первую очередь:
1. IP-адрес интерфейса, который являлся входящим для оригинального пакета.
2. IP-адрес интерфейса, который должен был бы являться исходящим для оригинального пакета.
3. IP-адрес интерфейса, который будет являться исходящим для ICMP-сообщения.
4. IP-адрес лупбэка.
Если вы все же задумывались об этом ранее, то не спешите давать однозначный ответ 🙂
Для ответа на вопрос из названия публикации я собрал вот такую лабу в GNS3:

Некоторые пояснения к топологии:
1. Трассировка будет производиться от PC1 к PC2.
2. На каждом маршрутизаторе есть лупбэк вида X.X.X.X
3. На всех роутерах и всех интерфейсах запущен OSPF Area 0.
4. OSPF Interface Cost распределены таким образом, что трафик от любого роутера до 60.0.0.0/24 (сеть PC2) пойдет «вертикально», т.е. через цепочку оставшихся роутеров. И наоборот, трафик до 10.0.0.0/24 (сеть PC1) от любого роутера кроме Cisco1 пойдет через SW1 (что соответствует сети 123.0.0.0/24). Таким образом мы добиваемся ситуации, при которой входящий интерфейс оригинального пакета и исходящий интерфейс ICMP-сообщения не совпадают.
Кто-то скажет: зачем нужна такая далекая от реальности топология, в моей компании весь трафик в обе стороны ходит строго симметрично.
Ответ: Для OSPF это действительно не самая типичная ситуация, он использовался исключительно для упрощения конфигурации. В реальности за асимметрию путей вашего трафика в основном ответственен BGP.

Запускаем трассировку

Как вы можете видеть, Cisco и Juniper ответили с IP входящего интерфейса, тогда как Debian Linux и Mikrotik (имеющий тот же Linux в корнях своей операционки) ответили с IP интерфейса, который являлся исходящим для ICMP-пакета (123.0.0.X).
Record Route для сравнения:

Заключение

Поведение Linux и Mikrotik объясняется пунктом из RFC 1812. Этот пункт указывает, что source-адресом ICMP-сообщения должен являться адрес интерфейса, через который должен быть передан данный ICMP-пакет.
В это же время такие гиганты индустрии, как Cisco и Juniper, позволяют себе игнорировать указание RFC, очевидно полагаясь при этом на свой не дюжий опыт. И действительно, наблюдать в трассировке IP-адреса интерфейсов, через которые должен пройти оригинальный пакет, как по мне, видится более правильным решением, чем обнаруживать в той же трассировке IP из подсетей, строго говоря не имеющих к реальному пути пакета никакого прямого отношения.

Источник

Объединение двух офисов по VPN на Mikrotik.

Задача стоит “подключить два удаленных офиса между собой по VPN”.
В обоих офисах стоят маршрутизаторы Mikrotik.

Адресация офисов.

Адресация Офиса 1 (MSK), который будет у нас VPN-сервером:
WAN 88.53.44.1
LAN 192.168.10.0/24
VPN 192.168.60.1
Адресация Офиса 2(SPB), который будет VPN-клиентом:
WAN 88.53.55.2
LAN 192.168.20.0/24
VPN 192.168.60.2

Настройка VPN-server.

1. Первый маршрутизатор в офисе MSK.
Включаем VPN-Server.

2. Создаем пользователя, который к нам будет подключаться.

3. Добавляем интерфейс сервера.

Настройка VPN-клиента.

Второй маршрутизатор в офисе SPB, создаем клиентское подключение к головному офисе в Москве. Пользователь с именем User, пароль 1225555

Маршрутизация офисов.

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

Начнем с первого офиса в MSK:
dst-address – указываем локальную сеть офиса в SPB, к которой будем подключаться.
gateway – шлюз через который будем подключаться к сети, ip VPN клиента.
pref. source – указываем свою локальную сеть, с которой будем выходить.

Второй офис в SPB:

Заключение

Таким образом мы объединили два офиса между собой позволив пользователям чувствовать себя в одной сети и использовать внутренние общие ресурсы.

Если вы не видите общие ресурсы компьютеры офисов между собой или не проходит ping – отключите на обоих машинах firewall и проверьте открытость UDP порта 1701.

Источник

Инструкции по настройке MikroTik

Настройка статической маршрутизации в MikroTik

Когда нужно применять статическую маршрутизацию в MikroTik

Любая корпоративная сеть, как правило состоит из многоуровневой коммутации как на уровне самого роутера, так и во внешних сервисах. В качестве примера будет сформирован список случаев, когда актуально обратиться к настройке статического маршрута(route) на маршрутизаторе(роутере) MikroTik:

Нужно настроить статическую маршрутизацию MikroTik?

Мы поможем настроить: маршрутизатор(роутер), точку доступа или коммутатор.

Как настроить “static routing” в MikroTik

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

Настройка находится IP→Routes

Dst. Address – конечный адресат, популярные значения

Gateway – шлюз, которому будет отправлен пакет.

Check Gateway – проверка доступности шлюза:

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

Type – маршруты, которые не указывают nexthop для пакетов, но вместо этого выполняют некоторые другие действия с пакетами, имеют тип, отличный от обычного unicast(одноадресного). Маршрут blackhole(черная дыра) молча отбрасывает пакеты, в то время как маршруты, unreachable(недоступные) и prohibit(запрещающие), отправляют сообщение ICMP Destination Unreachable (код 1 и 13 соответственно) на адрес источника пакета.

Distance – определение приоритета заданного маршрута. Чем ниже число, те выше приоритет.

Scope\Target Scope – параметры рекурсивной маршрутизации, состоящей из этапов:

Больше информации по использованию параметров ааа можно найти в соответствующем руководстве “Manual:Using scope and target-scope attributes → ”

Поддержи автора статьи, сделай клик по рекламе ↓↓↓

Routing Mark – направлять пакеты из заданной таблицы маршрутизации. Как правило этот параметр или пустой или заполняется промаркерованнымb маршрутами из раздела Mangle.

Pref. Source – задается IP адрес, от которого будет отправлен пакет. Этот параметр актуален, когда на интерфейсе несколько IP адресов.

Примеры статических маршрутов в MikroTik

Настройка статического маршрута с предварительной маркировкой пакета(раздел Mangle)

Применяется для использования разных линий интернета для разных узлов. К примеру в сети расположено два сервера, использующие внешние порты 80 и 443.

Для работы правила нужно промаркировать трафик(раздел Mangle) и указать его в параметре Routing Mark.

Ручное добавление статического маршрута для PPPOE подключения

Применяется, когда нужно изменить некоторые параметры в автоматическом добавлении маршрута(Add default route)

Настройка резервного интернет канала

В качестве параметра переключателя между провайдера используется параметр Distance. Трафик в этом случае направляется в тот маршрут, значение Distance которого МЕНЬШЕ,

Балансировка нагрузки для двух интернет каналов

Осуществляется через почередное указание шлюзов провайдера. Параметром Gateway можно задавать не только последовательность, но и управлять количественной частью. К примеру, если вам нужно чтобы к провайдеру со шлюзом 11.11.11.11 уходило в 2 раза больше трафика(или там канал в 2 раза быстрее) достаточно этот шлюз указать два раза.

Добавление статического маршрута для VPN соединения

В качестве шлюза указывается IP адрес VPN клиента. Использование таких маршрутов в MikroTik популярно, когда в качестве L2TP или PPTP VPN клиента выступает роутер, со своей подсетью.

Поддержи автора статьи, сделай клик по рекламе ↓↓↓

Есть вопросы или предложения по настройке статической маршрутизации в MikroTik? Активно предлагай свой вариант настройки! Оставить комментарий →

Источник

Рекурсивная маршрутизация в MikroTik

Принцип работы рекурсивной маршрутизации в MikroTik и что такое scope и target-scope

Рекурсивная маршрутизация

Данная реализация поведения маршрутизации появилась из-за того, что в протоколе BGP при распространении маршрутов полученных через eBGP в iBGP next-hop по умолчанию, не меняется. Но не будем о BGP, а будем о простом.

Давайте начнём с простого, ниже я привёл таблицу маршрутизации простого маршрутизатора без каких либо излишек.

Смотря на таблицу маршрутизации выше, ответьте на вопрос. Какой шлюз будет выбран для отправки пакета на адрес 8.8.8.8?

Я более чем уверен, что вы абсолютно правильно определили шлюз как 10.11.100.254 в маршруте 0.0.0.0/0 по номером ноль.

А теперь попробуйте ответить на следующий вопрос. Какой интерфейс будет выбран для отправки пакета на адрес 8.8.8.8? Почувствуйте разницу, в первом вопросе я спрашивал про шлюз, а в данном вопросе про интерфейс.

И вы скорее всего все ответите, что ether1 и будете правы, но вопрос почему именно так.

Задача маршрутизатора, определить не шлюз, а интерфейс выхода, так как маршрутизатору надо будет понять как передать до шлюза пакет, если тип ethernet, то необходимо будет выяснить с помощью arp mac адрес шлюза, если это какой-то тип инкапсуляции, то пакет надо обернуть в данный тип инкапсуляции и отправить, на адрес пира.

Я не могу, вам показать fullview таблицу маршрутизации, так как она бы банально заняла огромное место на данной странице.

И так представьте у себя в голове таблицу маршрутизации в 700000 маршрутов. Представили?!

Я намеренно проигнорирую такие вещи как Кеш таблицы маршрутизации. (Представим, что его нет.)

Перед маршрутизатором стоит задача, отправить пакет на адрес 8.8.8.8

В данном процесс поиска, есть одно тонкое место, при повторном поиске маршрута, уже до адреса шлюза 5.5.5.1 маршрутизатор проходит опять всю таблицу маршрутизации. Вам не кажется, что это немного излишне? Строго говоря адрес шлюза должен быть в непосредственно присоединенной сети к маршрутизатору! Так может следующий поиск осуществлять только среди connected маршрутов? да это было бы идеально. Но так как я уже написал выше, в протоколе BGP при передачи маршрута из eBGP в iBGP адрес шлюза не меняется, то шлюз уже не может быть connected. И что же делать?

Scope

В linux, а так как RouterOS основан на Linux, то также и в RouterOS введено такое понятие как scope маршрута и target-scope

У любого маршрута есть, свой scope и target-scope.

Теперь давайте смотря на таблицу маршрутизации выше, попробуем ответить на вопрос. Какой интерфейс будет выбран для отправки пакета на адрес 8.8.8.8?

Значения Scope

Значение вы можете править руками, как для scope так и для target-scope. В случае с динамической маршрутизацией вы можете scope или target-scope указать с помощью фильтров маршрутизации, но вам необходимо знать, что есть предустановленные значения.

Все типы маршрутов, кроме на iBGP, основаны на состоянии интерфейса, ну возможно eBGP немного сбоку стоит, так как по умолчанию он требует прямой связности с пиром, хотя это обходится с помощью multihop. А iBGP у него target-scope = 30, так как адрес шлюза не меняется, и нужен ещё один какой-то протокол, который бы сообщил как достичь сети nexthop-a. Например статический маршрут или зачастую ospf.

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

И так давайте переделаем дефолтный маршрут, и адрес шлюза укажем не наш шлюза, а например 8.8.8.8

Создадим маршрут до 8.8.8.8 через шлюз нашего провайдера.

Создали, маршрут но маршрут по умолчанию, до сих пор не активен. Так как маршрутизатор всё также не смогу найти, маршрут до 8.8.8.8, так как target-scope дефолтного маршрута равен 10, и именно среди таких scope будет производится поиск до адреса 8.8.8.8. Нам необхоидимо установить scope маршрута 8.8.8.8, так чтобы он попадал под поиск, а это значит установить scope либо 10 или меньше. Сделаем.

И наблюдаем, то что поднялся рекурсивный маршрут. gateway-status=8.8.8.8 recursive via 10.11.100.254

Теперь давайте ещё раз ответим на вопрос, только изменим адрес назначения. Какой интерфейс будет выбран для отправки пакета на адрес 4.4.4.4?

А теперь мы можем сделать следующее, мы можем указать, использовать check-gateway и тем самым проверять доступность 8.8.8,8, и если будут недоступны, маршрут умрёт, и станет активным какой-нибудь другой маршрут с худшей дистанцией, например через LTE интерфейс.

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

Одними 8.8.8.8 сыт не будешь

Да конечно, если упадёт 8.8.8.8, то мало не поздоровиться, будете переделывать. Можно поступить следующим образом.

Например взять три хоста высокой доступности 1.1.1.1, 8.8.8.8 и 77.88.8.8, можете любые свои, главное чтобы они действительно максимально всегда были доступны.

Создать три маршрута, через нашего провайдера. Таким образом

Далее создать три дефолтных рекурсивных маршрута, разной дистанцией.

В итоге, у вас будет такая картина в Winbox.

Если от 77.88.8.8 перестанет приходить ответы icmp, но при этом 8.8.8.8 будет приходить, то маршрут через шлюз 77.88.8.8 выпадет из процесса маршрутизации и его место займет следующий дефолтный маршрут по дистанции.

Часто слышу вопрос, а как сделать так, чтобы можно сделать через PPPoE рекурсивный маршрут? Тут всё дело в понимании, как таковой адрес шлюза не используется, кроме как в ethernet сетях, так как в ethernet нам нужен его mac адрес, в любых типах инкапсуляции в том числе и PPPoE адрес шлюза не используется, в виду того, что маршрутизатору просто надо запихнуть пакет в другой протокол и отправить на другую сторону.

Естественно мы можем этим воспользоваться.

Создайте отдельный PPP Profile и укажите абсолютно любой IP адрес в поле remote-address, главное чтобы этот адрес не пересекался с вашими внутренними сетями. Далее укажите этот профиль в настройках вашего PPPoE клиента, и вы можете использовать указанный адрес в поле remote-address, как адрес шлюза, для настройки рекурсивной маршрутизации.

Источник

Портал agro-sss.ru

Pref source mikrotik что это

Preferred source