Приветствую!
Столкнулся с проблемой при попытке связать 2 офиса посредством IPSec-туннеля.
Что сделал:

HQ (192.168.1.0/24).

Роуты:
0.0.0.0/0 -> гейт провайдера
192.168.2.0/24 -> внешний интерфейс рутера филиала.

Фаеруолл:
Настроен маскарадинг всех пакетов во внутр. сеть филиала (должен присваиваться IP внешн. интерфейса).
Весь трафик между внутренними сетями разрешен.


Филиал (192.168.2.0/24).

Роуты:
0.0.0.0/0 -> гейт провайдера
192.168.1.0/24 -> внешний интерфейса рутера в HQ

Фаеруолл:
Настроен маскарадинг всех пакетов во внутр. сеть HQ (должен присваиваться IP внешн. интерфейса).
Весь трафик между внутренними сетями разрешен.


Что получилось:
IPSec туннель ставится без проблем, но пакеты во внутренние удаленные сети в тоннель не попадают.
Вместо этого они отправляются рутером на шлюз провайдера, где и гибнут.

Что я делаю не так?

Напишите подробно, какие ip адреса и на каких интерфейсах + статическая маршрутизация, так будет проще разобраться

Здравстуйте!

Эмм... Что-то я немного недопонимаю. Во-первых причем тут протокол пойнт-ту-пойнт? Я использую IPSec. В интерфейсах туннель IPSec вообще отсутствует, как, впрочем и еще где бы то ни было. Я понимаю лишь с помощью трассировки, что туннель установлен успешно (первый же узел - удаленный роутер).
Как я понял из Ваших рекомендаций мне нужно маскарадить Destination IP? Я честно говоря не очень понимаю все механику процесса... У меня был опыт подобных решений реализованных на HP 7100 dl.
Там все было понятно - роутер, увидев пакет с назначением во внутреннюю удаленную сеть, пришедший на внутренний интерфейс локального роутера, шифровал его с помощью IPSeс, и отправлял удаленному роутеру, взяв адрес роутера из таблицы машрутизации. В заголовке UDP-пакета стоял публичный адрес удаленного роутера. Т.о. роутеры по пути следования пакетов обрабатывали его безо всяких проблем. Естественно все это безобразие использовало технологию NAT-T.
Теперь что касается Mirkotik:
1. Не вижу NAT-T вообще
2. Не могу пока что уяснить, какой IP-адрес светится в заголовке шифрованного UDP пакета. Есть подозрение, что адрес внутренних сетей.
3. При маскарадинге адресов назначения или исходного адреса пакет, как я понимаю, не принимается удаленным роутером, т.к. роутер видит, что пакет бы изменен.
4. Не могу понять, где я могу увидеть установленные IPSec туннели. В Peers ничего не видно.

Теперь интерфейсы и IP-адреса.

HQ

Внутренний интерфейс - 192.168.1.1/24
Внешний интерфейс - 81.211.xxx.254/30

Статич. маршруты

0.0.0.0/0 -> 81.211.xxx.253 метрика 1
192.168.2.0/24 -> 81.13.xxx.134 метрика 1

Branch

Внутренний интерфейс - 192.168.2.1/24
Внешний интерфейс - 81.13.xxx.134/30

Статич. маршруты

0.0.0.0/0 -> 81.13.xxx.133
192.168.1.0/24 -> 81.211.xxx.254

Настройки IPSec - требовать шифрование всего трафика 81.13.xxx.134 <-> 81.211.xxx.254

Как я понимаю, этого набора должно быть достаточно, чтобы пакеты во внутренние сети шифровались. А они не шифруются...

немного непонял из прошлого поста ТЗ, вот пример построения сети через IP Sec

Нажмите для просмотра прикрепленного файла

Mikrotik 1 и Mikrotik 2 расположены разных сетях и являются граничными маршрутизаторами. Схема предусматривает, что они имеют внешние IP-адреса или имеют любой другой способ подключения друг кдругу. Сеть 192.168.5.0, адреса 192.168.5.1 и 192.168.5.2 являются виртуальными, т.е. созданными в результате поднятия туннеля между маршрутизаторами.

Описание IPSec

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

Все протоколы IPSec делятся на два типа:
протоколы шифрования и формирования шифрованного потока;
протоколы обмена ключами.

К протоколам первого типа относятся ESP (Encapsulating Security Payload — инкапсуляция зашифрованных данных) и АН (Authentication Header — аутентифицирующий заголовок). Стоит отметить, что AH не подразумевает обеспечения конфиденциальности передаваемых данных и отвечает только за проверку их целостности.

