Astra linux l2tp ipsec

Команды для работы с VPN соединением

Вывести информацию о созданном соединении

Подключение к VPN из командной строки

Отключение от VPN из командной строки

Еще больше интересных статей на тему Linux читайте на нашем сайте.

Новости и обсуждение также есть на сайте ВК. Мы рассмотрели создание VPN соединения из консоли Linux.

Источник

Непростой IPSec с Linux

Развивая IT-инфраструктуру рано или поздно приходит задача интегрироваться с какими-либо сервисами крупной организации. Это может быть, например, банк или оператор связи. Как правило в крупных организациях действуют устоявшиеся политики информационной безопасности, которые в частности требуют реализации сервиса с внешней по отношению к ним инфраструктурой через шифрованные каналы — IPSec. В то же время в небольших организациях стартапах нет опыта организации таких схем, а из оборудования есть только VDS с Linuxом на борту. Более того, к моему удивлению, в рунете практически нет материалов с описанием инструментов траблшутинга под Linux. Попробуем устранить этот пробел и описать практическую часть настроек.

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

Обратите внимание, сам IPSec организовывается между одними IP-адресами (в моем примере 10.0.255.1 10.0.1.1 ), а сам сервис — между другими ( 192.168.255.1 192.168.1.1 ). Такие схемы еще называются IPSec Network-Network.

Простой пример — вы работаете в молодой, но очень амбициозной компании СуперСервис, и вам надо организовать взаимодействие с закрытым API компании МегаТелеком. Ваша инфраструктура — один сервер VDS, инфраструктура партнера — куча сетевого и серверного оборудования. Задача делится на два этапа:

1. Организовать транспорт (как будет происходить межсетевое взаимодействие).
2. Настроить сервис (запустить приложения непосредственно на серверах).

Итак, менеджер СуперСервис решил организовать подключение к какой-то крупной организации для решения бизнес-задачи. Он обратился к МегаТелеком, на что ему выслали технические условия по подключению. Одно из этих условий — организация IPSec. Это условие пришло в виде таблички excel, пример которой я представил ниже. На картинке я желтым выделил технически значимые параметры. Формат может отличаться, но суть остается той же.

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

Концепция IPSec

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

IPSec — набор техник и протоколов по организации защищенного соединения.

В отличии от прочих технологий туннелирования (GRE, PPP, L2TP, даже MPLS-TE) для IPSec не создается явных туннельных интерфейсов, через которые можно маршрутизировать трафик. Вместо этого в IPSec предусмотрена концепция так называемых Security Assotiations (SA). SA и есть туннель от одного сетевого устройства к другому. Но не стоит забывать, что SA — не сетевой интерфейс в нормальном понимании этого слова, классическая маршрутизация здесь не работает. Вместо таблицы маршрутизации здесь работает концепция Security Policy (SP). Мы явно прописываем что-то типа аксес-листа (ACL) для пропуска трафика через определенную SA. Все эти вещи определены в так называемом фреймворке ISAKMP.

ISAKMP — описание процедур IPSec, в литературе называют его фреймворком. В нем описываются термины SA, SP, SAD (Security Assotiations Database), SPD (Security Policy Database), необходимость установки вспомогательных туннелей… ISAKMP построен так, чтобы не зависеть от технологий туннелирования, алгоритмов аутентификации и шифрования. Он просто вводит необходимые определения.

IKE(v1/2) — непосредственно протокол аутентифиации. Он уже реализовывает алгоритмы обмена ключами и их применение.

Благодаря концепции Cisco сейчас ISAKMP и IKE считаются синонимами.

Перед шифрованием трафика стороны должны договориться о параметрах (и ключах) этого шифрования. Для этого между обоими сторонами поднимается вспомогательный туннель (его еще называют ISAKMP туннель), который действует все время. Туннель этот двунаправленный, представляет из себя соединение по UDP (по умолчанию на порту 500). Для организации этого вспомогательного туннеля стороны должны проверить подлинность друг друга (должен совпасть пароль). Этим занимается протокол IKEv1/2 (Internet Key Exchange). И уже по организованному ISAKMP туннелю стороны договариваются о шифровании непосредственно пользовательского трафика.

