Polytech-soft.com

ПК журнал
3 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Ipsec vpn что это

Пример настройки туннеля IPSec VPN с компьютера из ОС Windows

NOTE: Важно! Если вы планируете настроить Keenetic в качестве VPN-сервера, начать необходимо с проверки того, что он имеет публичный «белый» IP-адрес, а при использовании доменного имени KeenDNS, что оно настроено в режиме «Прямой доступ». При несоблюдении любого из этих условий подключение к такому серверу из Интернета будет невозможно.

В нашем примере для VPN IPSec-подключения мы будем использовать бесплатное ПО Shrew VPN Client, скачать его можно с сайта производителя: https://www.shrew.net/download
Установите VPN-клиент и проверьте, что установился специальный драйвер для работы Shrew (в Свойствах сетевого подключения должна стоять галочка напротив Shrew Soft Lightweight Filter).

Запустите VPN Access Manager.

9. После запуска откроется окно программы.

10. Нажмите кнопку Add для создания VPN-подключения.

11. На вкладке General нужно указать настройки:

  • Host Name or IP address — внешний/публичный IP-адрес Keenetic (в нашем случае 46.72.181.99);
  • Auto Configuration: disabled;
  • Adapter Mode: Use an existing adapter and current address.

12. На вкладке Client оставьте значения по умолчанию.

13. На вкладке Name Resolution снимите галочки Enable DNS и Enable WINS.

14. На вкладке Authentication укажите следующие параметры:

  • Authentification Method: Mutual PSK;
  • Local Identifity > Identification Type: IP AddressAddress String: 192.168.221.33 и снимите галочку Use a discovered local host address;
  • Remote Identifity> Identification Type: IP AddressAddress String: 192.168.222.1 и снимите галочку Use a discovered local host address;
  • Credentials> Pre Shared Key: 12345678.

15. На вкладке Phase1 укажите:

  • Exchange Type: main;
  • DH Exchange: group 1;
  • Cipher Algorithm: des;
  • Hash Algorithm: md5;
  • Key Life Time limit: 3600.

16. На вкладке Phase 2 укажите:

  • Transform Algorithm: esp-des;
  • HMAC Algorithm: md5.

Внимание! Настройки фаз 1 и 2 должны совпадать с аналогичными параметрами, установленными на устройстве, с которым будет устанавливаться VPN-туннель.

17. На вкладке Policy снимите галочку Obtain Topology Automatically or Tunnel All, нажмите Add и укажите локальную подсеть за Keenetic.

Нажмите OK и Save для сохранения настроек.

18. В списке подключений появится созданное VPN-соединение.

19. Дважды щелкните по ярлыку VPN-подключения и нажмите в открывшемся окне Connect для запуска VPN-соединения.
В итоге вы должны увидеть последнюю запись: tunnel enabled (данное сообщение означает, что успешно установлена фаза 1 туннеля).

20. Для завершения установки VPN-туннеля нужно с компьютера (из командной строки Windows) запустить трафик в направлении удаленной подсети, находящейся за роутером Keenetic.
Например, сделать это можно командой ping (в нашем примере выполняется пинг IP-адреса роутера 192.168.222.1).

21. Для отключения туннеля в VPN Access Manager нажмите кнопку Disconnect.

Пример настройки IPSec-подключения на ответной стороне VPN-сервера:

Примечание

  • Если наблюдаются разрывы VPN-подключения, попробуйте на Keenetic отключить опции Nailed-up и Обнаружение неработающего пира (DPD).
    Nailed-up (данная настройка предназначена поддерживать работу туннеля в простое, т.е. когда нет передачи трафика, и восстанавливать его при разрыве).
    Обнаружение неработающего пира DPD (данная функция проверяет работоспособность туннеля, посылая Hello-пакеты, на которые удаленная сторона должна прислать ответ).
  • На компьютере с ОС Linux также можно воспользоваться бесплатным программным VPN-клиентом Shrew Soft VPN Client. Загрузить программу можно с сайта разработчика https://www.shrew.net/download или найти её и установить через Центр приложений операционной системы.
    Shrew Soft VPN Client успешно работает в операционных системах FreeBSD, NetBSD, Fedora Core и в различных дистрибутивах Ubuntu Linux (Mint, Xubuntu и др.) на платформах x86 и amd64.