К протоколам второго типа относится только один существующий на данный момент – IKE (Internet Key Exchange). Данный протокол обычно используется в двух случаях:
передаваемый трафик попал под какое-либо правило, по которому он должен быть зашифрован и у клиента нет данных для его шифрования (Security Associations SA). В этом случае он отправляет запрос на получение ключа своему оппоненту;
клиент получил запрос на получение ключа и должен ответить вызывающей стороне.

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

Транспортный режим подразумевает шифрование только блока транспортных данных IP пакета.

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

В ситуации когда IPSec пакеты сгенерированы с использованием AH (Authentification Header) не достаточно применения технологии NAT. Структура IP пакета, подверженного обработке IPSec протоколом меняется, что делает невозможным его правильное распознавание. Для устранения этой проблемы прибегают к технологии NAT-Traversal, которая инкапсулирует IPSec трафик в UDP пакеты и передаёт их по сети в виде привычного маршрутизируемого сетевого трафика. На принимающей стороне от пакета отбрасывается UDP заголовок и концевик и на стек протокола IPSec поступают полученные данные.

RouterOS Mikrotik имеет следующие средства для работы с IPSec: создание политик для шифрования правил, автоматическую генерацию ключей, ручное создание правил для шифрования трафика, работу как в транспортном режиме, так и в режиме туннелирования, средства мониторинга. Кроме того, в файерволе системы предусмотрен механизм NAT-T, о котором было рассказано выше.

Для создания простейшего транспортного IPSec подключения между двумя маршрутизаторами нужно:

на первом маршрутизаторе выполнить:

на втором маршрутизаторе выполнить:

Также на обоих маршрутизаторах необходимо разрешить используемые протоколами IPSec порты:

Если у вас не возникло никаких трудностей с вышеописанным, откройте статистику и посмотрите шифруются ли пакеты

В случае использования IPSec в туннельном режиме для объединения сетей с адресами 192.168.10.0/24 и 192.168.20.0/24 правила будут выглядеть следующим образом.


и


результате маршрутизаторы 192.168.1.1 и 192.168.1.2 будут обмениваться ключами и создадут безопасный шифрованный туннель между сетями 192.168.20.0 и 192.168.10.0.

Создание Proposals можно сравнить с созданием профилей шифрования. Среди доступных опций предусмотрены:
алгоритмы генерации данных для аутентификации, которые могут принимать значения: md5, sha1, null;
алгоритмы генерации данных для шифрования со значениями: des, 3des, aes-128, aes-192, aes-256, null.

Также возможно указать время жизни профиля в секундах или байтах и способ генерации материала для шифрования из списка предложенного ниже:
modp768;
modp1024;
modp1536;
none.

Профили Proposals используются в качестве опции при создании политик (Policy)

Пример несколько ущербный (простите ). Во-первых там внешние интерфейсы находятся в одной подсети. В реальном мире это практически невозможно. Во-вторых трафик между рутерами не маршрутизируется. А вот если бы он маршрутизировался, то тогда пакеты в частные сети 192.168.xxx.xxx просто бы дропались провайдерами. Однако вернемся к моей ситуации.

В лаборатории все замечательно работало. И пакеты туннелировались. Но как только я попытался поднять то же самое в реальном мире - появились проблемы. Причем проблемы не с IPSec как таковым, а с маршрутизацией пакетов.

На сегодняшний день картина такова - есть IPSec туннель, наличие которого можно определить только трассировкой.

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

Теперь возьмем случай если включить dst-src. Для HQ подменяем адреса назначения исходящего пакета с 192.168.2.1 на адрес 81.13.xxx.134. В этом случае пакет должен достигнуть рутера Branch, но его drop'ает рутер, т.к. пакет изменен.

В фаеруолле сейчас у меня вообще разрешено все.

Общий вопрос - как направить трафик в IPSec туннель, у которого нет своего IP-адреса, и которого нигде не видно?

P.S. "Виртуальные сети" в примере это EoIP, правильно? А EoIP суть есть GRE-туннели?

P.P.S. Вот картинку нарисовал.Нажмите для просмотра прикрепленного файла

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

Если пакеты уходят на шлюз по-умолчанию провайдера, значит роутер незнает маршрута.
т.е. он не добавлен в ip>routes

Чтобы проконтроллировать трафик, есть Tools > Torch

P.S. на ломаной 2.9.27 могут возникнуть проблемы

можно через PPTP построить шифрованный канал с аутентификацией + через EoIP создать прозрачную сетевую среду, эмулирующую прямое Ethernet подключение между сетями

Давайте забудем о PPTP. Мне нужен функционал IPSec

Я правильно понял, что Вы предлагаете поставить сперва GRE-туннель, а затем поверх GRE-туннеля поставить еще и IPSec-туннель? А сколько они отожрут от полосы пропускания? А самое главное - расход процессорного времени! Да и вообще несколько громоздкая система получается. На мой взгляд GRE-туннель в данном случае абсолютно излишняя деталь интерьера Да и в общем, насколько я знаю, GRE-туннели в первую очередь нужны для работы протоколов OSPF и RIP, но никак не для построения VPN-туннелей. А еще в случае GRE-туннеля у меня нет уверенности, что трафик пойдет в IPSec-туннель, а не в GRE. Проброс трафика между локалками в GRE-туннеле абсолютно неприемлем, т.к. такое решение не обеспечивает шифрование трафика.

