IPSec VPN (site-to-site) – это технология, позволяющая объединить удаленные филиалы организации в единую защищённую сеть через Интернет, обеспечивая шифрование данных и высокий уровень безопасности.

В IPSec сайт-сайт между двумя равнозначными шлюзами USG6510E нет классической схемы «сервер-клиент». Оба устройства считаются равноправными пир-устройствами (peers). Инициатором IPSec-туннеля становится тот шлюз, который первым отправит трафик, подходящий под политику IPSec. Такой режим для Huawei называется bidirectional.

В данной инструкции представлен вариант настройки IPSec без использования сертификатов. Предполагается, что сетевой экран уже в работе, у него настроен как минимум WAN-интерфейс, маршрут по-умолчанию 0.0.0.0/0, NAT и соответственно есть доступ в Интернет. Все эти настройки можно посмотреть на этой странице. (ССЫЛКА)

 

НАСТРОЙКА FW1.

Задаем название устройства в сети через Dashboard, чтоб в дальнейшем различать два шлюза.

 

Политика IPSec.

Создаем новую политику.

 

Режим site-to-site выбирается автоматически.

Virtual System: public – если на USG включена технология виртуальных систем, здесь выбирается, в каком VSYS создаётся политика.

 

Вводим настройки базовой конфигурации.

Policy Name – любое понятное название IPsec-политики.

Local Interface – интерфейс, через который выполняется IPsec соединение.

Local Address – IP-адрес FW1.

Peer Address – IP-адрес FW2.

Authentication Type – способ аутентификации в IPsec.

Pre-shared key: – общий заранее согласованный ключ. Это пароль, который должен совпадать на обеих сторонах FW1-FW2. Вводим сложный пароль из не менее 8 букв разного регистра, цифр и спец.символов.

Local ID – идентификатор локальной стороны в фазе IKE. Используется IP-адрес по умолчанию.

Peer ID – идентификатор ответного FW в IKE. Так как в данном случае IP-адреса у FW1-2 статические – оставляется пустым. Можно в обоих указать IP-адреса как дополнительную меру безопасности.

Peer ID удобно использовать при динамическом внешнем IP у одного из FW. Например, в главном офисе статический IP, а в филиале динамический. В этом случае подключение от FW2 может приходить с любого внешнего IP-адреса. FW1 будет сравнивать не IP, а ID, указанное в IKE. Если ID совпадает, то туннель считается валидным. Это самый универсальный способ при динамических IP.

Add Security Policy – кнопка, чтобы создать соответствующую Security policy, которая разрешит IKE/IPsec трафик для заданных источников. Политиками займемся позже.

 

Data Flow to Encrypt – это правило, которое определяет, какой трафик должен шифроваться IPsec-политикой.

 

Выбираем адреса сетей источника и назначения.

Add Security Policy – кнопка, которая напоминает, что между указанными IP-адресами нужно разрешить трафик в политиках безопасности. Создадим эту политику позже.

 

IKE/IPSec Proposal (предложение) – это набор правил шифрования и параметров безопасности, которые используют две стороны для построения IPsec-туннеля.

Предложение делится на две фазы.

IKE Proposal – параметры фазы 1. Устанавливают защищённый канал для переговоров.

IPSec Proposal – параметры фазы 2. Шифруют трафик внутри канала.

 

IKE Parameters (фаза 1).

IKE (Internet Key Exchange) – обмен ключами. Выставляем значения как на скриншоте ниже.

IKE Version: IKEv2 – версия протокола IKE, используемого для установки защищённого канала.

Encryption: AES-256 – шифрование канала фазы 1.

Integrity Hash: SHA2-256 – хеш-алгоритм аутентификации.

PRF (Pseudo Random Function): SHA2-256 – псевдослучайная функция, используемая для генерации ключевого материала и проверки подлинности сообщений при установке IPSec-туннеля.

DH Group: 14 – параметры Диффи–Хеллмана (обмен ключами).

SA Timeout: 86400 – срок действия SA фазы 1 (24 часа).

 

IPSec Parameters (фаза 2).

IPSec (Internet Protocol Security) – защита данных.

Encapsulation Mode: Tunnel – режим инкапсуляции IPsec во второй фазе. Шифрует весь исходный пакет

Security Protocol: ESP – стандартный протокол для шифрования в IPsec.

ESP Encryption: AES-256 – симметричное шифрование, защищает содержание данных фазы 2.