Пользователи, считающие этот материал полезным: 21 из 27

ИТ База знаний

Полезно

— Узнать IP — адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Популярное и похожее

Что такое технология DPI?

Что такое IPS, IDS, UTM?

Анатомия защищенного соединения в беспроводных сетях

Эволюция систем IPS/IDS: прошлое, настоящее и будущее

Самое интересное про IPSec и VPN

Туннель через публичную сеть

3 минуты чтения

В сегодняшней статье речь пойдет о способах организации виртуальных частных сетей VPN (Virtual Private Network). VPN – это набор криптографических механизмов, обеспечивающих защищенный, двухсторонний канал для безопасной передачи данных через незащищенную сеть, такую как Интернет. Благодаря VPN пользователь может получить доступ к удаленной сети и работать с её ресурсами так, как если бы он находился внутри нее. Поэтому VPN получил широкое распространение у компаний, имеющих в своем штабе дистанционных сотрудников.

Терминология

VPN представляет собой соединение типа Point to point (точка-точка), которое принято называть “туннелем” (tunnel), а участников данного соединения – “пирами” (peer). Каждый пир шифрует данные, подлежащие передаче через туннель и дешифрует данные, которые получает из туннеля.

Если к одному пиру устанавливается несколько туннелей, то такой пир называется VPN – шлюзом, а сеть, находящаяся за ним – “доменом шифрования” (encryption domain). Несмотря на название, трафик внутри домена шифрования не шифруется, так как считается защищенным от попадания во внешнюю сеть. Кроме того, VPN – туннель может быть установлен между сетями.

Удаленный сотрудник, желающий настроить VPN — туннель с доменом шифрования своего офиса, должен установить на своей рабочей станции специальное ПО – VPN-клиент, например: OpenVPN, VyprVPN, TunnelBear и др.

Для большего понимания, на рисунке ниже отмечены все элементы, рассмотренные ранее:

Разберем основные принципы, по которым устанавливается VPN – соединение.

  1. Перед установлением соединения пиры идентифицируют друг друга, чтобы удостовериться, что шифрованный трафик будет отправлен правильному получателю.
  2. Пиры договариваются, по каким протоколам будет устанавливаться соединение для сохранения целостности и конфиденциальности данныхю
  3. Создается ключ, который будет использоваться для шифрования и дешифрования данных

Существует множество механизмов, способных обеспечить выполнение данных функций, но мы рассмотрим самый распространенный — IPsec(IP Security).

IPsec – это целый набор протоколов, обеспечивающих сервисы приватности и аутентификации. Обычно в IPsec выделяют три основных протокола:

  1. AH (Authentication Header) – протокол идентификации заголовка. Данный протокол обеспечивает защиту передаваемых данных от изменения, путем проверки каждого бита пакета после передачи. То есть обеспечивает функции целостности.
  2. ESP (Encapsulating Security Protocol) Данный протокол обеспечивает не только функции целостности, но и конфиденциальности, путем добавления своего заголовка в пакет, подлежащий защите.
  3. IKE (Internet Key Exchange protocol) – протокол обмена ключами. Данный протокол предназначен для автоматического генерирования, обновления и обмена ключами между участниками VPN – соединения.
Читать еще:  Задания по html верстке

В IPsec есть еще один важный термин – SA (Security Association). SA это непосредственно VPN – соединение в контексте IPsec. SA устанавливается сразу после того, как IPsec – узлы договорились и согласовали все параметры, по которым будет организован VPN – туннель.

Итак, VPN – соединение с использованием IPsec устанавливается в два этапа:

На первом этапе VPN – узлы идентифицируют друг друга и согласовывают алгоритмы шифрования, хэширования и аутентификации, после чего создается первый SA.

