Disclaimer

Я работаю в сервисной компании, и в своей работе мы часто используем российские SD-WAN-решения. Делаем крупные и нестандартные внедрения, а также предоставляем сеть по «подписочной модели», в том числе и SD-WAN. Несмотря на то, что сама по себе концепция SD-WAN и основные делали архитектуры были описаны много лет назад, реальное применение технологии только набирает обороты.

В данной статье я хочу поделиться способом конфигурирования NAT на СРЕ (Customer Premises Equipment) от Kaspersky SD-WAN, который пригодится в случае подключения сетей с одинаковым адресным диапазоном. За два года работы мы накопили довольно большой и интересный опыт внедрения SD-WAN этого вендора. В статье вы не найдете рассказ про технологию SD-WAN в целом, сравнения решения разных вендоров, преимущества и недостатки сервиса, а также какое решение является «более настоящим» SD-WANом, а какое – только оптимизацией выхода в интернет. Потому что, возможно, все это будет темой для следующих статей. Здесь сфокусируюсь только на технических деталях конфигурирования.

О чем пойдет речь

Сегодня попробуем сделать на первый взгляд невозможную конфигурацию – а именно, соединить сети с полностью пересекающимся и даже одинаковым адресным пространством, используя решение Kaspersky SD-WAN. Бесшовное объединение сетей разных организаций и подразделений всегда были сложными задачами для сетевых архитекторов и инженеров.

На нашем стенде представлены две идентичные сети двух компаний, с диапазоном адресов 192.162.3.0/24, которые необходимо соединить. Для демонстрационных целей мы развернули три компьютера с различными популярными сервисами:

• VM-WINSRV (Web Server, RDP)

• VM-LAMP (Web Server, SSH)

• VM-CLIENT (RDP)

Обращаю внимание, что VM-LAMP и VM-CLIENT имеют полностью одинаковые IP-адреса и даже сетевую конфигурацию (маска, шлюз, сервер имен).

Наша схема представлена на рисунке:

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

Адреса псевдонимов взяты «почти случайным» образом с маской 32 бита. Маска 32 бит позволит нам максимально снизить вероятность попадания в какой-то рабочий диапазон в интернете или другой сети. Можете брать, например, RFC 1918-диапазоны, но самое главное условие – псевдоним должен быть уникальным и не пересекаться с адресами, с которыми взаимодействует данный компьютер.

Внутри Kaspersky SD-WAN лежит классический iptables. Если вы знакомы с этим инструментом, то многие параметры конфигурирования для вас будут более понятны. SNAT – Source Network Address Translation – механизм, при котором в пакете проходящем через маршрутизатор меняется адрес отправителя (цепь postrouting). DNAT – Destination Address Translation – тут меняется адрес получателя (цепь prerouting).

Для удобства восприятия я представлю вначале конфигурацию NAT в направлении от VM-CLIENT к компьютерам Компании 1, затем из сети Компании 1 к компьютеру VM-CLIENT.

Следующая схема показывает концепцию конфигурирования SNAT и DNAT на СРЕ SD-WAN Kaspersky, использованную в данной статье:

В исходящих пакетах с VM-CLIENT необходимо заменить адрес отправителя (SRC) на 11.0.2.236 при выходе с СРЕ ICL-KESR1-02. При прохождении СРЕ ICL-HABR-DEMO-YANDEX-01 необходимо заменить адрес-псевдоним на реальный адрес. Замена происходит на двух устройствах, а подмененные адреса указаны на схеме выше.

Приступим к конфигурированию

Начнем с настройки адресов-псевдонимов. Kaspersky SD-WAN не позволяет напрямую задать alias на интерфейсах, поэтому, используем хитрость, конфигурируем VRRP. Выбираем уникальный VRID, устанавливаем Master роль и задаем адрес-псевдоним (VIP):

