Конфигурация IP-адресации

Произведем настройку IP-адресов в соответствии с параметрами, предоставленными провайдером

Мы считаем, что нет смысла вносить какие-либо дополнения в эти настройки.

Тегирование соединений от провайдера

Возможно, вы помните, но если и нет, мы напомним, что каждый пакет, который достигает маршрутизатора и попадает в цепочку prerouting, может далее направиться в forward или Input.

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

Давайте сначала выполним настройку, а затем обсудим, что было сделано.

Давайте разберемся с первым правилом, все последующие аналогичны.

Если пакет приходит на интерфейс ether1 и его адрес назначения находится в сети 88.88.88.0/29, и данный пакет инициировал соединение, то мы маркируем это соединение меткой Next-Hop/88.88.88.1.

Примечание:

88.88.88.0/29 — почему используем диапазон адресов, а не конкретный IP? Если бы мы начали создавать правила для каждого IP-адреса, количество этих правил быстро бы возросло, при этом общий смысл остался бы прежним.

connection-state=new — не имеет смысла маркировать уже установленные соединения. Как вы помните, состояние «new» означает пакет, инициировавший соединение, и таких пакетов всего один. Если бы мы применяли это к каждому пакету, RouterOS пытался бы постоянно маркировать соединение, которое уже могло бы быть помечено.

Next-Hop/99.99.99.1 — почему мы выбрали именно это? Наша основная задача — отправлять трафик через тот же шлюз, с которого он пришел. Этот ярлык является напоминанием о том, какой шлюз будет использоваться для отправки трафика провайдеру. Мы могли бы использовать что-то вроде ISP1, но у нашего первого провайдера два префикса на одном интерфейсе. Трафик, приходящий на разные префиксы, нужно каким-то образом различать.

Итак, это наш базовый шаблон. Далее мы приступим к разработке логики.

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

Доступность маршрутизатора

Первым шагом, который нам предстоит сделать, это обеспечить доступ к управлению маршрутизатором с использованием различных провайдеров. Мы хотим обеспечить возможность подключения через любой IP-адрес с помощью ssh, winbox, и, если вы планируете использовать RouterOS в качестве VPN-сервера, то и к нему. В основном нам нужно настроить правильное направление пакетов, которые будут отправлены с маршрутизатора в ответ на входящие запросы.

Начнем с организации корректных таблиц маршрутизации. В одной таблице маршрутизации не может быть два одинаковых активных маршрута одновременно. Если маршруты совпадают, приоритет определяется значением distance. Чтобы использовать несколько идентичных маршрутов, RouterOS предлагает возможность создавать дополнительные (именованные) таблицы маршрутизации.

Давайте создадим эти таблицы

Давайте разберёмся

dst-address=0.0.0.0/0 — это стандартный маршрут по умолчанию.

gateway=88.88.88.1 — указывает на шлюз. Следует учесть, что наш первый провайдер предоставляет два префикса с разными шлюзами. В итоге у нас формируется три маршрута, и фактически у нас три разных провайдера, а не два.

routing-mark=Next-Hop/88.88.88.1 — это именованная таблица маршрутизации. Её имя может быть любым. На наш взгляд, удобно использовать в названии таблицы шлюз, через который будет направлен пакет при выборе данного маршрута. Важно понимать, что названия маркировок соединений и маршрутов могут различаться.

Мы обратили внимание на то, что речь шла о таблицах и маркировках. Маркировка маршрута не всегда является таблицей, хотя во многих контекстах так оно и выглядит. Возникает вопрос: в чём разница в правилах между двумя фильтрами в firewall?

Фактически, routing-mark — это метка, которую мы вручную устанавливаем на пакет с использованием mangle, тогда как routing-table указывает, через какую таблицу маршрутизации прошел пакет.

Если маршрутизатор не обнаруживает подходящего маршрута в заданной таблице маршрутизации, он продолжает поиск в основной таблице по умолчанию (main). В таких ситуациях возможно фильтровать пакеты, используя, например, routing-mark=custommark и routing-table=main. Однако такой подход нам не подходит: если подходящий маршрут отсутствует, пакет должен быть «упущен» маршрутизатором, поскольку пересылка через другого провайдера не имеет смысла.

Для изменения этого поведения нам нужно внести коррективы

Таким образом, мы убеждаемся, что пакеты, имеющие определённую маркировку (routing-mark), будут искать маршруты только в соответствующей таблице маршрутизации, предотвращая тем самым их нежелательную пересылку.

Оставшийся шаг — направить нужный трафик в соответствующую маркировку.

Мы используем цепочку output, так как работаем только с трафиком, генерируемым в ответ на запрос соединения. Мы выбираем пакеты, которые соответствуют определённым соединениям, и направляем их в именованную таблицу.

