VPN:IPIP
В статье разбирается настройка IPIP-туннеля на оборудовании MikroTik с целью объединения двух сетей (site-to-site VPN). После создания VPN-канала между сетями будет настроена маршрутизация и выполнена проверка работоспособности. Также будут разобраны типичные проблемы, которые могут возникнуть в процессе настройки и проверки.
Введение
IP in IP — это протокол IP-туннелирования, который инкапсулирует один IP-пакет в другой IP-пакет. Инкапсуляция одного IP пакета в другой IP пакет, это добавление внешнего заголовка с SourceIP — точкой входа в туннель, и Destination — точкой выхода из туннеля. При этом внутренний пакет не был изменен (кроме поля TTL, которое уменьшилось). Поля Don’t Fragment и The Type of Service должны быть скопированы в внешний пакет. Если размер пакета больше чем Path MTU, пакет фрагментируется в инкапсуляторе, это должно быть во внешнем заголовке. Декапсулятор должен будет собрать пакет. Многие маршрутизатора, включая Cisco и Linux-based, поддерживают этот протокол.
Полезные материалы по MikroTik
Схема сети
В головном офисе установлен маршрутизатор GW1. В филиале установлен маршрутизатор GW2.
Головной офис
IP-адрес внешней сети головного офиса: 10.1.100.0/24
IP-адрес внешнего интерфейса маршрутизатора GW1: 10.1.100.1/24
IP-адрес внутренней сети головного офиса: 192.168.15.0/24
IP-адрес внутреннего интерфейса маршрутизатора GW2: 192.168.15.1/24
Филиал
IP-адрес внешней сети головного офиса: 10.1.200.1/24
IP-адрес внешнего интерфейса маршрутизатора GW1: 10.1.200.1/24
IP-адрес внутренней сети головного офиса: 192.168.25.0/24
IP-адрес внутреннего интерфейса маршрутизатора GW2: 192.168.25.1/24
VPN-канал
IP-адрес VPN-сети: 172.16.30.0/30
IP-адрес VPN-интерфейса маршрутизатора GW1: 172.16.30.1/30
IP-адрес VPN-интерфейса маршрутизатора GW2: 172.16.30.2/30
Настройка
Настройка первого маршрутизатора
Через графический интерфейс
Первым делом надо создать IPIP-туннель.
Далее надо назначить IP-адрес IPIP-туннелю, созданному на предыдущем шаге.
Через консоль
/interface ipip
add name=filial1 keepalive=10s,10 local-address=10.1.100.1 remote-address=10.1.200.1
/ip address
add address=172.16.30.1/30 interface=filial1
Настройка второго маршрутизатора
Через графический интерфейс
Далее надо назначить IP-адрес IPIP-туннелю, созданному на предыдущем шаге.
Через консоль
/interface ipip
add name=HQ keepalive=10s,10 local-address=10.1.200.1 remote-address=10.1.100.1
/ip address
add address=172.16.30.2/30 interface=HQ
Настройка маршрутизации
Если на предыдущих шагах все было сделано верно, то VPN-соединение между двумя офисами было установлено, но для того, что бы обе сети могли обмениваться информацией друг с другом они должны знать друг о друге, т. е. между ними должна быть настроена маршрутизация. Для этого надо выполнить следующие шаги:
На первом маршрутизаторе
Через графический интерфейс
Выполнить следующие настройки:
Dst. Address: 192.168.25.0/24 (адрес сети к которой указываем маршрут)
Gateway: 172.16.30.2 (интерфейс через который можно «добраться» до сети)
Pref. Source: 192.168.15.1 (интерфейс с которого будут идти запросы к сети)
Комментарий указать по нажатию кнопки «Comment» (не обязательно)
Через консоль
/ip route
add comment=»route to filial1 through VPN» dst-address=192.168.25.0/24 gateway=172.16.30.2 pref-src=192.168.15.1
На втором маршрутизаторе
Через графический интерфейс
Выполнить следующие настройки:
Dst. Address: 192.168.15.0/24 (адрес сети к которой указываем маршрут)
Gateway: 172.16.30.1 (интерфейс через который можно «добраться» до сети)
Pref. Source: 192.168.25.1 (интерфейс с которого будут идти запросы к сети)
Комментарий указать по нажатию кнопки «Comment» (не обязательно)
Через консоль
/ip route
add comment=»route to HQ through VPN» dst-address=192.168.15.0/24 gateway=172.16.30.1 pref-src=192.168.25.1
HQ — это аббревиатура от headquarter, что в переводе означает головной офис.
Следует учесть
Проверка
Проверка состоит из двух частей:
- Надо убедиться, что между двумя маршрутизаторами MikroTik установлено VPN-соединение. Это описано ниже.
- Если VPN-соединение установлено успешно, то далее надо проверить есть ли связь между хостами в двух сетях. Для этого достаточно запустить ping с любого компьютера в сети на любой компьютер другой сети.
Через графический интерфейс
Если подключение установлено, то статус подключения должен отображаться с буквой «R«. Что значит running, т. е. запущено.
Через консоль
На обоих маршрутизаторах выполнить команду /interface ipip print
Если соединение установлено успешно, то статус подключения, так же, как и через графический интерфейс, должен отображаться с буквой «R«.
Инструкции по настройке MikroTik
Когда нужно применять статическую маршрутизацию в MikroTik
Любая корпоративная сеть, как правило состоит из многоуровневой коммутации как на уровне самого роутера, так и во внешних сервисах. В качестве примера будет сформирован список случаев, когда актуально обратиться к настройке статического маршрута(route) на маршрутизаторе(роутере) MikroTik:
- При добавлении статического адреса на какой-либо интерфейс. Это может быть как интернет соединение(ppoe, dhcp client, static address), так и обычная локальная настройка интерфейса в MikroTik.
- Для обмена данным связки L2TP\PPTP VPN сервера и узлами, которые находятся ЗА VPN клиентом. Эта частая связка, когда в качестве VPN клиента выступает не конечный узел, а установлен маршрутизатор(роутер), за которым может быть множество узлов(при объединении двух офисов).
- При использовании нескольких провайдеров и создании различных правил по балансировки нагрузке или автопереключению(резервированию) интернета.
- Когда нужно разделить узлы локальной сети на группы, каждая их которых будет использовать разные правила для выхода в интернет.
- Индивидуальные случаи, когда нужно задать предопределенное правило движение трафика для узла, которое не создаётся автоматически.
Нужно настроить статическую маршрутизацию MikroTik?
Мы поможем настроить: маршрутизатор(роутер), точку доступа или коммутатор.
Как настроить “static routing” в MikroTik
Будет рассмотрена запись статического маршрута, с детальным описанием рабочих параметров.
Настройка находится IP→Routes
Dst. Address – конечный адресат, популярные значения
- 0.0.0.0/0 – интернет;
- 192.168.0.0/24 – подсеть;
- 192.168.0.50 – конечный узёл;
Gateway – шлюз, которому будет отправлен пакет.
Check Gateway – проверка доступности шлюза:
- arp – по наличию записи в таблице ARP;
- ping – посредством отправки icmp запросов.
Этот пункт позволяет произвести точное определение не доступности шлюза и является рекомендованным, при использовании автоматического переключения линии интернета.
Type – маршруты, которые не указывают nexthop для пакетов, но вместо этого выполняют некоторые другие действия с пакетами, имеют тип, отличный от обычного unicast(одноадресного). Маршрут blackhole(черная дыра) молча отбрасывает пакеты, в то время как маршруты, unreachable(недоступные) и prohibit(запрещающие), отправляют сообщение ICMP Destination Unreachable (код 1 и 13 соответственно) на адрес источника пакета.
Distance – определение приоритета заданного маршрута. Чем ниже число, те выше приоритет.
Scope\Target Scope – параметры рекурсивной маршрутизации, состоящей из этапов:
- Маршрут ищет интерфейс для отправки пакета исходя из своего значения scope и всех записей в таблице main с меньшими или равными значениями target scope
- Из найденных интерфейсов выбирается тот, через который можно отправить пакет указанному шлюзу
- Интерфейс найденной connected записи выбирается для отправки пакета на шлюз
Больше информации по использованию параметров ааа можно найти в соответствующем руководстве “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 v6
Я настоятельно рекомендую сначала прочитать, далее вникнуть, потом понять и только после того, как у вас вся картина будет нарисована в голове, приступить к настройке.
Настройка нескольких провайдеров в RouterOS.
Основная проблема настройки нескольких провайдеров заключается в том, что мы должны отправить пакет в тот же шлюз, с которого пришёл трафик через провайдера. Если мы этого не сделаем, то в большинстве случаев оператор заблокирует трафик с неправильным source адресом.
Если оператор нам выдал ip адрес 1.1.1.2, то мы должны обеспечить выход через этого провайдера именно с таким ip адресом, а не с каким либо другим.
Не будем ходить вокруг да около, а сразу приступим к настройке.
Для начала определим вводные данные.
- Интерфейс ether1
- IP:88.88.88.2/29 Gateway: 88.88.88.1, а также данный провайдер отдаёт ещё один префикс на том же интерфейсе IP:99.99.99.2/24 Gateway: 99.99.99.1
- DSN сервера 2.2.2.2 и 3.3.3.2
- Интерфейс ether2
- IP:44.44.44.2/29 Gateway: 44.44.44.1
- DSN сервера 7.7.7.2 и 6.6.6.2
- Ether3 — IP:172.20.17.1/24 — локальная сеть компьютеров
- Ether4 — IP:172.20.18.1/24 — локальная сеть для серверов
Настройка IP адресации
Настроим IP адреса, согласно выданным настройкам от провайдера.
Я думаю бессмысленно как-то дополнять данные настройки.
Настройка MikroTik
Закажи настройку MikroTik непосредственно сейчас, поможем в поиске решения по любому кейсу связанному с MikroTik.
Предоставляю гарантию две недели на свою работу, оплата постфактум, работаю как с юридическими, так и физическими лицами.
Маркировка соединений от провайдера
Вы наверное помните, а если и нет, то стоит напомнить, что любой пакет, который приходит на маршрутизатор и попадает в цепочку 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.
На данный момент у нас нет маршрута по умолчанию в таблице маршрутизации main, встаёт вопрос, какой шлюз указать в качестве маршрута по умолчанию, если мы укажем первого провайдера, то в случае падения интерфейса мы останемся у разбитого корыта, мы можем сразу указать три шлюза и с помощью distance указать приоритеты, но тогда мы должны помнить про данную настройку и случае замены провайдера или какого-либо изменения править конфигурацию и в этом моменте, а там то всего нужно пройти выбор маршрута и далее уже переопределить направление, т.е по факту это логический кейс.
Все интерфейсы имеют способность падать, есть один интерфейс, который всегда находится в состоянии UP, но в RouterOS использовать его в конфигурации не представляется возможным — это Loopback.
В RouterOS данный интерфейс можно заменить пустым bridge.
Я часто рассказываю на курсах, почему именно такое название, а не просто Loopback, возможно в ближайшем будущем в RouterOS будет добавлено поддержка Loopback интерфейса и если разработчики заложат такое же название, то при обновлении версии RouterOS могут возникнуть проблемы.
А теперь создадим маршрут в таблице main, который необходим для преодоления выбора маршрута и попадания пакета в цепочку output.
Максимальная дистанция для того, чтобы в случае если мы создадим нормальный маршрут по умолчанию, а не фиктивный, нам данный маршрут не мешал.
Напоминаю, что дистанция 255 это административная дистанция, которая явно указывает на то, что данный маршрут мёртв и не участвует в маршрутизации.
Всё, на данном этапе вы должны иметь возможность подключаться к маршрутизатору по любому IP адресу через любого провайдера одновременно, можете “пинговать” и делать всякие другие непотребства с внешними IP адресами.
Выход с маршрутизатора
Хоть и по сути мы сделали уже много, но у нас ещё несколько кейсов впереди. Теперь мы должны сделать таким образом, чтобы пакеты, которые генерирует сам маршрутизатор (не в ответ), уходили через нужного провайдера и шлюза.
Когда вы “пингуете” с маршрутизатора, строите PPP* или IP туннели с самого маршрутизатора или dns запросы отправляете с самого маршрутизатора. Разница с прошлым кейсом в том, что мы отправляли пакет по уже установленному соединению, а здесь пакет улетает с маршрутизатора и соединение не имеет маркировки.
Здесь будет значительно проще.
Весь трафик, уходящий с маршрутизатора, и имеющий IP адрес попадающий под префикс, будет отправлен в именованную таблицу маршрутизации.
Всё, теперь вы можете строить туннели и у вас всё будет работать, но только в том случае если явно указан IP адрес, например в Ipsec или gre, ip туннели и прочее, там где явно можно указать Source адрес. А что делать с сервисами, где нельзя указать явно IP адрес источника? Ответ на этот вопрос кроется в таблице маршрутизации. Параметр pref-src отвечает за то, какой IP адрес будет выбран если он явно не задан.
Если вам необходимо установить соединение из локальной сети с адресом который назначен на интерфейсе провайдера, допустим при использовании Hairpin-NAT, в правилах вы должны исключить BOGON сети из адресов назначения.
В нашем примере если только для одного IP адреса.
Ещё раз для понимания, у нас есть два варианта развитая сюжета, если IP адрес источника явно указан и тогда нам нечего не грозит и всё замечательно работает. Второй вариант, когда IP адрес явно не задан, например вы подминаете l2tp-client у нас нет возможности указать source адрес, но ведь адрес назначения есть в любом случае. Тогда маршрутизатор поступает следующим образом, он находит маршрут в таблице маршрутизации main, смотрит какой указан pref-src и использует данный ip адрес, как адрес источника.
Вы помните что мы создавали фиктивный маршрут.
Давайте его немного изменим так, чтобы мы определили IP адрес, с которого будет формироваться трафик.
Выбор IP адреса зависит только от вас, выбирайте тот адрес, который считаете менее загруженным.
На этом этапе всё, теперь вы можете строить различные туннели и устанавливать соединения не только указывая явно source адрес.
Доступ за НАТ
172.20.18.2 — это exchange сервер, мы должны обеспечить доступность 25,80,443 портов через каждого провайдера.
НАТ делаем, как обычно, без всяких излишеств.
А теперь давайте вспомним то, что мы делали самым первым правилом в mangle мы промаркировали все соединения, которые приходят через всех провайдеров! Данная маркировка нам опять поможет.
Нам необходимо отфильтровать весь трафик, который идёт из локальной сети и отправить в том направлении к маркировке которого соединение имеет отношение.
Попробуем логически по шагам описать то, как это будет работать. Опишем для одного провайдера, для остальных по тоже схеме.
- Когда пакет придёт на IP адрес 88.88.88.2 мы промаркировали соединение, которому принадлежит пакет.
- Далее в NAT мы изменили адрес назначения, и маршрутизатор отправит его до сервера.
- Естественно сервер в ответ отправит пакет, как минимум syn,ack, так как данный пакет принадлежит уже существующему соединению, мы по имени соединению отправим данный пакет в именованную таблицу маршрутизации.
НАТ уже сделали, дело осталось за малым- найти трафик, который приходит от сервера.
Наверное нет смысла описывать, всё предельно понятно, на входе мы промаркировали трафик от провайдеров, и когда пакет снова попал на вход маршрутизатора, но уже пакеты идут от серверов мы отправляем такие пакеты в именованную таблицу маршрутизации.
Наверное многие спросят, а почему указывается не интерфейс ether1, а не взять и указать явно локальный интерфейс, например ether4.
Мы с вами делаем универсальную конфигурацию, если явно указать какой-либо другой интерфейс, значит в случае если у нас будет ещё один NAT, который пойдёт в другой порт, нам необходимо будет добавлять ещё одно аналогичное правило, но уже с другим интерфейсом. А ведь мы можем даже завернуть трафик с помощью NAT вообще на внешние сервера например 1.1.1.1, и что тогда? Единственный интерфейс откуда в цепочке prerouting мы не должны ожидать данный трафик, это трафик с самого провайдера и причём именно с того, с которого он пришёл.
Всё работает, теперь вы можете подключаться в своему серверу по любому IP адресу. Создайте DNS A запись RR и укажите все три внешних IP адреса и всегда ссылайтесь на данную запись.
Ещё каких-то лет 7 назад, DNS RR работал не очень хорошо, в плане того, что приложения зачастую использовали только первый IP адрес, сейчас все изменилось и многие приложения в случае, если не смогут подключиться по одному адресу, будут пытаться подключаться по другому и так далее…
А также source NAT?
Промелькнула такая мысль в голове? Ведь когда пакет от сервера будет уходить через маршрутизатор, нам надо будет подменить его src адрес, на адрес на который он шёл в самом начале. Но мы ничего не сделали для этого.
Нам делать ничего не нужно, если вспомнить что в правило NAT попадает только самый первый пакет, тот на основании которого было создано соединение new, именно поэтому обычно вы видите небольшие значения в счётчиках правила NAT.
Обратное преобразования NAT произойдёт автоматически, давайте взглянем на запись в conntrack.
Давайте уберём из вывода лишнее, чтобы оно нам не мешало.
И так когда пакет попал на маршрутизатор и соединение было “только-только” создано, соединение имело такой вид
После того как произошла процедура 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 сети, это список сетей, которые никогда не должны использоваться для публикации между public AS в протоколе BGP, другими словами это все те сети, которые используются исключительно в локальных целях.
Создадим адрес лист с BOGON сетями.
А далее создадим правила для того, чтобы выпустить хосты с определённого IP адреса.
Если пакет в адресе источника находится адрес, который перечислен в адрес листе и при этом адрес назначения не попадает под BOGON листы (т.е трафик в интернет), отправить в именованную таблицу.
И последний нюанс-это настроить NAT.
Обратите внимание, что не весь трафик, а только тот, который находится в определённом маркированном маршруте, это необходимо для того, чтобы трафик между локальными сетями не попадал под NAT правило.
Выпускаем всех остальных и балансируем нагрузку.
Осталось дело за малым, выпустить всех остальных в интернет и постараться распределить нагрузку. Оговорю сразу мы не можем распределить нагрузку по пакетно, нам мешает то, что провайдеры не пропустят трафик с другими IP адресами через свою сеть. Поэтому будем балансировать соединениями. Да, мы не получим суммарную пропускную способность на одно соединение всех провайдеров, но это лучшее, что мы можем сделать в данном случае.
Мы будем использовать ECMP для того, чтобы распределить нагрузку по провайдерам.
Наверное вы уже догадались, что весь оставшийся трафик от ваших локальных хостов будет попадать в таблицу main.
Давайте сделаем маршрут ECMP с тем учётом, что шлюз 88.88.88.1 это 10Mbps, а 44.44.44.1 5Mbps.
Пакеты будут отправляться поочередно для каждого шлюза, на каждые 3 пакета, 2 пакету будут отправлены в 88.88.88.1 и оставшийся один пакет на шлюз 44.44.44.1.
Хотя это немного и не правильно, дело в том, что у процесса ECMP есть отдельная таблица кеша, и чтобы каждый раз не выбирать маршрут, маршрутизатор для связки src-address:port dst-address:port создаёт хеш и выберет для данного хеша уже шлюз по схеме Round Robin, тем самым для одного соединения будет выбираться один и тот же шлюз.
Но не все так однозначно, каждый раз, когда вы изменили маршрут, например добавили шлюз или шлюз умер то кеш ECMP чистится, а также каждые 10 минут всё также чистится кеш, отсюда появляется проблема, что каждые 10 минут может выбраться другой шлюз. И снова для каждого уникального хеша будет выбираться маршрут.
На ресурсах, которые используют привязку сессии авторизации к IP адресу, вы получите проблему в виде запроса логина и пароля, например mail.ru будет у вас запрашивать пароль при смене ip адреса.
Проблема в том, что ограничение в 10 минут, это ограничение жёсткое и нам его не убрать и не изменить.
Будем решать штатными средствами RouterOS.
Давайте подумаем вместе, что нам известно о пакете, который попал под ECMP маршрут? Конечно, данный пакет находится в таблице main.
Идея данного способа заключается в следующем. Дать маршрутизатору выбрать маршрут с помощью ECMP, промаркировать такие соединения и все последующие пакеты в этом соединение пускать мимо ECMP, тем самым мы убираем проблему 10 минут.
chain=postrouting — Работаем в цепочке по факту того, что уже выбрал ECMP, можно использовать и цепочку forward, но тогда не попадёт трафик который был сгенерирован самим маршрутизатором.
routing-table=main — Маршрут ECMP находиться в main таблице.
out-interface=ether1 — ECMP выбрал шлюз, который лежит через первый интерфейс
connection-state=new — Мы маркируем соединение, нет смысла работать со всеми пакетами.
action=mark-connection new-connection-mark=ECMP/ether1 — маркируем соединение.
Ещё раз, мы дали возможность ECMP выбрать направление и мы уже по факту промаркировали соединения, основываясь на выборе интерфейса.
А теперь все последующие пакеты в соединениях с такой маркировкой должны быть отправлены в тот же интерфейс, но не в таблицу main, так как там работает ECMP, нам это уже не к чему.
Не забудьте, что трафик смотрится со всех сторон, а нам необходимо только трафик из локальной сети, а так как интерфейсов может быть много, лучше всего отфильтровывать по принципу весь трафик КРОМЕ того который пришёл с интерфейса провайдера.
Осталось настроить NAT
За сим всё, спасибо за внимание.
Удалённая настройка маршрутизатора, к дальней дороге.
VPN: L2TP site-to-site (объединение офисов через ВПН на Mikrotik)
Статья взята здесь http://mikrotik.vetriks.ru/wiki/VPN:L2TP_site-to-site_(объединение_офисов) . Взята, потому что хороша и самодостаточна, коротка, проста и понятна. У нас уже есть пошаговая инструкция по объединению сетей через VPN L2TP с IPSec, но она немного громоздкая и может показаться чересчур подробной. А здесь описан быстрый и простой способ. Короче, спасибо ребятам из vetrix.ru.
В головном офисе установлен маршрутизатор GW1. Он же будет настроен в качестве VPN-сервера. В филиале установлен маршрутизатор GW2, который будет настроен как VPN-клиент.
Головной офис
IP-адрес внешней сети головного офиса: 10.1.100.0/24
IP-адрес внешнего интерфейса маршрутизатора GW1: 10.1.100.1/24
IP-адрес внутренней сети головного офиса: 192.168.15.0/24
IP-адрес внутреннего интерфейса маршрутизатора GW2: 192.168.15.1/24
Филиал
IP-адрес внешней сети головного офиса: 10.1.200.0/24
IP-адрес внешнего интерфейса маршрутизатора GW1: 10.1.200.1/24
IP-адрес внутренней сети головного офиса: 192.168.25.0/24
IP-адрес внутреннего интерфейса маршрутизатора GW2: 192.168.25.1/24
VPN-канал
IP-адрес VPN-интерфейса маршрутизатора GW1: 172.16.30.1/32
IP-адрес VPN-интерфейса маршрутизатора GW2: 172.16.30.2/32
Настройка
Настройка первого маршрутизатора
Через графический интерфейс
Включить L2TP-сервер. Не смотря на то, что L2TP не несет в себе нормального шифрования, лучше оставить только аутентификацию «mschap2» как наиболее надежную.
Создать новый аккаунт. Для дальнейшего удобства лучше задавать имена так, что бы сразу можно было определить к кому или чему они относятся. Т. е. имена типа user1, user2, user3 и т. д. не желательны в виду того, что в случае увеличения их количества будет тяжело сопоставить реальных пользователей аккаунтов и сами аккаунты.
Создать статическую запись L2TP сервера. Это действие не обязательно, т. к. если запись не создать вручную, то при каждом подключении она будет создаваться динамически. Но при этом наличие этой записи облегчает дальнейшую настройку и диагностику.
Через консоль
Настройка второго маршрутизатора
Через графический интерфейс
Создать интерфейс для подключения к первому маршрутизатору. Здесь так же оставляем только аутентификацию «mschap2«.
Через консоль
Настройка маршрутизации
Если на предыдущих шагах все было сделано верно, то VPN-соединение между двумя офисами было установлено, но для того, что бы обе сети могли обмениваться информацией друг с другом они должны знать друг о друге, т. е. между ними должна быть настроена маршрутизация. Для этого надо выполнить следующие шаги:
На первом маршрутизаторе
Через графический интерфейс
Выполнить следующие настройки:
Dst. Address: 192.168.25.0/24 (адрес сети к которой указываем маршрут)
Gateway: 172.16.30.2 (интерфейс через который можно «добраться» до сети)
Pref. Source: 192.168.15.1 (интерфейс с которого будут идти запросы к сети)
Комментарий указать по нажатию кнопки «Comment» (не обязательно)
Через консоль
На втором маршрутизаторе
Через графический интерфейс
Выполнить следующие настройки:
Dst. Address: 192.168.15.0/24 (адрес сети к которой указываем маршрут)
Gateway: 172.16.30.1 (интерфейс через который можно «добраться» до сети)
Pref. Source: 192.168.25.1 (интерфейс с которого будут идти запросы к сети)
Комментарий указать по нажатию кнопки «Comment» (не обязательно)
Через консоль
HQ — это аббревиатура от headquarter, что в переводе означает головной офис.
Примечание: Параметр Pref. Source (pref-src) не является обязательным. Он становится нужен, если количество филиалов будет более одного. Без этого параметра не будут проходить ping’и с маршрутизатора одного филиала до хостов и внутреннего интерфейса маршрутизатора другого филиала. Не будут проходить ping’и именно с маршрутизаторов, т. е. между хостами двух филиалов связь будет.
Проверка
Проверка состоит из двух частей:
- Надо убедиться, что между двумя маршрутизаторами MikroTik установлено VPN-соединение. Это описано ниже.
- Если VPN-соединение установлено успешно, то далее надо проверить есть ли связь между хостами в двух сетях. Для этого достаточно запустить ping с любого компьютера в сети на любой компьютер другой сети.
Через графический интерфейс
Если подключение установлено, то статус подключения должен отображаться с буквой «R«. Что значит running, т. е. запущено.
Через консоль
Выполнить команду
/interface l2tp-server print — на сервере
/interface l2tp-client print — на клиенте
Если соединение установлено успешно, то статус подключения, так же, как и через графический интерфейс, должен отображаться с буквой «R«.