Второй этап возможен только после завершения первого. На втором этапе генерируются данные ключей и происходит согласование используемой политики. После завершения второй фазы формируется второй SA и все данные, подлежащие передаче, шифруются. Именно после второго этапа формируется VPN – туннель и установка считается завершенной.

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас 🙁 Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации 🙂 Просто оставьте свои данные в форме ниже.

Загадочный IPsec

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

Из чего состоит IPsec?

IPsec — это не один протокол, а три или четыре, смотря как считать. В OpenVPN и других решениях на основе TLS все просто: устанавливается соединение по TCP или UDP, согласовываются параметры, а затем передаются данные.

В IPsec за согласование параметров и собственно передачу данных отве‐ чают разные протоколы. В Linux, BSD и многих специализированных ОС маршрутизаторов туннель можно настроить вручную, без помощи управляющего протокола.

AH и ESP

Три основных компонента безопасности — доступность, аутентичность и конфиденциальность. IPsec может обеспечивать аутентичность, при этом ничего не делая для конфиденциальности.

Протокол AH (Authentication Header) добавляет в пакет специальный заголовок с контрольной суммой. На практике он используется редко, поскольку никак не способствует конфиденциальности.

Тем не менее его можно встретить в приложениях, где важна только аутентичность. К примеру, протокол маршрутизации OSPFv2 использовал пароли и суммы MD5 для защиты от поддельных анонсов, а его наследник OSPFv3 не включает никакой функциональности для защиты — вместо этого предлагается использовать IPsec в транспортном (прозрачном) режиме и с одной подписью AH без шифрования.

ESP (Encapsulated Security Payload) шифрует содержимое пакета и добавляет хеши. Его можно использовать в двух режимах — транспортном и туннельном. Это сейчас в сетях IPv4 любой VPN немыслим без маршрутизации частных (серых) адресов через туннель, поскольку со внешним миром хосты общаются через NAT. Но IPsec старше NAT и изначально шифровал только полезную нагрузку пакетов, не трогая заголовки, — это и есть транспортный режим.

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

Что интересно, оба они не работают поверх TCP или UDP, а используют отдельные номера протоколов IP. Во всяком случае, по умолчанию — ESP может быть инкапсулирован в UDP для работы через NAT, но об этом позже.

Фреймворк для управляющих протоколов — ISAKMP

Общие принципы согласования настроек безопасности описывает ISAKMP (Internet Security Association and Key Management Protocol). Он описан в RFC 2408.

ISAKMP не является законченным сетевым протоколом. Это фреймворк, который описывает требования к безопасной работе протоколов обмена настройками безопасных соединений, терминологию и общий формат пакетов, но ничего не говорит о конкретных протоколах обмена ключами, шифрования и прочего — это остается на совести реализаций.

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

Самая популярная и практически единственная реализация ISAKMP — IKE.

Управляющий протокол — IKE

IKE (Internet Key Exchange) — реальный управляющий протокол IPsec на основе ISAKMP. На практике можно сказать, что Phase 1 — согласование настроек IKE, а Phase 2 — согласование настроек ESP.

В UNIX‐подобных системах IKE — это единственная часть стека IPsec, которая работает в виде обычного процесса. Само шифрование реализовано в ядре, и демон IKE передает ему параметры после согласования со второй стороной. В Linux это происходит через netlink или команды ip xfrm.

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

Популярные пакеты «для IPsec» вроде StrongSWAN и LibreSWAN реализуют именно IKE.

Согласование настроек шифрования

В IKE есть возможность предложить второй стороне несколько вариантов на выбор, и соединение будет установлено, если у обеих сторон найдется хотя бы один совпадающий вариант. Это общий принцип работы протоколов обмена ключами, TLS работает так же, но в TLS периодически удаляют поддержку устаревших алгоритмов. В IKE безопасность выбора алгоритмов остается на совести пользователя. Заведомо уязвимые DES и MD5 из протокола официально не исключены и до сих пор поддерживаются многими реализациями.

Читать еще:  Значок рубля html