Хотя все может показаться корректно настроенным, в RouterOS есть особенность, которую следует учитывать. Перед отправкой пакета в цепочку output, маршрутизатор сначала обращается к основной таблице маршрутизации (main) и ищет подходящий маршрут для адреса назначения. Только три службы могут функционировать за пределами этой логики: ping, traceroute и ospf, что требуется для работы с VRF.

На данный момент в нашей основной таблице маршрутизации нет маршрута по умолчанию. Возникает вопрос: какой шлюз выбрать? Если мы выберем первого провайдера и его интерфейс упадет, то сетевое соединение будет потеряно. Мы можем установить все три шлюза с разным приоритетом используя параметр distance. Но при этом, при замене провайдера или других изменениях, нам придется редактировать конфигурацию. Логичнее было бы сначала осуществить выбор маршрута, а затем перенаправить трафик.

Все интерфейсы могут иметь проблемы. Однако есть один интерфейс, который всегда активен, но его использование в RouterOS не возможно — это Loopback.

Настройка выходного соединения с маршрутизатором

Хотя мы уже проделали немало работы, перед нами ещё несколько задач. Теперь наша цель — настроить маршрутизатор так, чтобы пакеты, генерируемые самим маршрутизатором (не в ответ на другие пакеты), направлялись через нужного нам провайдера и через нужный шлюз.

Рассмотрим ситуацию, когда мы отправляем «пинг» с маршрутизатора, создаём PPP* или IP туннели с устройства или отправляем DNS-запросы непосредственно с маршрутизатора. В отличие от предыдущей задачи, где пакеты направлялись по уже установленным соединениям, в этом случае пакеты отправляются с маршрутизатора, и соединение не маркировано.

Процесс настройки здесь будет гораздо проще

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

Теперь мы можем создавать туннели, и все будет работать корректно, но только при условии явного указания IP-адреса, например, в IPsec, GRE, IP-туннелях и так далее, где можно явно указать адрес источника. Но что делать с сервисами, в которых явное указание IP-адреса источника невозможно? Ответ кроется в таблице маршрутизации. Параметр pref-src определяет, какой IP-адрес будет выбран, если он явно не задан.

Если требуется установить соединение из локальной сети с адресом, присвоенным интерфейсу провайдера, например при использовании Hairpin-NAT, необходимо в правилах исключить BOGON-сети из адресов назначения.

В нашем примере это делается для одного IP-адреса

Важно понимать, что у нас есть два сценария: когда IP-адрес источника указан явно и всё работает отлично, и когда IP-адрес явно не задан, как, например, при настройке L2TP-client. В этом случае маршрутизатор ищет маршрут в основной таблице маршрутизации, проверяет параметр pref-src и использует соответствующий IP-адрес в качестве адреса источника.

Напомним, что мы создали фиктивный маршрут

Давайте модифицируем его так, чтобы определить IP-адрес для генерации трафика

Выбор IP-адреса зависит от вас. Выберите адрес, который, на ваш взгляд, будет менее загруженным.

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

Доступ через NAT

172.20.18.2 — это наш exchange сервер, и мы должны обеспечить доступность портов 25,80,443 через каждого провайдера.

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

Помните, как первым правилом в mangle мы маркировали все соединения, приходящие от всех провайдеров? Эта маркировка снова нам пригодится.

Нам необходимо отфильтровать весь трафик, идущий из нашей локальной сети, и направить его в соответствие с маркировкой соединения.

Рассмотрим логический порядок действий для одного провайдера, для остальных схема аналогична:

1. Когда пакет приходит на IP адрес 88.88.88.2, мы маркируем соответствующее соединение
2. Затем, в NAT, меняем адрес назначения, и маршрутизатор перенаправляет его к серверу
3. В ответ сервер отправляет пакет, минимум syn,ack. Так как этот пакет относится к уже существующему соединению, мы на основании этой маркировки направляем пакет в именованную таблицу маршрутизации

После настройки NAT нам нужно обработать трафик, исходящий от сервера.

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

Многие могут задаться вопросом, почему мы указываем не интерфейс ether1. Ответ прост: мы создаем универсальную конфигурацию. Указывая конкретный интерфейс, при добавлении нового NAT, потребуется добавить аналогичное правило с новым интерфейсом.

Теперь вы можете подключиться к вашему серверу по любому из IP-адресов. Создайте DNS A запись RR, указав все три внешних IP-адреса, и всегда обращайтесь к этой записи.

Пример: mail.ourcompany.ru

1. mail.ourcompany.ru A 88.88.88.2
2. mail.ourcompany.ru A 99.99.99.2
3. mail.ourcompany.ru A 44.44.44.2

Ещё лет 7 назад DNS RR работал не совсем корректно. Тогда приложения часто использовали только первый IP-адрес. Однако ситуация изменилась, и теперь многие приложения будут пытаться подключиться к другому адресу, если первый недоступен, и так далее.

А также source NAT

Возникла такая мысль: когда пакет от сервера будет уходить через маршрутизатор, нам нужно будет подменить его src адрес, на адрес, на который он шёл изначально. Однако, мы не проводили каких-либо настроек для этого.

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