Тем более, что проблема не в построении IPSec-туннеля - он есть и исправно работает. Проблема в том, что трафик не идет в этот туннель. Как я понимаю, рутер, вместо того, чтобы поставить в заголовок UDP-пакетов IP-адрес внешнего интерфейса, упорно ставит туда адрес частной сети, потому что изначально пакет пришел из внутренней сети. Как можно этого избежать не изменяя сам пакет?

Вы немного не так поняли, да ладно, если нужен именно IPSec, то давайте делать через IPSec.
Какой второй роутер, если на микротик, то через torch можно будет на нем посмотреть приходящие пакеты на интерфейс.

Простите, но вы ошибаетесь.
Вся маршрутизация TCP/IP построена на принципе нулевых маршрутов. Ни один рутер в мире не знает всех маршрутов. Задача каждого - отправить пакет до такого шлюза, который в конечном итоге будет знать, где искать сеть, в которой расположен адресат.
Да и как я могу прописать все маршруты на пути от сети 81.211.xxx.xxx до сети 81.13.xxx.xxx???
В нашем случае рутеру надо знать2 вещи - нулевой маршрут и IP-адрес внешнего интерфейса устройства, за которым находится нужная частная сеть.

З.Ы. Я немного недопонял еще Ваш пост про метрики. При чем тут метрики?.. А в общем и целом это еще половина задачи. Задача в целом не только связать сети IPSec-туннелем, но и обеспечить работу с резервными каналами. Вот тут как раз уже нужны метрики будут...

Пакеты между внешними интерфейсами прекрасно ходят.

Между внутренними интерфейсами все хуже - пакет шифруется и отправляется через внешний интерфейс на шлюз провайдера. Провайдер его дропает.

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

можно построить обычный EoIP и если IPSec работает нормально, то все должно работать.

Фактически я не понимаю как запихать в IPSec-туннель трафик. IPSec-туннель не виден! Его нет в интерфейсах, у него нет IP-адреса, его нет в Peers. Т.о. образом написать маршрут вида "частную сеть ищи в IPSec-туннеле" нельзя. Макарадить адреса тоже нельзя - пакеты дропаются. Что же делать?
Ну вот опять Вы предлагаете решать проблему методом туннель по туннелю. Но ведь это расточительство! У меня полоса пропускания 1 мегабит.

Если быть точным, то маршрутизация IP, дальше L3 при маршрутизации роутеры не должны знать.



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

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

давайте решать проблемы по мере их поступления.
для начала нам нужно прокинуть первую сеть ко-второму роутеру, без использования трансляции адресов, потому как НАТ не приемлем в данной ситуации.
я правильно вас понял?

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

Сейчас немного понятней стало ваше ТЗ

Так.
Давайте попробуем подвести промежуточные итоги

Итак, IPSec-туннели не являются VPN-туннелями. Правильно?

Вся работа с IPSec возможно только через GRE-туннели aka EoIP. Верно? Если нет GRE, то IPSec-туннель нам фактически ничего не дает?

Давайте подитожим.


Нет


GRE и EoIP это разный вид туннелирования, в первом случае туннелирование происходит посредством авторизации и шифрования, а второй сквозным пробрасывание всех данных, включая бродкасты.

EoIP - прозрачный мост (Ethernet over IP)

Используем NAT-T Где его искать?


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

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

Вообще все это очень странно. Я сам вязал сети посредством IPSec c IKE и все прекрасно работало и не нуждалось в каких-либо доп. туннелях.

На этом предлагаю взять паузу до понедельника.
Удачных Вам выходных

С уважением,
Андрей.

Структура IP пакета, после обработки IPSec меняется, что делает невозможным его правильное распознавание, для устранения этой проблемы используют NAT-Traversal, которая инкапсулирует IPSec трафик в UDP пакеты и передаёт их в виде привычного маршрутизируемого сетевого трафика, на принимающей стороне от пакета отбрасывается UDP заголовок и концевик и на стек протокола IPSec поступают полученные данные.
Mikrotik имеет следующие средства для работы с IPSec: создание политик для шифрования правил, автоматическую генерацию ключей, ручное создание правил для шифрования трафика, работу как в транспортном режиме, так и в режиме туннелирования, средства мониторинга.

В данной ситуации все упирается в трансляцию адресов, пакеты не заворачиваются в UDP.

При EoIP шифрование не будет, потому IPSec будет нужен, в отличии от VPN.
IPSec + Nat-T vs VPN + EoIP