С каждым туннелем ассоциировано одно или несколько «предложений» (proposals). Предложения обрабатываются до первого совпадения. Отсюда следствие: вполне возможна ситуация, когда зловредный (или безответственно настроенный) сервер предложит клиенту устаревшие алгоритмы, а неаккуратно настроенный клиент согласится. У некоторых клиентов вообще может не быть возможности выбрать алгоритмы вручную, а особо ленивые админы любят делать для всех клиентов один большой proposal со всеми мыслимыми алгоритмами. Сортировать алгоритмы по надежности стандарт не обязывает, и стороны вполне могут договориться на шифр полувековой давности.

Более того, официально поддерживается null cipher — опция не шифровать трафик вообще.

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

  1. Ни в коем случае нельзя соглашаться ни на что, что кончается на ecb. ECB (Electronic Code Book) — чрезвычайно небезопасный режим работы блочных шифров. Суть проблемы наглядно демонстрирует знаменитый ECB penguin. Хороший шифр в неверном режиме — плохой шифр. AES‐128‐ CBC — хорошо, AES‐128‐ECB — плохо.
  2. 3DES и Blowfish до недавнего времени считались надежными, но уязвимость SWEET32 показала, что это не так. AES‐128, AES‐256, Twofish и другие шифры с 128‐битными блоками — все еще разумный выбор.
  3. Группы для алгоритма Диффи-Хеллмана DH1024 (group 2) и DH1536 (group 5) также признаны уязвимыми. Нужно использовать DH2048 (group 14) или группы на эллиптических кривых.

В IKE вполне можно использовать разные наборы алгоритмов для Phase 1 и Phase 2. Смысла в этом немного, но возможность имеется.

Diffie-Hellman и PFS

Параметр PFS ранее я оставил без внимания, так как эта штука была мне не совсем понятна, когда рассказывал про объединение сетей с помощью L2TP/IPsec на Mikrotik и Keenetic Ultra II. Восполним недостающие знания.

PFS (Perfect Forward Secrecy) — рекомендуемая опция, которую многие оставляют выключенной, а зря, особенно если используется pre‐shared key.

В этом режиме из ключей обеих сторон генерируется периодически обновляемый сессионный ключ и согласуется с помощью алгоритма Диффи-Хеллмана (DH). В предельно упрощенной формулировке он основан на том, что возвести число в степень просто, а вычислить логарифм гораздо сложнее. При использовании PFS, если кто‐то получит доступ к общему ключу, он не сможет расшифровать им перехваченный трафик, в этом и суть forward secrecy. Подобранный ключ от одной сессии также не поможет рас‐ шифровать последующие, при условии, что числа достаточно большие, именно поэтому DH1024 и DH1536 стали небезопасны — современное железо уже достаточно быстрое для их взлома.

Параметр Phase2 lifetime (ESP lifetime) указывает, как часто должен меняться ключ. Время жизни ключа — чисто локальный параметр, который не согласуется через IKE и может оказаться разным на разных сторонах. Если твои туннели IPsec сначала передают трафик, а потом вдруг перестают работать, проверь, совпадает ли время жизни ключа на обеих сторонах.

Security Associations (SA)

В отличие от OpenVPN или wireguard, IPsec сам по себе не создает никаких виртуальных интерфейсов. Во времена его зарождения у каждого хоста в интернете был публичный адрес и никакой потребности в виртуальных сетях с отдельной адресацией просто не было. Виртуальными интерфейсами занимаются отдельные протоколы, например L2TP или GRE, а IPsec только шифрует их трафик. Многие платформы поддерживают VTI — ассоциированный с соединением IPsec виртуальный интерфейс, но на деле это всего лишь автоматизированная настройка IPIP поверх IPsec.

Вместо туннелей IPsec оперирует еще более абстрактными сущностями — security associations. Они не являются сетевыми соединениями, это просто наборы параметров, которые указывают, какой трафик и как шифровать. К примеру, «трафик из 192.168.1.0/24 в 10.1.0.0/24 зашифровать AES‐128 и добавить сумму SHA1».