Фактически ICL-KESR1-02-B будет всегда играть master-роль, но нам нужен не сам VRRP, а результат. Под капотом мы увидим дополнительный адрес в виде так называемого alias:

Аналогично поступаем для ICL-HABR-DEMO-YANDEX-01:

Только в этом случае нам необходимо добавить два псевдонима, для VM-LAMP и VM-WINSRV. Результат:

Так как в моем примере используется адрес с маской 32 бита, необходимо настроить еще и таблицу маршрутизации. При использовании маски 24 бита для адресов-псевдонимов в VRRP и нахождении СРЕ в одной сети overlay можно было бы обойтись и без конфигурирования маршрутов.

В качестве Gateway указан 192.168.1.4 это адрес CPE ICL-HABR-DEMO-YANDEX-01, 192.168.1.221 это адрес ICL-KESR1-02-B в сети overlay.

Теперь сконфигурируем SNAT на ICL-KESR1-02-B:

Более детально, содержимое строки:

Во всех исходящих пакетах с VM-CLIENT на адрес 11.0.0.0/24 меняем исходящий адрес на псевдоним. Иначе, при сохранении реального адреса, получатель не сможет вернуть ответ, так как это адрес из сети получателя. Далее пакет в таком виде будет отправлен на СРЕ ICL-HABR-DEMO-YANDEX-01, где произойдет трансляция другого типа – DNAT.

Конфигурируем DNAT на ICL-HABR-DEMO-YANDEX-01:

И более подробно первая строчка:

Для разнообразия примеров, DNAT настроен по-разному для VM-LAMP и для VM-WINSRV. Для первого хоста мы обрабатываем только TCP/80 и TCP/22. Для второго (VM-WINSRV) мы не уточняем порты и протокол, а пропускаем все протоколы, вложенные в IP.

Теперь сконфигурируем пример с трафиком от компьютеров «Компании 1» к компьютеру «Компании 2» (VM-CLIENT).

Тут мы разрешаем компьютерам «Компании 1» подключаться к VM-CLIENT. В качестве демонстрации вариантов настойки, в этот раз я не использую адреса-псевдонимы» для подмены адреса отправителя. Вместо этого беру адрес интерфейса overlay (192.168.1.4).

Конфигурация SNAT для ICL-HABR-DEMO-YANDEX-01:

В предыдущем примере мы конфигурировали в этой вкладке только DNAT.

Конфигурация DNAT для ICL-KESR1-02-B:

В предыдущем примере мы конфигурировали в этой вкладке только SNAT, сейчас показываю вкладку DNAT.

Вместо заключения

Итак, я показал несколько вариантов соединения двух «одинаковых» сетей с помощью NAT заданного в интерфейсе управления Kaspersky SD-WAN. Такие задачи регулярно встречаются в работе сетевых инженеров, и всегда удобно, если используемое решение позволяет произвести конфигурацию быстро и понятно.

В заключение хотел бы отметить и некоторые ограничения:

• ограничения в количестве VRID в одной сети (1-255). В случае повторений VRID на разных СРЕ мы будем видеть ошибки в логах. На практике мы еще не доходили до этого ограничения;

• не поддерживается ALG. На сегодня работа NAT и Межсетевого экрана не работает на 7 уровне. Не думаю, что это нужно. Но тем не менее, для тех, кто ждет более корректную трансляцию «уровня 7», есть плохие новости;

• работая с межсетевыми экранами не следует забывать про ICMP type 3 code 4. В первом туннеле нет разрешенного ICMP, поэтому, механизм PMTU работать не может.

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

К сожалению, сделать отдельный фильтр на SNAT/DNAT только для ICMPType 3 Code 4 не получится, придется разрешать весь IP, а блокировки производить уже в межсетевом экране.Kaspersky SD-WAN корректно отрабатывает ответы, и PMTU работает корректно, если разрешен, но замечу, что для сложных случаев в решении есть механизм «MSSclamptoPMTU», который поможет решить проблему – но это вновь тема для другой статьи.