Что такое VPN-туннель
В этой статье рассказываем, что такое VPN-туннели, как они работают, а также — какие есть виды туннелирования.
В нашей технологически развивающейся эпохе, где все больше информации передается через сети, чаще возникает угроза утечки данных. Поэтому важно обеспечить безопасную передачу информации между двумя и более сетевыми узлами.
Рабочий способ — использовать технологию VPN-туннелирования, которая позволяет установить инкапсулированное сетевое соединение между двумя сетевыми узлами. В этой статье рассмотрим, что такое VPN-туннели, как они работают, а также — какие есть виды туннелирования.
Что такое VPN-туннель
VPN-туннель — это сетевое соединение для безопасной передачи информации между двумя или более удаленными узлами в интернете.
Когда пользователь подключается к VPN-туннелю, все сетевое взаимодействие происходит внутри него, что позволяет создать безопасный канал для обмена данными между удаленными узлами. При этом VPN-туннели можно использовать для обхода заблокированных в вашем регионе ресурсов.
Как работает VPN-туннель
Внутри VPN-туннеля данные упаковываются в специальные пакеты и передаются по защищенному каналу, как если бы они перемещались через физическое соединение, например, с помощью Ethernet. Это делает невозможным просмотр и изменение данных при передаче между устройствами. То есть в процессе работы пакеты шифруются, чтобы исключить нелегитимный доступ со стороны злоумышленников.
Есть несколько протоколов туннелирования (например, GRE, ICMP или IP in IP), которые можно использовать для настройки VPN-туннелей. Выбор конкретного зависит от цели, ваших требований к стойкости шифрования и вычислительной сложности.
Кроме того, VPN-туннель может работать в нескольких режимах — «передача данных между двумя сетями», «защита удаленного доступа к внутренним ресурсам сети» и «обход ограничений доступа к определенным ресурсам».
Передача данных между двумя сетями
Этот режим используют для соединения локальных сетей между собой через интернет. Такой подход может быть полезен для организации связности между филиалами компании. При этом каждый конец туннеля должен быть настроен для подключения к определенной сети.
Защита удаленного доступа к внутренним ресурсам сети
Этот режим подходит для создания безопасного и шифрованного канала между отдельным устройством — как правило, компьютером или телефоном — и внутренней сетью, к которой обычно нет прямого доступа. Такой подход может быть полезен для удаленной работы, когда сотрудникам нужен доступ к внутренним ресурсам компании, или для подключения к домашней сети из разных мест. В этом режиме удаленный клиент должен быть настроен для подключения к сети через VPN-туннель.
Обход ограничений доступа к определенным ресурсам
Этот режим используется для доступа к ресурсам, которые могут быть географически заблокированы или ограничены. Например, если вы путешествуете в страну, где доступ к некоторым веб-сайтам заблокирован, VPN-туннель поможет обойти это ограничение и получить доступ к содержимому. В этом режиме выбор конечной точки туннеля важен, чтобы обойти ограничения на контент. Другими словами, нужно подключиться к ресурсу по VPN через страну, где искомый ресурс доступен.
Виды туннелирования VPN
Существует несколько видов туннелирования VPN, каждый из которых выполняет определенные функции в защите данных и настройке соединения:
- Раздельное туннелирование. Метод, при котором VPN-туннель создается только для определенных сетевых соединений, в то время как другие остаются открытыми. Позволяет экономить на пропускной способности сети путем исключения передачи трафика. Однако это менее безопасный метод: информация, которая передается через обычное подключение к интернету, может быть украдена.
- Полное туннелирование. Метод, при котором весь сетевой трафик проходит через VPN-туннель. Этот метод обеспечивает большую степень безопасности, поскольку вся передаваемая информация защищена от внешних угроз. Однако может замедлить скорость соединения и использовать большую пропускную способность сети, чем раздельное туннелирование.
Выбор между раздельным и полным туннелированием зависит от нескольких факторов, включая уровень безопасности, необходимость регулирования пропускной способности сети и ее общую производительность. Если безопасность данных в приоритете, предпочтительнее использовать полное туннелирование. Если же необходимо сохранить пропускную способность сети и обеспечить безопасность некоторых соединений, лучшим выбором станет раздельное туннелирование.
Шифрование и безопасность
Когда речь заходит о шифровании в VPN, важно различать алгоритмы шифрования и типы шифров. Фактически, первые относятся к способам передачи данных внутри VPN-туннеля. Сам шифр может быть одним из алгоритмов шифрования, но не наоборот. Давайте подробнее рассмотрим каждую из сущностей.
Алгоритмы шифрования
Одно из главных условий VPN-технологии — это качественное шифрование данных для защиты пользовательской информации во время передачи через интернет. Традиционные стандарты включают в себя симметричное и асимметричное шифрование.
Симметричное шифрование использует один и тот же ключ для шифрования и дешифрования информации. В случае VPN-технологий, клиент и сервер обмениваются одним ключом шифрования, так что все передаваемые данные могут быть зашифрованы и дешифрованы с помощью него. Симметричное шифрование обеспечивает быстрое и эффективное шифрование данных, что делает его наиболее распространенным методом.
Однако симметричное шифрование является менее безопасным, чем асимметричное, поскольку использует один и тот же ключ. Если злоумышленник получит к нему доступ, все данные могут быть легко прочитаны.
Асимметричное шифрование, напротив, использует два ключа — открытый и закрытый. Первый может распространяться свободно и используется для шифрования, в то время как второй — для дешифрования и является конфиденциальным.
Асимметричное шифрование обеспечивает более высокий уровень безопасности, чем симметричное. Однако является менее эффективным и зачастую требует больше ресурсов для шифрования и дешифрования данных.
Выбор алгоритма зависит от нужд компании и уровня безопасности, который она хочет обеспечить для своих пользователей. Часто VPN-сервисы комбинируют оба метода.
Методы шифрования
AES (Advanced Encryption Standard). Это один из наиболее распространенных и надежных методов симметричного шифрования. Использует один и тот же ключ для шифрования и дешифрования данных и шифрует данные блоками по 128 бит. AES имеет также другие варианты длины ключа — AES-128, AES-192 и AES-256. Последний считается наиболее надежным и часто используется в VPN-сервисах.
ChaCha20 и Poly1305. ChaCha20 — это относительно новый метод поточного шифрования, который был разработан для обеспечения большей производительности и безопасности туннелирования. В сочетании с MAC-функцией Poly1305, этот метод обеспечивает высокоскоростной и надежный способ шифрования данных. ChaCha20 и Poly1305 используют ключ длиной 256 бит.
Blowfish и Twofish. Blowfish является симметричным блочным шифром, который был разработан в 1993 году. А Twofish — его наследником, ориентированным на безопасность и производительность. Оба метода используют шифрование с переменной длиной ключа, блоки по 64 бита и различные режимы их шифрования.
3DES (Triple Data Encryption Standard). Это метод симметричного шифрования, который использует три ключа. Он не считается безопасным и уже устарел, но все еще используется в некоторых VPN-сервисах.
RSA (Rivest-Shamir-Adleman). Это асимметричный методом шифрования, который использует два ключа — открытый и закрытый. Он используется для создания зашифрованных туннелей безопасного обмена данными. RSA является более безопасным, но медленным в сравнении с симметричными методами. Это особенно заметно при использовании ключей большей длины.
MPPE (Microsoft Point-to-Point Encryption). Это метод симметричного шифрования, который был разработан для работы в соединениях PPTP (Point-to-Point Tunneling Protocol). Он использует ключ длиной 40 или 128 бит и шифрует данные.
Camellia. Это метод симметричного шифрования, который обычно называют альтернативой AES. Он использует ключ длиной от 128 до 256 бит и шифрует данные блоками по 128 бит. Camellia считается наиболее безопасным методом шифрования.
Большинство современных VPN-сервисов сочетают несколько методов шифрования, чтобы обеспечить максимальную защиту данных и сохранить высокую производительность.
Туннельные протоколы
VPN работает, используя различные туннельные протоколы, которые кодируют все данные, отправляемые через интернет, и обеспечивают их безопасность. Эти туннельные протоколы могут использовать различные методы шифрования и установки соединений, а также поддерживать разные уровни безопасности.
PPTP (Point-to-Point Tunneling Protocol)
PPTP — однин из самых старых и наиболее распространенных протоколов для создания VPN-туннелей. Он поддерживается многими операционными системами, включая Windows, MacOS и Linux. И является симметричным протоколом, который использует шифрование MPPE для защиты данных, передаваемых через туннель.
PPTP может быть быстрее, чем некоторые другие протоколы, но он не считается наиболее безопасным, так как уже был взломан в прошлом. Следует использовать PPTP только тогда, когда другие протоколы недоступны или не подходят для конкретных нужд.
L2TP (Layer 2 Tunneling Protocol)
L2TP — наиболее безопасный протокол, чем PPTP. Поддерживается почти всеми операционными системами. Использует асимметричное шифрование RSA и шифрование с ключом 256 бит. L2TP обеспечивает высокий уровень безопасности, но при этом может быть медленнее, чем другие протоколы.
IPSec (Internet Protocol Security)
IPSec — туннельный протокол, который может работать как для симметричного, так и для асимметричного шифрования. С помощью него можно обеспечить высокий уровень безопасности: IPSec шифрует данные с ключом до 256 бит. Однако может быть сложен в настройке и иметь низкую производительность на некоторых устройствах.
OpenVPN
Сочетает в себе преимущества PPTP, L2TP и IPSec, обеспечивает высокий уровень безопасности и производительности. OpenVPN может использовать AES-256 для шифрования данных с поддержкой симметричного и асимметричного шифрования. А также поддерживает сжатие данных.
IKEv2 (Internet Key Exchange version 2)
Это один из самых быстрых и безопасных протоколов для создания VPN-туннелей. IKEv2 особенно хорошо подходит для работы с мобильных устройствах, так как поддерживает быстрое соединение между сетевыми интерфейсами — например, между Wi-Fi и мобильной связью. Протокол можно настроить — например, выбрать подходящий алгоритм шифрования.
WireGuard
Это относительно новый протокол туннелирования, который уже зарекомендовал себя как быстрый и легковесный вариант. WireGuard использует симметричное шифрование и поддерживает различные методы аутентификации и шифрования, включая ChaCha20 и Poly1305. Этот протокол может работать на большинстве современных операционных систем, включая Windows, MacOS, Linux, Android и iOS.
SSTP (Secure Socket Tunneling Protocol)
Этот протокол был разработан специально для Windows и использует SSL-шифрование для создания защищенного туннеля. SSTP можно использовать для соединения с VPN-серверами через HTTP-прокси, что делает его идеальным вариантом для офиса. Несмотря на свою безопасность, этот протокол довольно медленный.
Выбор протокола зависит от требований к безопасности, производительности и доступности. В большинстве случаев достаточно OpenVPN и IKEv2, так как они обеспечивают высокую безопасность и быстрое соединение. PPTP и L2TP могут быть незначительно быстрее, но менее безопасны, а IPSec и SSTP имеют больше требований к настройке. WireGuard также можно назвать хорошим вариантом для создания мобильных VPN-туннелей за счет своей скорости.
Преимущества и недостатки использования VPN
Преимущества
- Безопасная передача данных. VPN-соединение защищает данные от внешних угроз, таких как кража данных или взлом соединения.
- Анонимность и конфиденциальность. VPN обеспечивает анонимность и конфиденциальность, скрывая реальный IP-адрес пользователя и его локацию.
- Обход ограничений. VPN можно использовать для обхода ограничений, которые не позволяют пользователю получить доступ к веб-сайтам, сервисам или контенту, например, в определенных странах.
- Безопасный доступ к общественным Wi-Fi сетям. Не все Wi-Fi сети обеспечивают безопасную передачу конфиденциальных данных — например, паролей и логинов. VPN шифрует информацию, тем самым обеспечивает безопасный доступ к общественным сетям.
Недостатки
- Медленная скорость соединения. VPN может замедлить скорость соединения за счет шифрования данных и добавления дополнительных ресурсов на маршрутизаторах и серверах.
- Дополнительные расходы. Некоторые VPN-провайдеры взимают плату за использование услуг.
- Риск компрометации данных. Неправильная настройка VPN-соединения или использование ненадежных провайдеров может привести к утечке или компрометации данных.
ГОСТ VPN как сервис
Создайте удаленный доступ к вашей инфраструктуре в Selectel, используя алгоритмы шифрования ГОСТ.
Варианты использования VPN
VPN можно применять как в частной, так и корпоративной сферах. Рассмотрим наиболее популярные способы.
Частная сфера
По сути, к частной сфере можно отнести все сценарии, о которых мы говорили ранее: от организации безопасного соединения с сетями Wi-Fi и обхода ограничений до обеспечения конфиденциальности и анонимности в интернете.
Однако VPN также можно использовать, например, для безопасного подключения к домашней сети из любой точки мира. Это особенно полезно, если у вас есть собственное облако для хранения файлов.
Корпоративная сфера
В корпоративной сфере VPN можно использовать для удаленного доступа — например, к внутренним ресурсам. Для работы из дома сотрудники могут подключаться к офисной сети через безопасное соединение.
Также с помощью VPN можно настроить связность между филиалами компании и организовать доступ до зарубежных облачных SaaS-сервисов. Последнее особенно актуально, когда важно сохранить защиту персональных данных сотрудников.
Способы организации VPN
Существует два основных способа организации VPN — использование собственного сервера или аренда решения от провайдера. Оба варианта имеют свои преимущества и недостатки, а выбор зависит от конкретных потребностей и возможностей пользователя.
Собственный сервер
Создание туннеля на собственном сервере — это более гибкий и в долгосрочной перспективе выгодный вариант для организации VPN. Для этого потребуется установка специального ПО на сервере.
Если сервер собственный, вы можете по-своему настраивать политики доступа, выбирать протоколы шифрования и другое.
Обычно настройка VPN-туннеля состоит из нескольких этапов:
- установка VPN-серверного ПО и настройка сетевых интерфейсов,
- настройка доступа к VPN-серверу с помощью учетных записей пользователей и сетевых конфигураций,
- настройка параметров безопасности, включая шифрование данных, сертификаты безопасности и другое,
- настройка политик доступа для различных пользователей и групп,
- настройка клиентского ПО для соединения с VPN-сервером.
VPN-провайдер
Доступный и простой вариант организации VPN — аренда сервера у провайдера. При выборе VPN-провайдера необходимо учитывать:
- надежность и безопасность сервиса,
- скорость соединения,
- количество доступных серверов,
- стоимость услуги,
- уровень поддержки клиентов,
- совместимость с различными операционными системами и устройствами.
VPN-провайдеры предоставляют простой способ организации VPN. Необязательно разбираться инфраструктурном оборудовании — все уже настроено за вас.
Создание VPN-туннеля
VPN-туннели создают виртуальные каналы передачи данных, которые позволяют пользователям и приложениям обращаться к ресурсам одной сети, в данном случае виртуальной, так, как если бы они находились непосредственно внутри этой сети. Таким образом, создаётся своеобразный «туннель» через общественную сеть, которой обычно является интернет.
VPN-туннелирование использует протоколы шифрования и аутентификации, обеспечивающие защиту передаваемых данных и обмен ключами для сохранения безопасности и целостности информации, проходящей через VPN-туннель.
Для построения VPN-туннеля в облаке #CloudMTS используется стандарт IPSec.
Создание VPN-туннелей требуется для связи площадок между собой по внутренним IP-адресам через защищенный канал, построенный поверх сети интернет.
Преимущество их использования в сравнении с другими способами связности сетей заключается в экономической выгоде и простоте в настройке. В облаке #CloudMTS для VPN-туннеля взимается плата только за использование публичного IP-адреса.
Поскольку VPN-туннель представляет собой двунаправленный обмен трафиком, для обозначения точек подключения выделяют Сторону А и Сторону Б.
В контексте документации #CloudMTS:
- стороной А является CloudMTS,
- стороной Б может быть выбранное пользователем оборудование, способное терминировать IPSec-туннель.
В случае VPN-туннелей Сторона А и Сторона Б играют роль точек подключения. Это значит, что настройки на обеих сторонах должны быть симметричные.
Типы VPN-туннелей
- Route-based — основывается на маршрутизации трафика. Он использует информацию о маршрутах, чтобы определить, каким образом данные должны быть направлены через VPN-туннель.
- Policy-based — основывается на политиках безопасности. Он использует набор правил и условий, определенных в политиках безопасности, чтобы решить, какие данные будут пересылаться через VPN-туннель. Политики безопасности могут определять различные параметры, такие как источник и назначение данных, протоколы, порты и другие факторы, чтобы контролировать доступ и обеспечивать безопасность соединения.
В #CloudMTS доступно создание Policy-based VPN-туннелей. Если вам требуется создать Route-based VPN-туннель, обратитесь в техническую поддержку любым удобным способом.
Создание VPN-туннеля
- В интерфейсе Network выберите сеть и перейдите в меню VPN-туннели.
- Нажмите на кнопку +Добавить.
- В окне Новый VPN-туннель заполните поля:
- Название — название VPN-туннеля.
- Описание — любая заметка.
- Peer address — публичный IPv4-адрес стороны Б, с которым будет установлено VPN-подключение.
- Peer ID — уникальный идентификатор стороны Б. Это может быть IP-адрес (IPv4 или IPv6), доменное имя или уникальный идентификатор узла. Peer ID используется для однозначного определения и проверки подлинности удаленного партнера, с которым устанавливается связь.
- IKE Profile — конфигурационный профиль, который определяет параметры и настройки для процесса установки и управления безопасным соединением, используя протокол IKE (Internet Key Exchange). IKE profile включает в себя различные параметры, которые определяют, как должно происходить взаимодействие между устройствами при установке и обслуживании безопасного соединения.
Рекомендуем использовать IKEv2 протокол, поскольку он представляет собой более современную версию протокола IKE с улучшенной безопасностью и производительностью.
- Preshared key — общий для Стороны А и Стороны Б секретный ключ, который используется для первоначальной проверки подлинности. Воспользуйтесь опцией Сгенерировать или введите собственный.
- Source Networks — IP-адреса и подсети, анонсируемые со стороны #CloudMTS.
- Destination Networks — IP-адреса и подсети, анонсируемые со стороны Б. Source и Destination Networks также должны быть симметрично настроены на стороне Б.
После того как VPN-туннель поднимется и будет находиться в статусе Активен, автоматически будут настроены правила отбора на стороне виртуальной сети для маршрутизации трафика из подсетей, указанных в поле Source Networks до подсетей, указанных в Destination Networks. Тем самым, дополнительной конфигурации на стороне #CloudMTS не требуется.
Протоколы и алгоритмы
IKE Profiles
IKE_V1
| Key | Value | Описание |
|---|---|---|
| Encryption Algorithm | AES128, AES256 | Используется для шифрования содержимого. Число — длина ключа в битах. |
| Digest Algorithm | SHA1, SHA2 256, SHA2 384, SHA2 512 | Используется для верификации отправителя и целостности сообщения (убедиться, что сообщение не было модифицировано по пути). |
| Diffie-Hellman | Group 16, Group 2, Group 5, Group 20, Group 21, Group 14, Group 15, Group 19 | Протокол, позволяющий сторонам сгенерировать общий секретный ключ, не обмениваясь секретными данными. Номер группы определяет максимальную длину ключа. Предпочтительной является группа 14 (2048 бит). |
IKE_V2
| Key | Value | Описание |
|---|---|---|
| Encryption Algorithm | AES 256, AES GCM 192, AES GCM 256, AES GCM 128, AES 128 | Используется для шифрования содержимого. Число — длина ключа в битах. |
| Digest Algorithm | SHA2 512, SHA1, SHA2 256, SHA2 384 | Используется для верификации отправителя и целостности сообщения (убедиться, что сообщение не было модифицировано по пути). |
| Diffie-Hellman | Group 16, Group 2, Group 5, Group 20, Group 21, Group 14, Group 15, Group 19 | Протокол, позволяющий сторонам сгенерировать общий секретный ключ, не обмениваясь секретными данными. Номер группы определяет максимальную длину ключа. Предпочтительной является группа 14 (2048 бит). |
IPSec Profiles
| Key | Value | Описание |
|---|---|---|
| Encryption Algorithm | AES 256, AES GCM 192, AES GCM 256, AES GCM 128, AES 128 | Используется для шифрования содержимого. Число — длина ключа в битах. |
| Digest Algorithm | SHA2 512, SHA1, SHA2 256, SHA2 384 | Используется для верификации отправителя и целостности сообщения (убедиться, что сообщение не было модифицировано по пути). |
| Diffie-Hellman | Group 16, Group 2, Group 5, Group 20, Group 21, Group 14, Group 15, Group 19 | Протокол, позволяющий сторонам сгенерировать общий секретный ключ, не обмениваясь секретными данными. Номер группы определяет максимальную длину ключа. Предпочтительной является группа 14 (2048 бит). |
DPD Profiles
| Key | Value | Описание |
|---|---|---|
| Probe Mode | Периодический | Периодическая проверка доступности соседа с помощью обмена служебными сообщениями. |
| Probe Interval (Seconds) | 60 | Интервал проверки |
| Retry Count | 10 | Количество повторов, если все неуспешные, то удаленная сторона считается недоступной. |
Как настроить VPN-туннель от облака до офиса
Работа в облаках зарекомендовала себя как достаточно безопасная. Хорошо устроенная офисная сеть, может быть, даже целая серверная также как правило хорошо защищены. Но как при полноценной работе в облаке, так и в гибридном варианте возникает брешь в защите: там, где данные передаются между офисом и облаком.
Сегодня наиболее эффективным средством защиты данных в этой ситуации является VPN-туннель. Это специальное соединение между устройствами, в котором все получаемые и передаваемые данные шифруются. Сетевая активность, осуществляемая в нём, полностью безопасна и недоступна для расшифровки никакому третьему лицу. Даже если кто-то данные получит, он не сможет их расшифровать, а случаи взлома корректно настроенных VPN-туннелей пока неизвестны.
Какие вообще бывают VPN?
Сегодня есть целый ряд VPN-технологий, к которым мы можем обратиться. Но какая подойдет больше всего?
- Старейший протокол туннелирования известен как PPTP, point-to-point tunneling protocol или «протокол туннелирования от точки к точке». Его просто настроить и легко установить, но он уже давно далёк от стандартов безопасности!
- L2TP, а также L2TP/IPsec или Layer 2 Tunneling Protocol (протокол второго уровня) шифрующий трафик с помощью IPsec-протокола. Его также легко настроить, зато он полностью защищает ваш трафик!
- OpenVPN — технология с открытым исходным кодом. Настроить сложно, на мобильных устройствах работает неустойчиво, а также требует стороннего ПО.
- Протокол майкрософта называется SSTP (Secure Socket Tunneling Protocol). Он используется в Windows-средах, хотя его поддерживают и системы *nix. Он использует https-трафик и позволяет подключать два серых адреса друг к другу через облако.
- Совместная работа майкрософта и циско IKEv2 (Internet Key Exchange) поддерживается в Windows, macOS и iOS.
Из этих пяти разновидностей мы выбираем IPSec VPN, который подходит также для безопасного подключения из дома к корпоративной сети или для объединения нескольких сетей (например, принадлежащих нескольким офисам). Даже среди прочих VPN именно IPSec является одним из наиболее криптостойких алгоритмов шифрования, при этом настраивается он достаточно просто. Для примера рассмотрим несколько вариантов его настройки, и начнём с того, который используем сами — создание VPN-тоннеля между офисом и облаком на основе Mikrotik RouterOS и роутера Mikrotik.
Как мы в Maxiplace строим VPN-туннели
У нас богатый опыт создания VPN-туннелей между офисом и облаком. Ниже мы расскажем о том, как нашим клиентам настроить VPN IPSEC Site-to-Site между виртуальным роутером в облаке и физическим в офисе.
Для начала нужно использовать ПО Cloud Hosted Router (поставляется в виде ISO) для превращения виртуалки в роутер. CHR — это версия Mikrotik RouterOS, созданные для установки на компьютеры и виртуальные машины. Его интерфейс полностью соответствует интерфейсу роутера Mikrotik. Как только вы установите CHR на виртуальную машину — запросите у нашей технической поддержки приватную сеть. Для примера мы будем использовать такие адреса:
Теперь давайте настроим первый маршрутизатор. Введите IP маршрутизатора, с которым будете соединяться, в поле Address, используя secret-ключ, с помощью которого будет осуществляться авторизация.
Теперь нужно настроить IPsec-политику, которая опишет случаи использования шифрования:
Настраиваем правила обхода NAT:
Также следим, чтобы правило находилось первым в списке и выше masquerade.
Чтобы настроить второй маршрутизатор, нужно сделать всё то же самое, только с поправкой на IP-адреса и сети. Если вам необходима полная инструкция, с ней можно ознакомиться в нашей Базе знаний.
Наконец, последним пунктом настройки обязательно должно быть тестирование. Если вы успешно установили соединение, то в поле Established появится таймер, указывающий, как давно оно установлено. Если он появился — выполните ping, чтобы проверить доступ к ресурсам офиса из облака:
Мост через глобальную сеть: как настроить туннель на Keenetic
Чтобы создать подключение IPsec VPN под названием site-to-site (на русском обычно звучит как «точка-точка») вам понадобятся два интернет-центра Keenetic. Один будет ожидать подключения и обозначаться как сервер, а второй инициировать его и обозначаться как клиент. Наш «сервер» обязательно должен обладать белым, то есть публичным постоянным IP-адресом. Клиенту достаточно будет серого. Вот между этими двумя точками мы и будем сооружать туннель.
Очевидно, что такой компонент системы как IPsec VPN нужно установить на обоих центрах, что можно осуществить в «Общих настройках» в «Обновлениях и компонентах», кнопка «Изменить набор компонентов».
Настраиваем сервер
Нам потребуется добавить подключение в разделе подключений IPsec в «Других подключениях». Для роли «сервера» нам нужно включить опцию ожидания подключения удаленного пира, а также опции Nailed-up и Dead Peer Detection. Первая будет поддерживать соединение активным и восстанавливать туннель при разрывах (этот параметр включается один раз, с одной стороны, в самом начале построения туннеля). Вторая будет определять работоспособность нашего VPN-тоннеля.
Настраивая первую фазу идентификатора локального шлюза можно использовать любой идентификатор, например, адрес IP, FQDN или DN («полное имя домена» и «имя домена»), почтовый адрес.
Обратите внимание! В первой фазе тоннеля идентификатор локального шлюза и идентификатор удалённого должны различаться. Укажите их крестообразно, например, если на клиенте локальный шлюз будет client, а удалённый server, то на сервере наоборот: локальный — сервер, а удалённый — client. При настройке тоннеля из облака в офис будет достаточно просто, а вот когда тоннелей станет несколько нужно будет помнить об уникальных обозначениях для каждого!
Настраивая вторую фазу укажем адреса локальной и удалённой сетей в соответствующих полях. Помните: тоннель не откроется, если настройки обоих фаз будут не идентичны.
Настроив обе фазы можем перевести переключатель подключения во включённое положение. Принимающая сторона туннеля открыта!
Настраиваем клиент
Настройка клиента зеркально похожа на настройку сервера. Начинаем так же: добавляем подключение в разделе подключений IPsec в «Других подключениях». В открывшемся уже знакомом окне нужно включить опцию автоподключения, что сделает настраиваемый клиент инициатором. Nailed-up уже включен на сервере и на этом конце можно данную опцию не трогать, а Dead Peer Detection включать по желанию.
Нужно заполнить поле «Удалённый шлюз»: туда вписываем IP-адрес или доменное имя нашего сервера. Затем просто настраиваем обе фазы зеркально серверу. Вуаля: можем включать туннель и с этой стороны.
Проверяем тоннель
Если все настройки были указаны верно, то тоннель должен открыться, а статус подключения будет отражаться в странице «Другие подключения». Чтобы проверить его работоспособность можно через него пингануть противоположный интернет-центр, хотя широковещательные запросы (вроде NetBIOS’а) через него не пройдут. Пинг может блокироваться межсетевыми экранами или фаерволом, а если ваш Keenetic не является основным шлюзом своей сети, то трафик может пойти мимо тоннеля.
Два программных роутера и тоннель между ними
Программные роутеры могут соединять любые сети, инфраструктуры или даже целые виртуальные центры обработки данных. В нашем случае один из них может быть установлен в офисе, а второй – в облаке у хостера. Технически каждый из них воплощён как отдельная виртуальная машина во вкладке Edges, а вся настройка будет происходить из вкладки IPsec VPN Sites.
Существует несколько настроек, которые нужно обязательно задать. Задаём мы их в модальном окне Add IPsec VPN, после того как перевели переключатель Enabled в активированное положение. Первый блок это:
- Name, которое может быть любым.
- Идентичные Local ID и Local Enpoint, отображающие внешний адрес (второе автоматически заполняется кнопкой Select).
- Адрес подсети целиком – в Local Subnet.
Далее идёт блок клиентских настроек:
- Peer ID – имя подключаемого центра, совпадает с Peer Endpoint.
- Peer Endpoint – публичный IP-адрес второго роутера.
- Peer Subnets – подсеть, которую мы соединяем. Через запятую можно указать несколько сетей.
Сохраняем изменения и переходим во вкладку Activation Status, чтобы активировать IPsec VPN Service Status. Всё, мы настроили первый из роутеров — второй просто настраиваем зеркально. То есть соответствие между двумя роутерами такое:
| Local ID | Peer ID |
| Local Endpoint | Peer Endpoint |
| Local Subnets | Peer Subnets |
| Peer ID | Local ID |
| Peer Endpoint | Local Endpoint |
| Peer Subnets | Local Subnets |
После этого остается только проверить работоспособность нашего тоннеля! Это делается с помощью инструмента статистики из соответствующего раздела в Edge Gateway. Если мы всё настроили правильно, то Channel Status будет показывать галочку.
Итоги
IPsec-соединение — самое безопасное VPN-соединение для нашей задачи. Его функциональность может быть гораздо шире! Но для работы с облачным решением из офиса оно и так подходит идеально, а в будущем его можно будет легко масштабировать. Ну а нашим клиентам не обязательно учиться создавать такие туннели, потому что каждому из них мы готовы открыть IPsec VPN бесплатно. Для этого нужно создать тикет, указав требуемые характеристики: протокол маршрутизации, внешний IP и метод шифрования.
Статья добавлена 1 год назад. Автор — Blog Admin
Как сделать VPN-туннель для недружественного почтового сервера
В предыдущей статье, где рассказывалось о признании моего почтового сервера «недружественным», я упоминал о том, что смог обойти введённые ограничения с помощью аренды дополнительного виртуального сервера на территории РФ и проброса до него VPN-туннеля от основного сервера. После публикации статьи мне пришло несколько личных сообщений с просьбой рассказать подробнее о процессе настройки такого туннеля. В этой статье я постараюсь как можно более подробно описать этот процесс.
Введение
В статье предполагается, что на всех серверах установлена ОС Ubuntu 20.04, а в качестве почтового сервера используется Postfix. В целом, описанные здесь методы, скорее всего, будут применимы к любому дистрибутиву Linux, а также и к другим UNIX-подобным ОС (например, FreeBSD), но вам нужно будет сделать поправки в части используемого менеджера пакетов, фаервола и, возможно, настроек сетевой маршрутизации.
Добавлю также, что VPN-туннель между серверами можно использовать не только для почты, но и для проксирования любого другого протокола, где важно знать оригинальный IP-адрес клиента и где невозможно получить его каким-то иным способом, кроме как средствами нижележащего протокола транспортного уровня (TCP или UDP). Например, для HTTP достаточно простого обратного прокси, так как в нём реальный IP можно передавать с помощью заголовков X-Forwarded-For. В случае с SMTP также возможна настройка промежуточного почтового сервера (релея), но по сравнению с поднятием VPN это гораздо более трудоёмкая задача, поэтому рассматривать такой вариант мы здесь не будем.
Сценарий использования
Наш сценарий использования можно описать следующим образом. У нас есть основной сервер (назовём его mail.mydomain.com), который принимает и отправляет электронную почту. При этом существует определённый почтовый домен (например, unfriendly.org), MX-сервера которого не принимают входящие соединения от mail.mydomain.com из-за его «недружественности», не позволяя ему слать почту на адреса @unfriendly.org. Приём почты от @unfriendly.org тоже не работает по аналогичным причинам.
Мы арендуем дополнительный сервер-шлюз (назовём его vpn.mail.mydomain.com), который для MX unfriendly.org «недружественным» не является, и хотим установить между нашим шлюзом и основным сервером VPN-туннель, чтобы иметь возможность обмениваться почтой между @unfriendly.org и mail.mydomain.com.
Отдельно отметим, что мы НЕ хотим, чтобы все исходящие соединения с mail.mydomain.com шли через VPN — через наш шлюз должны идти соединения только при отправке на @unfriendly.org (и другие проблемные домены, если они есть), а все остальные соединения должны идти напрямую. В итоге должна получиться следующая схема:
Для поднятия туннеля будем использовать OpenVPN. Я использовал информацию из вот этого руководства по его настройке в качестве стартовой точки. Сначала нам нужно установить пакет OpenVPN в систему. Рекомендую устанавливать его из официального репозитория, для этого выполняем следующие команды:
# wget -O - https://swupdate.openvpn.net/repos/repo-public.gpg | apt-key add - # echo "deb http://build.openvpn.net/debian/openvpn/stable focal main" > /etc/apt/sources.list.d/openvpn-aptrepo.list # apt update && apt install openvpnДалее перемещаемся в папку /etc/openvpn/server и генерируем общий ключ для TLS-аутентификации (мы будем использовать его и на сервере, и на клиенте):
$ cd /etc/openvpn/server $ sudo openvpn --genkey secret ta.keyТеперь создадим файл конфигурации сервера server.conf в той же папке. Ниже привожу содержимое этого файла с дополнительными комментариями:
# Понижаем привилегии процесса после запуска # в целях безопасности (необязательно) user nobody group nogroup # Используем виртуальный драйвер TUN (сетевой уровень) dev tun # Здесь я использовал нестандартный порт, # но можно использовать любой другой. # По умолчанию используется порт 1194 port 6876 # Рекомендуется использовать протокол UDP. # Чтобы понять, почему - гуглим "TCP Meltdown" proto udp # Сертификаты и приватные ключи. # Мы создадим их на следующих шагах данного руководства ca ca.crt cert vpn.mail.mydomain.com.crt key vpn.mail.mydomain.com.key # Настройки шифрования и аутентификации TLS. # Мы будем использовать эллиптические кривые, # поэтому алгоритм DHE можно отключить dh none tls-crypt ta.key cipher AES-256-GCM auth SHA512 # Сетевые настройки topology subnet server 172.16.0.0 255.255.255.0 keepalive 10 120 # В этой папке будем хранить настройку # статического IP-адреса для клиента client-config-dir /etc/openvpn/server/ccd # Необходимо при понижении привилегий persist-key persist-tun # Отправляем уведомление клиенту при остановке/перезапуске сервера explicit-exit-notify 1 # Уровень логирования verb 3Чтобы установить статический IP-адрес в VPN-сети для нашего почтового сервера, создадим папку /etc/openvpn/server/ccd и добавим туда файл mail.mydomain.com со следующей строчкой:
ifconfig-push 172.16.0.2 255.255.255.0Локальный IP-адрес сервера (vpn.mail.mydomain.com) будет 172.16.0.1, клиента (mail.mydomain.com) — 172.16.0.2.
Дополнительно вы можете жёстко задать параметры шифрования для использования эллиптических кривых, особенно если у вас другая ОС с более старой версией OpenSSL, где могут поддерживаться не все современные наборы шифров. Как это сделать, см. здесь (спасибо за материал пользователю @Maxim_Q).
Настройка фаервола
В Ubuntu 20.04 в качестве фаервола используется ufw , который является фронтендом для популярного в Linux iptables . Помимо правил, добавляемых с помощью команд, в ufw есть конфигурационные файлы, позволяющие прописывать дополнительные правила в формате iptables . Откроем файл /etc/ufw/before.rules и добавим в начало следующие строчки:
*nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 25 -j DNAT --to-destination 172.16.0.2:25 -A POSTROUTING -s 172.16.0.0/24 -o eth0 -j MASQUERADE COMMITЗдесь добавляется два правила в таблицу NAT:
- -A PREROUTING . перенаправляет входящие TCP-соединения на 25-й порт с интерфейса eth0 на адрес 172.16.0.2 (то есть на наш почтовый сервер mail.mydomain.com).
- -A POSTROUTING . разрешает исходящие соединения из локальной VPN-сети на интерфейс eth0 (в интернет) путём настройки SNAT для исходящих пакетов.
NB: Проверьте (например, через ifconfig ), что ваш основной сетевой интерфейс называется именно eth0 . Если это не так, укажите в правилах корректное название.
Дополнительно нужно включить и разрешить форвардинг IPv4-пакетов. Для этого сначала отредактируем /etc/sysctl.conf и раскомментируем в нём строчку net.ipv4.ip_forward=1 . Затем применим новые настройки с помощью команды:
# sysctl -pТеперь в файле /etc/default/ufw находим строчку DEFAULT_FORWARD_POLICY=»DROP» и меняем DROP на ACCEPT. Осталось только включить ufw и разрешить через него входящие SMTP- и OpenVPN-соединения. Не забываем также разрешить и SSH-соединения, чтобы не заблокировать себе доступ:
# ufw allow ssh # ufw allow 25/tcp # ufw allow 6876/udp # ufw enableNB: Не забудьте указать корректный номер порта OpenVPN вместо 6876, если вы используете другой порт (например, стандартый 1194).
Установка и настройка VPN-клиента
Сначала на машину mail.mydomain.com нужно установить пакет OpenVPN — делаем это таким же способом, как на VPN-сервере. Затем копируем сгенерированный на предыдущем этапе общий ключ ta.key с VPN-сервера в папку /etc/openvpn/client . Далее создаём конфигурационный файл /etc/openvpn/client/client.conf :
client # Понижаем привилегии процесса после запуска # в целях безопасности (необязательно) user nobody group nogroup # Используем виртуальный драйвер TUN и протокол UDP dev tun proto udp # Настройки подключения к удалённому серверу remote vpn.mail.mydomain.com 6876 resolv-retry infinite nobind # Сертификаты и приватные ключи. # Мы создадим их на следующих шагах данного руководства ca ca.crt cert mail.mydomain.com.crt key mail.mydomain.com.key remote-cert-tls server # Настройки шифрования и аутентификации TLS tls-crypt ta.key cipher AES-256-GCM auth SHA512 auth-nocache # Скрипт для настройки маршрутизации после поднятия туннеля. # Мы создадим его на предпоследнем этапе данного руководства script-security 2 up openvpn_routes.sh # Необходимо при понижении привилегий persist-key persist-tun # Уровень логирования verb 3Замечание
Если вы понижаете привилегии процесса OpenVPN, то при остановке клиента или сервера через systemctl или при перезагрузке системы будете наблюдать в логе сообщения вида:
MMM dd HH:mm:ss mail.mydomain.com openvpn[123456]: RTNETLINK answers: Operation not permitted MMM dd HH:mm:ss mail.mydomain.com openvpn[123456]: Linux ip addr del failed: external program exited with error status: 2Объясню, в чём дело: OpenVPN хочет удалить маршрут к VPN-подсети из системы, но не может этого сделать из-за пониженных привилегий (с добавлением маршрута проблем нет, так как привилегии понижаются не сразу, а после завершения начальной настройки). Но это не является чем-то критичным, так как маршрут всё равно пропадает автоматически после удаления туннельного сетевого интерфейса, что как раз и происходит при остановке OpenVPN.
Если вы всё же хотите избавиться от этих сообщений, можно попробовать сделать это, например, вот так. Я этот метод не пробовал, поэтому не могу сказать, будут ли здесь какие-то ещё проблемы, но лично мне этот вариант кажется не очень безопасным, так как он, по сути, сводится к разрешению выполнения команды ip для непривилегированных пользователей.
Выпуск сертификатов для аутентификации
Альтернативный вариант
Если вам лень возиться с настройкой собственного центра сертификации, можно попробовать использовать другой способ аутентификации — статический ключ. Вот здесь описывается, как это сделать. Вам нужно будет подправить конфигурацию и удалить все упоминания о сертификатах, а также убрать client-config-dir и прописать настройки IP-адресов вручную на стороне клиента и сервера. Убедитесь, что сервер запускается, путём выполнения команды:
# systemctl start openvpn-server@serverЕсли что-то пошло не так, проверьте лог:
# journalctl -u openvpn-server@server -eТакже стоит добавить сервер в автозагрузку с помощью следующей команды:
# systemctl enable openvpn-server@serverЕсли всё в порядке, то переходите к следующему разделу данного руководства «Настройка маршрутизации».
OpenVPN по умолчанию использует сертификатную аутентификацию. Это значит, что при подключении клиент и сервер должны обменяться X.509-сертификатами, подписанными доверенным удостоверяющим центром (УЦ). Такой центр мы создадим самостоятельно и сначала выпустим корневой сертификат, который установим и на сервер, и на клиент, а затем создадим и подпишем для них пользовательские сертификаты.
Почему мы не можем использовать для выпуска сертификата, например, сервис Let’s Encrypt? Всё просто: если наш VPN-сервер будет доверять УЦ Let’s Encrypt, то без дополнительных настроек кто угодно сможет запросить у них сертификат и использовать его для подключения к нашему VPN, чего мы, конечно же, не хотим. Поэтому мы развернём свой собственный центр сертификации, работу которого мы можем контролировать. В этом нам поможет пакет EasyRSA, представляющий собой обёртку над популярной утилитой OpenSSL.
Отметим также, что УЦ на базе EasyRSA необязательно устанавливать именно на VPN-сервер, более того, такой вариант менее безопасен, так как на сервере будет храниться приватный ключ вашего центра сертификации, которым можно подписывать пользовательские сертификаты и таким образом управлять доступом к вашему VPN-серверу. Оптимальный вариант — установить УЦ на ваш домашний компьютер, ноут и т.д. (если вы параноик, можете вообще отключить его от сети и передавать все данные на флешках).
Пакет EasyRSA используется не только для создания центра сертификации, но и для генерации приватных ключей и запросов на выпуск сертификатов. Работает это так:
- На сервере vpn.mail.mydomain.com генерируем пару «приватный ключ» — «запрос на сертификат».
- Отправляем файл запроса в УЦ.
- УЦ создаёт и подписывает сертификат и отправляет его обратно на сервер.
- Аналогичные операции проводим на машине mail.mydomain.com.
Обратите внимание, что ни один приватный ключ (в том числе ключ самого УЦ) не покидает машины, на которой он генерируется. Это одно из важных преимуществ использования криптосистемы с открытым ключом.
Установка центра сертификации
Как уже говорил ранее, этот шаг желательно выполнять на отдельной машине. Для упрощения будем полагать, что на ней также стоит Ubuntu 20.04.
Сначала установим пакет easy-rsa:
# apt update && apt install easy-rsaТеперь создадим в домашнем каталоге папку easyrsa , в которой будем хранить настройки, сертификат и приватный ключ нашего УЦ:
$ cd ~ $ mkdir easyrsa $ chmod 700 easyrsaДобавим во вновь созданную папку символьные ссылки на исполняемые и конфигурационные файлы EasyRSA, чтобы не обновлять их каждый раз вручную при обновлении пакета:
$ ln -s /usr/share/easy-rsa/* ~/easyrsa/Начиная с версии 2.4, в OpenVPN возможно использование криптографии на эллиптических кривых, которая является более надёжной по сравнению с традиционным RSA. Чтобы использовать эллиптические кривые (в данном случае предлагается кривая secp521r1), создадим файл ~/easyrsa/vars со следующим содержимым:
set_var EASYRSA_ALGO "ec" set_var EASYRSA_CURVE "secp521r1" set_var EASYRSA_DIGEST "sha512"Далее выполняем команды:
$ cd ~/easyrsa $ ./easyrsa init-pkiНа момент написания данного текста в версии OpenSSL в Ubuntu 20.04 есть небольшой баг, из-за которого при генерации ключей может появляться сообщение вида random number generator:RAND_load_file:Cannot open file (источник). Оно не свидетельствует о критической ошибке, но от него можно избавиться, создав указанный файл вручную:
$ dd if=/dev/urandom of=pki/.rnd bs=256 count=1Осталось инициализировать сам УЦ:
$ ./easyrsa build-caВ ходе создания УЦ вас попросят ввести парольную фразу — рекомендуется сделать её достаточно сложной, чтобы её нельзя было подобрать. Также нужно будет задать имя (Common Name) для вашего УЦ — можно использовать в качестве него, например, имя хоста вашей машины. Если вы пропустите этот шаг, по умолчанию будет использоваться имя «Easy-RSA CA», не являющееся особо примечательным, поэтому рекомендую вместо него задать своё имя — тогда при проверке выпущенных сертификатов будет сразу понятно, что они подписаны именно вашим УЦ.
Выпуск сертификата для VPN-сервера
Теперь займёмся выпуском сертификата для OpenVPN-сервера на машине vpn.mail.mydomain.com. Для этого на неё сначала необходимо установить пакет EasyRSA и выполнить все команды до init-pki включительно (см. выше). Далее нам необходимо сгенерировать приватный ключ и запрос на сертификат, который мы отправим в наш УЦ:
$ ./easyrsa gen-req vpn.mail.mydomain.com nopassОбратите внимание на параметр nopass — если его не указать, то EasyRSA попросит вас задать парольную фразу для генерируемого ключа, и VPN-сервер каждый раз при запуске будет её запрашивать (по очевидным причинам нам такой вариант не подходит). Также в ходе выполнения команды gen-req у вас снова запросят имя (Common Name), на этот раз для будущего сертификата — тут можно просто нажать Enter, чтобы использовать имя, которое вы указали в параметрах команды. В итоге у вас должны сгенерироваться два файла:
~/easyrsa/pki/private/vpn.mail.mydomain.com.key — это приватный ключ. Его необходимо переместить в папку /etc/openvpn/server , предварительно сменив владельца на root :
$ cd ~/easyrsa/pki/private/ $ sudo -s # chown root:root vpn.mail.mydomain.com.key # mv vpn.mail.mydomain.com.key /etc/openvpn/server/~/easyrsa/pki/reqs/vpn.mail.mydomain.com.req — это запрос на создание сертификата. Этот файл необходимо переместить на машину УЦ в любую папку (например, /tmp ), затем на ней же выполнить команды:
$ cd ~/easyrsa $ ./easyrsa import-req /tmp/vpn.mail.mydomain.com.req vpn.mail.mydomain.com $ ./easyrsa sign-req server vpn.mail.mydomain.comУбеждаемся, что Common Name в запросе на сертификат совпадает с именем хоста соответствующей машины (в данном случае vpn.mydomain.com) и, если всё верно, вводим «yes», после этого вас ещё попросят ввести парольную фразу, которую вы придумали ранее при создании УЦ. Сертификат будет сгенерирован по следующему пути: ~/easyrsa/pki/issued/vpn.mail.mydomain.com.crt . Берём его вместе с корневым сертификатом УЦ, который находится в ~/easyrsa/pki/ca.crt , и копируем на VPN-сервер в папку /etc/openvpn/server . Не забываем про настройки владельца и права доступа для этих файлов ( chown root:root и chmod 600 соответственно).
На данном этапе настройка VPN-сервера завершена. Чтобы запустить сервер, выполняем на нём команду:
# systemctl start openvpn-server@serverЧтобы добавить сервер в автозагрузку, выполняем:
# systemctl enable openvpn-server@serverЕсли при запуске возникла ошибка, посмотреть лог можно с помощью следующей команды:
# journalctl -u openvpn-server@server -eНаиболее частые ошибки возникают из-за проблем с конфигурацией (опечатки, пропуски) или отсутствия необходимых файлов (сертификат, приватный ключ и т.д.). Также, если вы неправильно настроили права доступа к файлам сертификатов и ключей, в логе появится предупреждение об этом.
Выпуск сертификата для VPN-клиента
Как и на VPN-сервере, на машине mail.mydomain.com тоже нужно установить пакет EasyRSA и выполнить init-pki . После этого создаём приватный ключ и запрос на сертификат:
$ ./easyrsa gen-req mail.mydomain.com nopassПеремещаем сгенерированный приватный ключ из ~/easyrsa/pki/private/mail.mydomain.com.key в папку /etc/openvpn/client , не забывая про смену владельца:
$ cd ~/easyrsa/pki/private/ $ sudo -s # chown root:root mail.mydomain.com.key # mv mail.mydomain.com.key /etc/openvpn/client/Затем отправляем файл запроса ~/easyrsa/pki/reqs/mail.mydomain.com.req на машину УЦ (например, в /tmp ), импортируем, выпускаем сертификат:
$ cd ~/easyrsa $ ./easyrsa import-req /tmp/mail.mydomain.com.req mail.mydomain.com $ ./easyrsa sign-req client mail.mydomain.comЕщё раз вводим «yes» (предварительно убедившись, что Common Name совпадает с mail.mydomain.com) и парольную фразу. Как и в предыдущий раз, сертификат создаётся по пути: ~/easyrsa/pki/issued/mail.mydomain.com.crt . Копируем его и корневой сертификат из ~/easyrsa/pki/ca.crt на машину mail.mydomain.com в папку /etc/openvpn/client , в очередной раз не забывая про настройку прав доступа.
На этом, казалось бы, всё, и VPN-клиент готов к работе, но остаётся ещё один момент — маршрутизация. Не забыли про строчку up openvpn_routes.sh в конфигурации клиента? Сейчас мы с этим разберёмся.
Настройка маршрутизации на VPN-клиенте
Напомню, что наш сценарий заключается в том, что направлять через VPN мы хотим не весь интернет-трафик, а только определённые соединения. Здесь есть небольшая проблема, так как обычно для всех исходящих интернет-соединений используется шлюз по умолчанию, ассоциированный с основным сетевым интерфейсом (например, eth0 ). Напомню, что на VPN-сервере мы специально не включали SNAT для входящих IP-пакетов, так как при подключении к почтовому серверу нам важно видеть реальный IP-адрес удалённой стороны вместо локального адреса VPN-сервера (172.16.0.1). Если ничего не настраивать, то при входящем соединении через VPN ответ этому IP-адресу, согласно правилам маршрутизации, почтовый сервер отправит через основной сетевой интерфейс. Очевидно, что ни к чему хорошему это привести не может.
Решением данной проблемы является создание альтернативной таблицы маршрутизации и задание правил для её использования. Источником для написания данного раздела послужила эта статья.
Сначала нам нужно указать системе, что мы создаём новую таблицу маршрутизации. В данном руководстве она будет называться openvpn . Создадим файл /etc/iproute2/rt_tables.d/openvpn.conf с единственной строчкой:
1 openvpnТеперь создаём shell-скрипт /etc/openvpn/client/openvpn_routes.sh со следующим содержимым:
#!/bin/bash ip route add default via 172.16.0.1 dev $dev table openvpn ip rule add from 172.16.0.2 table openvpn ip rule add to 172.16.0.2 table openvpnНе забываем сделать его исполняемым:
# chmod +x /etc/openvpn/client/openvpn_routes.shСогласно настройкам клиента, этот скрипт будет выполняться каждый раз после поднятия туннельного сетевого интерфейса. Давайте разберёмся, что здесь происходит:
- Команда ip route add default . добавляет маршрут со шлюзом по умолчанию 172.16.0.1 (локальный IP нашего VPN-сервера) через интерфейс $dev в таблицу маршрутизации openvpn . Значение параметра $dev устанавливается самим клиентом OpenVPN перед запуском скрипта и содержит название туннельного интерфейса для VPN-соединения (обычно это tun0 ).
- Команда ip rule add from . добавляет правило маршрутизации, предписывающее использовать таблицу openvpn для всех исходящих соединений с IP-адреса 172.16.0.2 (это локальный IP нашего VPN-клиента).
- Команда ip rule add to . добавляет аналогичное правило маршрутизации, но оно относится уже к входящим соединениям.
Таким образом, после выполнения данного скрипта все соединения, где одной из конечных точек является локальный IP-адрес машины mail.mydomain.com в VPN-туннеле (т.е. 172.16.0.2), будут маршрутизироваться через этот туннель. Чтобы проверить это, сначала поднимаем клиент:
# systemctl start openvpn-client@clientРекомендую также добавить его в автозапуск:
# systemctl enable openvpn-client@clientЕсли клиент стартовал без ошибок, для начала рекомендую попинговать 172.16.0.1, чтобы убедиться, что соединение с сервером действительно есть. Теперь попробуем соединиться через VPN с сервисом telnetmyip.com, чтобы убедиться, что маршрутизация работает корректно. С помощью telnet это можно сделать так:
$ telnet -b 172.16.0.2 telnetmyip.comУ меня этот сервис почему-то ничего не выводит, а просто закрывает соединение (возможно, из-за той же пресловутой «недружественности»). В этом случае можно попробовать ещё через curl :
$ curl --interface 172.16.0.2 telnetmyip.comВы получите ответ вида:
< "comment": "## Your IP Address is WW.XX.YY.ZZ () ##", "family": "ipv4", "ip": "WW.XX.YY.ZZ", . >Если WW.XX.YY.ZZ совпадает с внешним IP-адресом машины vpn.mail.mydomain.com, то поздравляю — всё настроено корректно! Замечу, что в случае некорректной настройки вам, скорее всего, вообще не удастся установить соединение.
Входящие соединения можно проверить, подключившись с помощью telnet к vpn.mail.mydomain.com на порт 25 с любой сторонней машины (например, с домашней — если, конечно, ваш интернет-провайдер не блокирует 25-й порт на выход). При этом в логах почтового сервера должен появиться ваш реальный внешний IP-адрес, а не локальный адрес VPN-сервера 172.16.0.1.
Настройка Postfix
Приём почты
Чтобы принимать в Postfix входящие соединения через VPN-туннель, вам не нужно менять никаких настроек — достаточно лишь добавить в DNS вторую MX-запись для вашего почтового домена, указав в ней имя хоста vpn.mail.mydomain.com. Рекомендуется поставить ей низкий приоритет (например, если для основной записи у вас приоритет 10, ставьте 100), чтобы соединения через VPN-шлюз шли только тогда, когда доступ к основному серверу заблокирован с удалённой стороны.
Единственное, что здесь стоит отметить — при соединении с vpn.mail.mydomain.com ваш сервер будет представляться как mail.mydomain.com. Это не должно повлиять на доставку почты, но если вы хотите сделать всё «по феншую», то нужно будет немного пошаманить с конфигурацией. Здесь есть два варианта, которые сводятся к тому, чтобы в /etc/postfix/master.cf создать дополнительный SMTP-сервер, который будет принимать соединения через VPN, и прописать ему нужное значение myhostname .
Первый вариант: привязать второй SMTP-сервер к IP-адресу в локальной VPN-сети, вот так это будет выглядеть в master.cf :
172.16.0.2:smtp inet n - y - - smtpd -o syslog_service_name=postfix/vpn -o myhostname=vpn.mail.mydomain.comПроблема здесь в том, что если VPN-туннель не поднят, при запуске Postfix выдаст фатальную ошибку: «fatal: bind 172.16.0.2 port 25: Cannot assign requested address». Поэтому я считаю такой способ не очень надёжным (например, если OpenVPN почему-то откажется запускаться, то Postfix тоже не сможет стартовать). Но можно поступить чуть хитрее, а именно — создать сервер, привязанный к другому порту. В примере ниже используется порт 4925 вместо стандартного 25:
4925 inet n - y - - smtpd -o syslog_service_name=postfix/vpn -o myhostname=vpn.mail.mydomain.comЧтобы это заработало, на VPN-сервере нужно отредактировать файл /etc/ufw/before.rules : в правиле -A PREROUTING . , которое мы создавали при настройке сервера, нужно поменять в конце порт 25 на 4925. Затем выполнить команду:
# service ufw restartNB: Если после этого вы видите, что на стороне Postfix подключение идёт всё ещё на 25-й порт — попробуйте перезагрузить VPN-сервер.
Теперь при подключении к vpn.mail.mydomain.com сервер представится вам именно этим именем. Обратите внимание, что мы также указали для нового сервера syslog_service_name=postfix/vpn , чтобы в логе было видно, как маршрутизируется соединение:
MMM dd HH:mm:ss mail.mydomain.com postfix/vpn/smtpd[12345]: connect from unknown[WW.XX.YY.ZZ]Если вы используете postscreen и хотите отвечать корректным именем при подключении через VPN, то помимо второго SMTP-сервера нужен будет второй postscreen с соответствующими настройками. Выглядеть это будет так:
4925 inet n - y - 1 postscreen -o syslog_service_name=postfix/vpn -o myhostname=vpn.mail.mydomain.com -o smtpd_service_name=vpn-smtpd -o postscreen_cache_cleanup_interval=0 vpn-smtpd pass - - y - - smtpd -o syslog_service_name=postfix/vpn -o myhostname=vpn.mail.mydomain.comДополнительно вам нужно будет настроить postscreen так, чтобы он обращался к файлу кэша через proxymap , иначе получите фатальную ошибку из-за невозможности эксклюзивной блокировки этого файла. Добавляем в /etc/postfix/main.cf :
postscreen_cache_map = proxy:btree:/var/lib/postfix/postscreen_cacheОтправка почты
Для отправки почты через VPN-сервер в первую очередь, конечно, нужно убедиться, что разрешены исходящие соединения по 25-му порту и что у сервера всё в порядке с PTR, SPF и спам-листами. Если с этим проблем нет, то можно приступить к настройке.
Сначала создадим в /etc/postfix/master.cf отдельный SMTP-клиент и укажем ему значение smtp_bind_address , соответствующее локальному IP-адресу нашего почтовика в VPN-сети — в нашем случае это 172.16.0.2. По умолчанию, если Postfix не может выполнить биндинг на smtp_bind_address , он логирует предупреждение и повторяет попытку отправки уже с основного адреса. Postfix 3.7 содержит полезную настройку smtp_bind_address_enforce , которую мы можем включить для предотвращения подобного поведения: в этом случае, если VPN-туннель временно не работает, письмо просто вернётся в очередь для повторной отправки.
vpn-smtp unix - - y - - smtp -o syslog_service_name=postfix/vpn -o myhostname=vpn.mail.mydomain.com -o smtp_bind_address=172.16.0.2 # для Postfix 3.7 и выше -o smtp_bind_address_enforce=yes Теперь настроим выборочную отправку писем на определённые домены через VPN. В нашем примере мы хотим отправлять через VPN письма на @unfriendly.org. Создаём файл /etc/postfix/vpn_transport со следующей строчкой:
unfriendly.org vpn-smtpи добавляем в /etc/postfix/main.cf :
transport_maps = hash:/etc/postfix/vpn_transportДалее выполняем команды:
# postmap /etc/postfix/vpn_transport # systemctl reload postfixи пробуем отправить письмо на любой адрес в домене unfriendly.org, затем убеждаемся, что при отправке этого письма вы видите в логе не postfix/smtp , а postfix/vpn/smtp . Аналогичным образом можно добавлять в /etc/postfix/vpn_transport другие почтовые домены, не забываем только каждый раз делать postmap и reload . Конечно, необязательно использовать именно формат hash для хранения транспортной таблицы — вы можете хранить эти данные в любом другом удобном вам формате (при условии, что он поддерживается в Postfix), в том числе в каком-нибудь MySQL/MariaDB.
Заключение
В данной статье мы рассмотрели простой способ создания альтернативного канала связи между почтовым сервером и внешним миром, который можно использовать, если по каким-то причинам (например, из-за «недружественности») связь с определёнными MX-хостами через основной канал не работает. Можно отметить следующие достоинства данного способа:
- Простота настройки, особенно по сравнению с поднятием полноценного резервного почтового сервера (backup MX);
- Возможность горизонтального масштабирования: при необходимости можно арендовать ещё один сервер и быстро поднять ещё один резервный канал — вследствие простоты настройки на это уйдёт совсем немного времени;
- Никакие данные не хранятся на VPN-сервере, что особенно важно, если он расположен в РФ;
- Для VPN-сервера можно выбирать самую дешёвую конфигурацию, так как OpenVPN не затрачивает большого количества ресурсов системы, если речь идёт об одном клиенте с небольшими объёмами трафика (что как раз применимо к нашему случаю).
Недостатком данного решения является привязка VPN-шлюза к конкретному почтовому серверу. Если ваша почтовая инфраструктура содержит несколько серверов, развёртывание туннеля может быть затруднено.
Ещё одной потенциальной проблемой, хоть и не связанной непосредственно с VPN, является ручная настройка списка «недружественных» почтовых доменов — при большом количестве пользователей на почтовом сервере это может быть просто неудобно. В теории можно попробовать автоматизировать этот процесс, написав свой собственный сервис, который будет пытаться устанавливать соединение с MX-серверами получателя с разных сетевых интерфейсов и, в зависимости от результатов, выбирать для передачи письма прямой SMTP-транспорт или VPN — но эта тема уже выходит за рамки данной статьи.
- Системное администрирование
- *nix