ESP Authentication: SHA2-256 – аутентификация подтверждает целостность данных с использованием хэш-функции.

PFS (Perfect Forward Secrecy): 14 – совершенная прямая секретность. Создаёт отдельный DH-обмен для фазы 2.

SA Timeout (Phase 2 Lifetime) – жизненный цикл SA для IPsec-туннеля (через сколько SA нужно пересоздать).

By Time – сколько секунд «живет» SA фазы 2. Типовое значение: 3600 секунд (1 час).

By Traffic – максимальный объём данных через SA. Когда достигнут – SA пересоздаётся. Типовое значение 5242880 KB (≈ 5 ГБ).

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

 

Dead Peer Detection (DPD) – механизм проверки, «жив ли» IPsec-туннель.  Если например пропал Интернет, USG должен это заметить и закрыть SA, чтобы освободить ресурсы и не держать «зависший» туннель.

Detection Mode.

Periodic – отправка проверочных пакетов, каждые N секунд.

On-demand – проверка отправляется только если трафика нет или есть подозрение на разрыв. Используется редко.

 

Detection Interval: 30 сек – интервал отправки запроса клиенту о его актуальности.

Retry Interval: 15 сек – если ответа нет, через сколько повторять проверку.

Retrans Times: 3 раза – сколько повторных попыток считать нормой, прежде чем признать туннель «мертвым».

 

Политика безопасности.

Если мы хотим сделать правильно и безопасно, то нужны только точечные разрешения по конкретным портам. Создаем правила разрешающие IPSec порты.

IKE Phase 1: UDP 500 – используется для обмена IKE (Internet Key Exchange) при установлении защищённого канала управления между FW1 и FW2.

IPsec NAT-T: UDP4500 – инкапсулирует ESP в UDP 4500, чтобы туннель мог проходить через устройства, изменяющие адреса (NAT).

ESP IPsec: IP ESP – это отдельный IP-протокол номер 50 (не порт). Он обеспечивает шифрование, целостность и защиту данных, передаваемых внутри IPSec-туннеля.

USG сам предлагает еще добавить сюда ah (при создании IPSec-политики).

AH (Authentication Header) – протокол 51, обеспечивает проверку целостности и аутентификацию пакетов, но не шифрует данные. Практически не используется, не работает через NAT. Современные IPSec-туннели применяют ESP (протокол 50) вместо AH. Не будем его добавлять.

Создавать нужно отдельные правила для каждого протокола.

Предустановленных портов UDP 500 и 4500 нет, создаем их.

 

Аналогично создается порт UDP4500.

Создание портов через CLI.

 

Создаем политики безопасности.

 

На первом этапе трафик направляется из внешней не доверенной сети в сам USG, поэтому в политиках используется направление зон untrust-to-local.

Аналогично создаются правила для других протоколов.

 

Расположить правила нужно ближе к верху списка (выше правила полного доступа в Интернет).

Если в сетевом экране нет общего правила, разрешающего трафик из local в untrust, то нужно создать отдельные правила для указанных портов на выход из USG.

Если IPSec не получается запустить, то можно сделать два общих правила local-to-untrust и untrust-to-local с указанием внешних IP-адресов сетевых экранов FW1 и FW2. Это широкий охват всех используемых сервисов, но в реальной работе такой вариант лучше не использовать.

Если у филиала динамический внешний IP, то правила безопасности с жёстко прописанным адресом становятся бесполезными, потому что при смене IP они перестают соответствовать реальности. Единственный найденный способ это не указывать IP-адрес источника, чтобы IPSec мог устанавливаться независимо от того, какой сейчас внешний IP у филиала. Это безопасно, потому что любая попытка IKE дальше проверяется по Pre-Shared Key и без правильного ключа туннель всё равно не поднимется. Злоумышленники ничего не смогут сделать с разрешённым UDP 500/4500. В таком случае желательно использовать не Pre-Shared Key а сертификаты.

 

Политика безопасности для проходящего трафика.

При нажатии на кнопку-ссылку в настройке Data Flow, Huawei USG предлагает создать правило без указания зон, потому что decrypted IPsec traffic не находится в зоне untrust, хотя пришёл оттуда. Такой способ работает. Но правильно всё же указывать source-zone и destination-zone, чтобы USG мог корректно применить правила. В любом случае наличие конкретных IP-адресов в правиле значительно снижает риск, даже если зоны не указаны. Создаем два правила в перекрестных направлениях LAN1 в LAN2 и LAN2 в LAN1.