Собственно организация IPSecа делится на две фазы:

1. Создание вспомогательного туннеля ISAKMP
2. Создание туннеля пользовательских данных

Как я писал, в концепции IPSec (а уже правильнее говорить, в концепции ISAKMP) туннели называются SA.

Первая фаза (организация ISAKMP SA) может осуществляться в двух режимах:

1. main — стороны поочередно обмениваются параметрами согласования. Считается более безопасным, используется для постоянных каналов (наш случай).
2. aggressive — инициатор в одном сообщении отправляет все необходимые параметры согласования, используется при подключении удаленного пользователя для временной сессии (чтобы быстрее).

Надо понимать, что основные SA-туннели однонаправленные. Для двусторонней передачи данных по IPSec каналу должно быть два туннеля: источник (src) → получатель (dst) и наоборот.

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

Шифровать и аутентифицировать исходный IP-пакет можно без учета IP-заголовка (транспортный режим) или вместе с ним (туннельный режим). Транспортный используется тогда, когда планируется организовать свои туннели по другим технологиям (не IPSec/ESP). Например, GRE, l2tp, ppp. Для целей подключения какого-то сервиса ко внутренней инфраструктуре большой организации практически не используется. Я использовал такой сценарий для объединения нескольких офисов в один VPN через IPSec-и. Нам же более интересен туннельный режим. Как видно из картинки, здесь добавляется один дополнительный IP-заголовок.

Кстати, есть реальный пример использования AH-инкапсуляции. Предположим, у нас есть две сети, подключенные к разным маршрутизаторам. Хосты должны передавать информацию с MTU 1500 байт без фрагментации, но у нас есть промежуточный участок, который поддерживает только 1380 байт. Вся трасса доверенная. Мы можем воспользоваться тем, что IPSec не создает туннельных интерфейсов, в классическом смысле через которые трафик не маршрутизируется. Мы создадим SA туннель AH типа (нам же не надо шифровать), тогда трафик пойдет него. В трафике фрагментироваться будут только внешние IP-пакеты (по внешним IP-заголовкам), внутренние будут пересобираться без изменений.

Обратите внимание, что заголовок ESP встает до транспортных TCP/UDP. Помните, в заголовке IP-пакета есть поле Protocol? На основе этого поля сетевое оборудование (да и конечные хосты) корректно обрабатывают IP-пакеты. Так вот для ESP свой номер — 50. Полный список протоколов для этого поля можно посмотреть на вики, бывает весьма полезно.

Отсутствие заголовка транспортного уровня (TCP/UDP/ICMP уже зашифрованы!) накладывает ограничение на технологии типа NAT. Вспомните, NAT с трансляцией портов (overload, PAT, MASQARADE, у него много имен) работает на основе портов транспортных протоколов. А в зашифрованном туннеле IPSec их нет! Для преодоления этой проблемы есть такая технология, как IPSec NAT-Traversal (NAT-T). В ходе первой фазы стороны согласовывают возможность использовать NAT-T. Если обе стороны поддерживают NAT-T (да еще и на одинаковых UDP-портах), тогда в итоговых туннелях для трафика добавляется заголовок UDP, с которым пакеты уже пройдут через маршрутизаторы с трансляцией сетевых адресов.

Сам по себе туннель не поднимется, нужно направить туда трафик. Как я писал выше, здесь не работают правила маршрутизации, надо писать политики Security Policy (SP).

Политики состоят из адреса источника, адреса назначения, направления (in, out, fwd) и параметров пользовательских туннелей (здесь как раз описываются ESP это будет или AH, туннельный вариант или транспортный). Это больше похоже на организацию правил для NATа. NATу тоже недостаточно записей таблицы маршрутизации. И там тоже указываются правила откуда, куда и как, а не куда и через что. И также неверным движением руки можно завалить всю связь на удаленном сервере.