И Вам всего хорошего!
С Уважением, Александр.

посмотри на счетчики

Доброе утро

И как это можно победить?


Счетчики считают зашифрованные/расшифрованные пакеты. Реджектов нет.

Доброе утро!

какой стоит ipsec protocols?
и в какой пакет инкапсулируется?
нужно смотреть torch на втором роутере
в настройках IP>Firewall>Nat нужно сделать src-address=blablabla с Action action=nat to-src-address=туннеля, хотя если пакеты заворачиваются на первом роутере, значит все ок.
тогда проблема в неразворачивании пакетов на втором роутере.
а если там все разворачивается, то проблема в маршрутизации на разворачиваемом роутере.

Короче вот что происходит.

Маршрут до удаленной сети не активен (192.168.1.0/24 -> внешний интерфейса рутера в HQ например)
Пакеты между двумя внеш. интерфейсами в торче выглядят как протокол IPsec (50).
При попытке пропинговать удаленную частную сеть пакет не инкапсулируется, а тупо отправляется на шлюз провайдера в виде icmp.
Вопрос для меня пока неразрешимый - как же написать роут для туннеля, у которого нет своего IP-адреса...

в настройках IPSec указывается в Policies>Action режим туннеля и его адреса фейковые
а в ip>firewall>nat, во вкладке action вместо masquerade, что направляет все пакеты на шлюз по-умолчанию, нужно указать src-nat=адрес туннеля, по-идее он будет заворачивать пакеты в туннель.

IPSec ставится при помощи ManualSA. IKE пока не поднимал. Шифрование AES-256.

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

Закладка General

Src.Addr: внеш. адрес1
Src.Port: все
Dest.Addr: внеш. адрес2
Dest.Port: все
Protocol: все

Закладка Action:

Action: encrypt
Level: require
IPSecProtocol: esp
Tunnel - marked
SA Src.Addr: внеш. адрес1
Sa Dest.Addr: внеш. адрес2
Proposal: default
ManualSA: sa1

проверьте nat-t

Еще тупой вопрос
А есть ли тут аналог команды show config?
Что-то не могу найти никак.

можно через export весь конфиг вывести в файл

в качестве туннеля сделайте EoIP

Еще раз сейчас перечитал мануал по IPSec.
Не нашел ни строчки о маршрутах, а также где настраивать NAT-t. Также не вижу информации о IP-адресах туннеля.
Прот НАТ-т вот что есть:
"В ситуации когда IPSec пакеты сгенерированы с использованием AH (Authentification Header) не достаточно применения технологии NAT. Структура IP пакета, подверженного обработке IPSec протоколом меняется, что делает невозможным его правильное распознавание. Для устранения этой проблемы прибегают к технологии NAT-Traversal, которая инкапсулирует IPSec трафик в UDP пакеты и передаёт их по сети в виде привычного маршрутизируемого сетевого трафика. На принимающей стороне от пакета отбрасывается UDP заголовок и концевик и на стек протокола IPSec поступают полученные данные."
и
"RouterOS Mikrotik имеет следующие средства для работы с IPSec: создание политик для шифрования правил, автоматическую генерацию ключей, ручное создание правил для шифрования трафика, работу как в транспортном режиме, так и в режиме туннелирования, средства мониторинга. Кроме того, в файерволе системы предусмотрен механизм NAT-T, о котором было рассказано выше."

Где его искать в настройках - не говорится ни слова.
Далее. Читаем -
"результате маршрутизаторы 192.168.1.1 и 192.168.1.2 будут обмениваться ключами и создадут безопасный шифрованный туннель между сетями 192.168.20.0 и 192.168.10.0."
Ага, только хорошо бы еще поиметь описание, как направить трафик в этот туннель.

В общем я так понимаю, что еще никто не пробовал использовать IPSec и Mikrotik OS.
Официальный саппорт тоже молчит.

Если честно - не буду
Я лучше поставлю на концах абсолютно понятные HP Procurve 7100dl. Мне совершенно не светит использовать в работе нечто, не являющееся стандартом шифрования данных (это я про EoIP).
Я лучше Микротики оставлю рулить каналами, а туннели буду поднимать на HP с помощью IPSec. Ибо у всех, кроме Mikrotik, туннели IPSec это именно туннели

Спасибо за то, что потратили на меня свое время

с помощью файрвола

Решать вам,

Добрый день!

Вы говорили, что можно направить траффик в туннель с помощью файервола.
Каким образом, если не секрет?

Буду очень признателен за помощь!

Здравствуйте

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

Делается это путем таблицы Mangle в файрволе, Action > mark routing и называется метку о маршруте.
Затем в IP > Routes в свойствах маршрута выбирается Routing Mark и нужная метка.

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

А туннель это всего лишь интерфейс.