Обратное преобразование NAT будет производиться автоматически. Давайте рассмотрим запись в conntrack:

Давайте уберём из вывода лишний шум:

На основании правил dst-NAT, src NAT в данном случае будет работать автоматически.

Когда пакет достиг маршрутизатора и соединение было только создано, соединение выглядело следующим образом:

После того как у нас произошла процедура dst NAT, маршрутизатор добавил флаги и указал, на какой адрес будет меняться IP-адрес во всех пакетах этого соединения:

Когда пакет направлялся через маршрутизатор в цепочки postrouting, активировалась процедура src NAT. Однако у нас не было установленных правил для src NAT, поэтому исходное значение было сохранено:

Стоит отметить, что все эти этапы проходили только при обработке первого пакета.

Теперь, если пакет приходит на маршрутизатор с заголовками src-address=5.19.245.3:57839 и dst-address=88.88.88.2:80, dst-address изменится на 172.20.18.2:80.

Если же пакет приходит на маршрутизатор с адресами в заголовках src-address=172.20.18.2:80 и dst-address=5.19.245.3:57839, src-адрес заменится на 88.88.88.2:80.

Таким образом, src NAT на этом этапе работает автоматически на основе правил dst-NAT.

Отправить с корректного адреса

Часто сталкиваются с ситуациями, когда необходимо строго определить, чтобы определённые внутренние хосты имели доступ только с конкретного IP-адреса.

Допустим, при использовании VoIP телефонии, провайдер требует регистрацию именно с определённого IP, или приложение банка на рабочей станции главного бухгалтера требует подключение с конкретного адреса.

Сначала настраивают списки адресов, куда добавляют внутренние адреса хостов, которым требуется выход через определённого провайдера и с конкретного IP.

Адрес 0.0.0.1 используется для создания списка без привязки к реальному адресу. Название списка является показателем, какой именно IP-адрес источника требуется использовать.

Реализация данного кейса требует понимания некоторых особенностей работы RouterOS.

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

Не получится направить весь трафик от внутреннего хоста к определённому провайдеру, так как есть также локальная сеть. Если добавить хост 172.20.17.100 и направить весь его трафик к первому провайдеру, то трафик, направленный на хост 172.20.18.2, также будет направлен туда.

Чтобы решить эту проблему, используются BOGON-сети — это сети, которые не должны публиковаться между публичными AS в протоколе BGP. В других словах, это те сети, которые используются только в локальных целях.

Мы решили составить список адресов, содержащий BOGON-сети.

Далее мы установим ряд правил для обеспечения того, чтобы хосты выходили с конкретного IP-адреса.

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

Теперь переходим к последнему этапу — настройке NAT.

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

Распределение трафика и балансировка нагрузки для всех пользователей

Мы почти завершили, и теперь перед нами стоит задача дать доступ всем оставшимся пользователям в интернет и оптимально распределить нагрузку. Сразу отметим, что пакетное распределение нагрузки невозможно из-за ограничений провайдеров, которые не пропускают трафик с чужими IP-адресами. Вместо этого мы сфокусируемся на балансировке соединений. Хоть и невозможно суммировать пропускную способность всех соединений, это лучший вариант в наших условиях.

Мы решили использовать ECMP (Equal Cost Multi Path) для балансировки нагрузки между провайдерами.

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

Учитывая, что шлюз 88.88.88.1 обладает скоростью 10Mbps, а 44.44.44.1 — 5Mbps, наш маршрут ECMP будет выглядеть следующим образом:

Это означает, что из каждых трёх пакетов, два будут направлены через 88.88.88.1, а один через 44.44.44.1.

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

Проблема в том, что 10-минутное ограничение кэша зашито в систему и не может быть изменено. Но мы нашли решение.

Мы решили дать маршрутизатору выбрать маршрут с помощью ECMP, пометить такие соединения и все последующие пакеты этого соединения обрабатывать вне ECMP. Таким образом, мы обходим ограничение в 10 минут и улучшаем стабильность соединения.

Приступим

Давайте проанализируем.

chain=postrouting — Мы работаем в цепочке после того, как ECMP сделал свой выбор. Это можно сделать и в цепочке forward, но тогда трафик, сгенерированный самим маршрутизатором, не будет учитываться.

routing-table=main — Наш маршрут ECMP находится в главной таблице.

out-interface=ether1 — ECMP определил маршрут через первый интерфейс.

connection-state=new — Мы ставим маркер только на новые соединения, так как нет необходимости обрабатывать все пакеты.

action=mark-connection new-connection-mark=ECMP/ether1 — мы ставим метку на соединение.

В общем, мы позволили ECMP определить маршрут, а затем поставили метку на соединения, основываясь на выбранном интерфейсе.

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

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

Почти готово.

Теперь давайте настроим NAT:

С этим мы завершили. Благодарим за ваше внимание!