Security associations существуют на обеих сторонах независимо и не могут оборваться сами по себе, в отличие от сетевых соединений. Если ты видишь на своей стороне живую SA, это еще не значит, что трафик нормально пойдет на вторую сторону туннеля. Не забывай проверять, что все на самом деле работает. Чтобы вторая сторона могла узнать, что у тебя происходит, нужно настроить dead peer detection (для IKEv1) или использовать IKEv2, где есть liveness check.

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

NAT TRAVERSAL

IPsec появился до NAT и в своем чистом виде работать за NAT не может. Эту возможность к нему прикрутили позже. Сам ESP — отдельный протокол IP с номером 50. Для работы за NAT его инкапсулируют в UDP. В этом случае IKE и инкапсулированный ESP используют один порт — UDP/4500.

Изначально от NAT страдали пользователи клиентских соединений вроде L2TP и IPsec. Популярность облачных платформ, где вместо присвоения хостам публичных адресов эти адреса раздают через 1:1, NAT сделала эту проблему актуальной и для соединений между маршрутизаторами.

При этом может возникнуть неожиданная проблема: если на другой стороне туннель настроен на фиксированный адрес, даже если NAT traversal поддерживается, соединение не заработает.

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

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

Например, в StrongSWAN:

IKEv1 vs IKEv2

У IKE есть две версии — IKEv1 и IKEv2. IKEv2 получила сколько‐нибудь широкое распространение только в последние несколько лет, и то не везде, но у нее есть ряд ощутимых преимуществ.

  • Окончательная стандартизация работы через NAT — в большинстве случаев она теперь просто работает.
  • Livenesscheck — двусторонний keepalived для проверки, живы ли SA.
  • Возможность совместить несколько критериев шифрования трафика в одной SA.
Читать еще:  Vpn скорость соединения

В IKEv1 на каждую пару локальных и удаленных адресов нужна была отдельная SA. К примеру, если хостам 192.168.1.1 и 192.168.1.2 нужен доступ через туннель к 10.1.0.1 и 10.1.0.2, демон IKE создаст четыре отдельные SA. IKEv2 в этом смысле более гибкая.

В IKEv2 также окончательно удален aggressive mode, в котором параметры Phase 1 и Phase 2 передавались одновременно. Значительная часть реализаций, впрочем, давно перестала его поддерживать и в IKEv1 из‐за очевидных проблем с безопасностью такого подхода.

Если обе стороны поддерживают IKEv2, лучше использовать именно ее. Если интересно почитать стандарт, она описана в RFC 5996.

Заключение

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

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

/ статья из журнала ХАКЕР (06) 2019 /

Если считаете статью полезной,
не ленитесь ставить лайки и делиться с друзьями.

Создание туннеля IPSec VPN

В сценарии рассматривается настройка IPSec-инстанса для передачи трафика от виртуальных машин Яндекс.Облака в туннель IPSec VPN с использованием демона strongSwan.

В примере туннель настраивается между двумя VPN-шлюзами. Для тестирования работы VPN-туннеля вам потребуется настроить шлюзы на обеих сторонах туннеля. Для этого можно воспользоваться другой сетью в Яндекс.Облаке или вашей локальной сетью.

Чтобы настроить VPN-туннель:

Если IPSec-инстанс больше не нужен, удалите его.

Подготовьте облако к работе

Перед тем, как разворачивать сервер, нужно зарегистрироваться в Облаке и создать платежный аккаунт:

  1. Перейдите в консоль управления, затем войдите в Яндекс.Облако или зарегистрируйтесь, если вы еще не зарегистрированы.
  2. На странице биллинга убедитесь, что у вас подключен платежный аккаунт, и он находится в статусе ACTIVE или TRIAL_ACTIVE . Если платежного аккаунта нет, создайте его.

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

Необходимые платные ресурсы

В стоимость поддержки инфраструктуры IPSec VPN входят:

  • плата за постоянно запущенные виртуальные машины (см. тарифы Yandex Compute Cloud);
  • плата за использование динамического внешнего IP-адреса (см. тарифы Yandex Virtual Private Cloud).

Создайте сети и подсети

Для связи облачных ресурсов с интернетом необходимо иметь созданные сети и подсети.

Создайте IPSec-инстанс