Через CLI.

Правило без указания зон нужно только одно. Если в правиле не указываются зоны, USG проверяет только IP-адреса и сервисы. Это значит, что правило действует на все интерфейсы, где source/destination совпадают с адресами в IPSec policy. С точки зрения работы IPSec туннеля это упрощает настройку: одно правило покрывает оба направления. Риск в том, что трафик с неожиданного интерфейса или зоны тоже может попасть под правило. Например, если в будущем добавится интерфейс снаружи, с совпадающими IP, то трафик пройдет, хотя его не планировалось пускать. Если зоны указаны, правило становится direction-sensitive и ограничивается только конкретными зонами, следовательно меньше шанс пропустить лишний трафик.

 

Маршрут в противоположную сеть.

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

 

В маршруте шлюзом указан IP-адрес противоположного USG (FW2).

 

Настройка FW1 завершена. Сохраняем конфигурацию на кнопку Save в верхней части браузера.

 

НАСТРОЙКА FW2.

Настройка почти идентична, поэтому приведена в виде текстовых команд для CLI.

Все команды в режиме system-view.

 

Название устройства в сети.

 

Политика IPSec.

Различие в этом разделе с FW1 в IP ответного шлюза и Data Flow to Encrypt. Источник и назначение меняются местами.

IKE Peer.

 

 IKE Proposal.

 

IPSec Proposal.

 

ACL.

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

 

IPSec Policy.

 

​

Политика безопасности.

Создание портов (сервисов).

 

Создание политик безопасности для туннеля.

Различие в этом разделе с FW1 в перестановке IP источника и назначения.

 

Политики для исходящего трафика (если потребуется).

 

Политика безопасности для forward-трафика.

 

Маршрут в противоположную сеть.

 

NAT.

В процессе тестов замечено, что трафик может пытаться идти в обход IPSec-туннеля через внешний IP-адрес. Чтоб это устранить нужно исключить трафик туннеля из NAT с помощью правила no-nat.

NAT всегда выполняется раньше IPsec ACL. Huawei это прямо пишет в документации: «For outbound traffic, NAT is performed before IPsec policy matching.» support.huawei

Если NAT policy неправильно настроена, то NAT подхватывает трафик туннеля и пытается перевести его во внешний IP, потому что он видит зону destination как untrust. В итоге пакет уже преобразован NAT, IPsec ACL уже не совпадает (ведь он ждёт 10.11.11.0/24 >> 10.12.12.0/24) и USG не отправляет пакет в туннель, а пытается доставить по routing table через WAN. То есть NAT просто портит пакет до того, как IPSec увидит его. Поэтому при NAT трафик начинает идти через внешний IP, а туннель остаётся без трафика.

 

Сохраняем настроенную конфигурацию.

 

Мониторинг.

Установившиеся туннели отображаются в USG на вкладке Monitor в IPSec.

 

Проверяем связь между компьютерами в разных сетях с помощью трассировки.

Из LAN11 в LAN12.

 

Из LAN12 в LAN11.

Там где звездочка находится сетевой экран. В нем не включено отображение ответа TTL.

Если трафик идет не по IPSec-туннелю, то это не правильно, не безопасно и нужно искать причины в настройках.

 

Диагностика.

Для диагностики работы IPSec туннеля используются различные инструменты.

Показывает состояние IKE Security Associations – этапы и параметры обмена ключами IKEv2, на которых основан IPSec-туннель. В выводе команды можно посмотреть список IKE-сессий и их Conn-ID, IP-адрес пира (peer), фазу, статус/флаги SA и др. Это всё используется для проверки успешной установки IKE-фазы, диагностики отказов, просмотра текущего состояния обмена ключами.

 

Эта команда показывает текущие IPSec Security Associations – активные параметры и состояние шифрованного туннеля IPSec: используемый туннелем интерфейс, используемая IPSec-политика и ACL, локальный и удалённый адреса/порты туннеля, какие сети входят в защищённый трафик flow source/destination и тп. Это полезная информация для диагностики.

 

По колонке hits можно определять доходит ли соединение до политики безопасности.

 

По статистикам ipsec и ike можно определить количество ошибок, количество успешных/неуспешных SA, падения/таймауты.

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

Дополнительную информацию по IPSec VPN можно посмотреть на официальном сайте info.support.huawei.com.