Все манипуляции с IPSec добавляют заголовки служебной информации. Минимум они съедят еще 40 байт от исходного пакета. Таким образом, например, при стандартном MTU для PPPoE в 1380 байт соединений реальное MTU будет /etc/racoon.conf ), запускается обычным init-скриптом ( /etc/init.d/racoon ).

Как всегда, подробности в man 5 racoon.conf

Дальше займемся утилитой setkey. Она тоже запускается как демон ( /etc/init.d/setkey ), но по факту она выполняет скрипт /etc/ipsec-tools.conf . Как я и говорил, она уже задает создает туннели для пользовательского трафика. А именно задает SA и SP для них. Это что-то вроде crypto-map на ASA. Самый простой вариант для нас — добавить просто SP. Тогда SA построится автоматически исходя из параметров второй фазы, указанной в настройках racoon.

Но есть возможность вообще не использовать параметры второй фазы из racoon, а задать SA через эту утилиту. Подробности и синтаксис можно посмотреть в man 8 setkey . А я же приведу приведу пример простейшей конфигурации.

На текущий момент утилиту setkey дублирует модуль iproute2.
В рамках него есть две команды управления записями SA и SP.

1. ip xfrm state
2. ip xfrm policy

Помимо управления этой же утилитой можно смотреть состояние организованных SA и применяемых к трафику SP. Подробнее в man 8 ip-xfrm .

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

1. Статический маршрут без определения некстхопа, но с явным указанием исходящего интерфейса и IP-адреса.
2. Задание маршрутов на основе policy based routing (PBR в Linux ака ip rule).
3. Трансляция адресов (NAT/MASQARADE).

С моей точки зрения здесь подходит первый вариант.

Мы можем добавить на наш интерфейс дополнительный (secondary) IP-адрес, при этом лучше сделать alias для этого интерфейса
root@localhost:

# ip addr add 192.168.1.1/32 dev eth1 label eth1:1
и настроить маршрут до сервера Мегателеком с этого IP-адреса.
root@localhost:

# ip route add 192.168.255.1/32 dev eth1:1 src 192.168.1.1
Но если так сделать, ничего не заведется. Дело в том, что при добавлении маршрута в таком виде Linux-станция будет пытаться определить MAC-адрес получателя, делать она это будет через ARP… Компьютер будет слать запросы ARP Who has IP 192.168.255.1 . Так как 192.168.255.1 нет в той же сети, где и 192.168.1.1 (маска /32!), ответа на ARP не будет. Зато при попытке соединения будет возвращаться с локального IP-адреса будет возвращаться No route to host . Чтобы это победить, нам надо задать статическую ARP-запись:
root@localhost:

# arp -s 192.168.255.1 00:00:00:00:00:01 -i eth1:1
Такой вот лайфхак. Кстати, такие манипуляции могут привести не совсем к коректной работе IP-стека Linux. В одном из случаев команды ip route не приводили к нужному результату, пришлось перезагружать сетевой стек.

Проверка работоспособности

Не забывайте, туннель поднимется только тогда, когда в него пойдет трафик! Надо запустить пинг с конкретного интерфейса (IP-адреса) до назначения.
root@localhost:

# ping -I 192.168.1.1 192.168.255.1
С небольшой задержкой должны быть ответы с обратной стороны (если конечно ICMP нигде не закрыт на участке).

Мы можем увидеть, поднялся ли ISAKMP-туннель

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

Бывает полезно в tcpdump посмотреть логику установления соединения. Здесь можно также увидеть фазы установления соединения и уже передаваемый шифрованный в ESP трафик. Конечно есть техники его расшифровки, но обычно такого вывода уже достаточно.

# tcpdump -i eth1 host 10.0.255.1

При удаленном подключении по SSH, чтобы не плодить кучу окон удобно запускать tcpdump в фоне:

# tcpdump -i eth1 -w ipsec.pcap esp &

Запускаем ping, telnet, netcat…

# killall tcpdump
root@localhost:

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

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

P. S.: Просьба обо всех ошибках или неточностях в статье сообщать личным сообщением. Когда я подправлю статью, комментарии будут смотреться глупо.

Источник