Создайте в Облаке виртуальную машину, которая будет служить шлюзом для IPSec-туннеля.

Откройте ваш каталог и нажмите кнопку Создать ресурс. Выберите пункт Виртуальная машина.

Укажите имя виртуальной машины, например ipsec-instance .

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

В блоке Публичные образы нажмите кнопку Выбрать и выберите образ IPSec-инстанс.

В блоке Сетевые настройки выберите требуемую сеть, подсеть и назначьте ВМ публичный IP-адрес из списка или автоматически.

Используйте только статические публичные IP-адреса из списка, или сделайте IP-адрес созданной машины статическим. Динамический IP-адрес может измениться после перезагрузки ВМ и туннель перестанет работать.

В поле Доступ укажите логин и SSH-ключ для доступа к ВМ.

Нажмите кнопку Создать ВМ.

Настройте IPSec

Настройте шлюз с публичным IP-адресом и подсетью, который будет устанавливать IPSec-соединение с удаленным шлюзом.

В примере ниже публичный IP-адрес шлюза будет 130.193.32.25 . За шлюзом будет находиться подсеть 10.128.0.0/24 . Этот шлюз будет устанавливать IPSec-соединение с удаленным шлюзом с IP-адресом 1.1.1.1 , за которым находится подсеть 192.168.0.0/24 .

Подключитесь к виртуальной машине по SSH:

Откройте конфигурацию IPSec:

Приведите раздел config setup к следующему виду:

Задайте следующие параметры тестового соединения:

  • leftid — публичный IP-адрес IPSec-инстанса.
  • leftsubnet — CIDR подсети, к которой подключен IPSec-инстанс.
  • right — укажите публичный IP-адрес шлюза на другом конце VPN-туннеля.
  • rightsubnet — укажите CIDR подсети, к которой подключен VPN-шлюз на другом конце VPN-туннеля.
  • В параметрах ike и esp укажите алгоритмы шифрования, которые поддерживаются на удаленном шлюзе. Списки поддерживаемых алгоритмов шифрования см. на сайте strongSwan: IKEv1 и IKEv2.
  • Остальные настройки укажите, консультируясь с документацией strongSwan и учитывая настройки удаленного шлюза.

Сохраните изменения и закройте файл.

Должна получиться конфигурация вида:

Откройте файл /etc/ipsec.secrets и укажите в нем пароль для установки соединения:

3. Настройте статическую маршрутизацию

Настройте маршрутизацию между IPSec-инстансом и заранее созданной виртуальной машиной без публичного IP-адреса.

Создайте таблицу маршрутизации и добавьте в нее статические маршруты:

Откройте раздел Virtual Private Cloud в каталоге, где требуется создать статический маршрут.

Выберите сеть, в которой требуется создать таблицу маршрутизации.

Нажмите кнопку Создать таблицу маршрутизации.

Задайте имя таблицы маршрутизации.

  • Длина — от 3 до 63 символов.
  • Может содержать строчные буквы латинского алфавита, цифры и дефисы.
  • Первый символ — буква. Последний символ — не дефис.

Нажмите кнопку Добавить маршрут.

В открывшемся окне введите префикс подсети назначения на удаленной стороне, в примере это 192.168.0.0/24 .

В поле Next hop укажите внутренний IP-адрес IPSec-шлюза. Нажмите кнопку Добавить.

Нажмите кнопку Создать таблицу маршрутизации.

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

  1. В строке нужной подсети нажмите кнопку .
  2. В открывшемся меню выберите пункт Привязать таблицу маршрутизации.
  3. В открывшемся окне выберите созданную таблицу в списке.
  4. Нажмите кнопку Привязать.

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

4. Настройте IPSec на другом шлюзе

Для работы VPN-туннеля требуется настроить еще один шлюз IPSec VPN. Вы можете создать в своем каталоге еще одну облачную сеть с подсетью и создать в ней IPSec-инстанс из образа, либо используйте в качестве шлюза машину в вашей локальной сети.

Ссылка на основную публикацию
ВсеИнструменты 220 Вольт
Adblock
detector