L2tp сервер на centos 8. установка и настройка vpn-сервера на linux для возможности подкючения стандартными средствами windows

Аутентификация через Active Directory

Проверка подлинности через активный каталог от Microsoft в xl2tp выполняется с помощью winbind и samba.

Подготовка сервера

Для корректной работы сервера с Active Directory необходимо задать ему имя (hostname), которое будет доступно в DNS. Также на сервере должно быть задано точное время.

1. Необходимо убедиться, что сервер доступен по своему доменному имени. Если серверу так и не было задано вменяемого имени, вводим команду:

hostnamectl set-hostname vpn.dmosk.local

* где vpn — имя сервера; dmosk.local — домен.

После добавляем в DNS наш сервер VPN. Ждем минут 15 (если у нас используется доменная инфраструктура с несколькими сайтами, иначе ждать не нужно).

2. Задаем временную зону:

\cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime

* в данном примере мы задаем зону по московскому времени.

Устанавливаем утилиту для синхронизации времени, разрешаем запуск демона и стартуем его.

yum install chrony

systemctl enable chronyd

systemctl restart chronyd

Присоединяем сервер к домену

Устанавливаем необходимые компоненты:

dnf install samba-client samba-winbind samba-winbind-clients krb5-workstation

Открываем конфигурационный файл samba:

vi /etc/samba/smb.conf

В разделе редактируем следующие опции:

workgroup = DMOSK
security = ads

* где DMOSK — NETBIOS имя домена; ads — указывает, что для samba будет использоваться модель безопасности LDAP Active Directory.

Также в добавим следующие строки:

kerberos method = secrets and keytab
realm = DMOSK.LOCAL
winbind enum groups = Yes
winbind enum users = Yes
idmap config * : rangesize = 1000000
idmap config * : range = 1000000-19999999
idmap config * : backend = autorid

* где:

kerberos method — метод проверки kerberos. В данном примере сначала используется secretts.tdb, а затем системная таблица ключей.
realm — сервер Active Directory. В нашем примере прописан домен, так как по нему можно обратиться к любому из серверов AD.
winbind enum groups — задает пределы перечисления групп через setgrent(), getgrent() и endgrent().
winbind enum users — задает пределы перечисления пользователей через setpwent(), getpwent()и endpwent().
idmap config * : rangesize — определяет количество доступных uids и gids в каждом доменном диапазоне.
idmap config * : range — определяет доступные совпадающие диапазоны uid и gid, для которых серверная часть является авторитетной.
idmap config * : backend — задает idmap плагин для использования в качестве SID/uid/gid подсистемы

Вводим сервер в домен:

net ads join -U Administrator@dmosk.local

* где Administrator — учетная запись пользователя AD с правами на ввод компьютеров в домен; dmosk.local — наш домен.

Мы должны увидеть, примерно, следующее:

Using short domain name — DMOSK
Joined ‘SAMBA’ to dns domain ‘dmosk.local’

Разрешаем автозапуск winbind и стартуем его:

systemctl enable winbind —now

Выбираем профиль для аутентификации:

authselect select winbind —force

Проверяем, что наш сервер может получить список пользователей Active Directory:

wbinfo -u

… и групп:

wbinfo -g

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

После проверяем, что аутентификация в AD через модуль ntlm_auth работает корректно:

ntlm_auth —request-nt-key —domain=DMOSK.LOCAL —username=Administrator

* где DMOSK.LOCAL — наш домен; Administrator — пользователь, под которым будем логиниться для проверки работы модуля.

Настройка PPP для аутентификации через AD

Открываем конфигурационный файл options.xl2tpd:

vi /etc/ppp/options.xl2tpd

Добавляем в самый низ:

…
plugin winbind.so
ntlm_auth-helper ‘/usr/bin/ntlm_auth —helper-protocol=ntlm-server-1 —require-membership-of=»DMOSK\\VPN Users»‘

* где VPN Users — группа в AD, пользователи который будут иметь возможность использовать VPN.

Перезапускаем xl2tpd:

systemctl restart xl2tpd

Проверка

В Active Directory добавляем группу VPN Users (если еще нет). Группа должна быть локальная в домене. В группу добавим пользователей, которым хотим дать доступ для VPN-подключения.

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

Настройка L2TP

В данной настройке будет минимум шагов, т.к. особых сложностей нет.

Создаётся пул адресов для VPN-клиентов в меню IP-Pool:

Создается PPP-профиль с дефолтными настройками, указывается только локальный адрес и удаленные адреса из созданного ранее пула:

В разделе PPP-Secrets создается пользователь для созданного выше profile.

И в том же разделе PPP включается L2TP-сервер:

Здесь, собственно, активируется сам сервер и указывается, что требуется использование IPsec с нужным секретом, который был задан при настройке IPsec Identities. Используется mschap2 для авторизации через L2TP. Значение required использовано для того, чтобы убедиться, что принимаются только L2TP-соединения, инкапсулированные в IPsec. Хотя на практике у меня с этим параметром получилось установить соединение с Linux-клиента без IPsec – уж не знаю, где ошибка и что не так, но для верности запретил такие подключения без шифрования ещё на уровне firewall в начале статьи.

На этом всё, настройка IPsec и L2TP-сервера на Mikrotik завершена и можно переходить к настройке клиента.

Шаг 2 — Создание центра сертификации

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

Располагая структурой каталогов для хранения всех элементов, мы можем сгенерировать ключ root. Это будет 4096-битный ключ RSA, который будет использоваться для подписи корневого центра сертификации.

Запустите следующие команды, чтобы сгенерировать ключ:

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

Вы можете изменить значение distinguished name (DN) на любое другое имя по своему желанию. Используемое здесь имя common приведено просто для примера, имя не должно соответствовать какому-либо элементу вашей инфраструктуры.

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

VPN Rule Orders

Rules for the VPN zone require special considerations especially if you want to edit them with LuCI. Think of the IP address/interface overlap. Your routers default outgoing interface is normally the WAN connection. Every packet that does not match your internal network will leave there. But with active security profiles in the kernel packets e.g. to the remote VPN subnet 192.168.10.0/24 will go out through the WAN interface too. Of course they will be encrypted in advance. A simple rule “Allow all LAN Zone to WAN Zone” matches any packet to one of the remote VPN networks. Placed at the wrong position on top of the list it may conflict with other VPN specific rules that follow.

Conclusion: The firewall script of at least version 10 will take care about that. You do not have to bother.

Настройка туннеля L2TP + IPSec на Mikrotik (site-to-site). Объединяем два офиса

Попробуем объединить два офиса фирмы в одну виртуальную частную сеть (VPN) используя туннельный протокол L2TP в связке с IPSec на оборудовании Mikrotik.

Схема подключения:

Из схемы мы видим, что Mikrotik в главном офисе (GW1), будет настроен на роль L2TP Server + IPSec, со следующими настройками:

Внешний IP (WAN): 111.111.111.111;
IP-адрес VPN Server: 192.168.77.1;
Адрес в LAN сети: 192.168.13.254.

MIkrotik в филиале (GW2) будет являться VPN-клиентом с настройками:

Внешний IP (WAN): 222.222.222.222;
IP-адрес VPN Client: 192.168.77.10;
Адрес в LAN сети: 192.168.12.254.

Приступаем к настройке.

Setup L2TP with IPSEC

Open server manager, click Tools, and open Remote Access Management, then right-click your server on the left pane to select Properties from the drop-down list.

Under server properties, navigate to the Security tab, and click Allow custom IPSec policy for L2TP/IKEv2 connection to enter your new pre-shared key.

In this guide, we use 12345678, choose something stronger, then navigate to IPV4 to set a static address pool and click OK to apply changes.

Keep note of the pre-shared key (PSK) since it will be required for every user establishing a connection to the VPN server.

From the left pane, expand the IPV4 sub-menu and right-click on NAT, then select New Interface. If you set PPTP earlier, click NAT and edit the existing interface you already created.

Navigate to the Services and Ports tab and select VPN Gateway [L2TP/IPSec], then click edit to change the private address from 0.0.0.0 to 127.0.0.1. Click OK to save changes and restart remote access from the left pane under All Tasks.

This will restart Routing and Remote Access, then save the applied L2TP configurations.

Preface

In the following chapters you will find a detailed description of how to setup firewall rules for IPsec VPN connections. The experienced reader may notice that nowhere iptables IPsec policy rules are used (-m policy –pol ipsec). The reason for that is a special VPN scenario where both tunnel ends use overlapping IP addresses. In this case we have do use source NAT (network address translation) rules. SNAT is only available in the POSTROUTING nat table. At this late firewall stage the system will discover for the first time that the packet has to pass the IPsec tunnel. Any ipsec policy based filter before will ignore the packet.

SoftEther VPN

SoftEther VPN — академический проект японского Цукубского университета (University of Tsukuba), распространяемый под лицензией GPLv2. Главной его особенностью является поддержка нескольких VPN-протоколов, совместимых с оригинальными клиентами. Это позволяет вместо парка серверов из проприетарных и open source решений использовать для подключения клиентов, работающих под управлением разных ОС, одно приложение. И просто выбирать нужный протокол в зависимости от конкретной ситуации. Поддерживаются: SSL-VPN (HTTPS), IPsec, L2TP, MS-SSTP, L2TPv3, EtherIP и OpenVPN. SoftEther VPN работает в режимах remote-access и site-to-site, на уровнях L2 (Ethernet-bridging) и L3 (IP). В случае замены OpenVPN мы получаем более простую конфигурацию. Есть генератор ovpn-файлов для быстрого подключения VPN-клиента. Замена SSTP VPN позволяет отказаться от использования серверов на базе Win2k8/2012, требующих лицензии. Собственный протокол обеспечивает прохождение Ethernet поверх HTTPS (отсюда и название проекта — Software Ethernet), характеризуется хорошей пропускной способностью и низкой латентностью. Его использование дает возможность прозрачно соединить несколько Ethernet-сетей в одну, то есть отпадает необходимость в дополнительных решениях Ethernet-over-IP.

И главное — он совместим с NAT и работает через стандартный 443-й порт, который обычно не блокируется брандмауэрами провайдеров. Эта возможность позволяет скрыть вообще использование VPN: со стороны трафик выглядит как обычный и не обнаруживается технологиями Deep Packet Inspection. Собственно, поэтому он и стал очень популярен в Китае, где его используют для обхода Великого китайского файрвола. При этом на стороне клиента реализован виртуальный сетевой адаптер Ethernet, а на сервере — виртуальный коммутатор. Большой плюс — наличие NAT Traversal, включенной по умолчанию, то есть не нужно просить админа открыть доступ к VPN-серверу, находящемуся во внутренней сети. Но и это еще не все. В сетях с ограниченным доступом, у которых блокируются все TCP- и UDP-пакеты (например, публичные Wi-Fi), для создания VPN можно использовать протоколы ICMP и DNS, обычно не блокируемые брандмауэром. Поддерживается Dynamic DNS, позволяющий получить доступ при динамически меняющемся IP-адресе. Для этого реализован сервис VPN Gate, называемый VPN Azure Cloud Service, — к нему можно организовать соединение из внутренней сети и затем при необходимости свободно попадать внутрь сети. Клиентская часть содержит специальный плагин VPN Gate, позволяющий отслеживать смену IP и быстро подключаться к VPN Gate.

Обеспечивается высокая производительность и скорость соединения 1 Гбайт/с без существенных ограничений по объемам ОЗУ и минимальной нагрузке на процессор. Поэтому требования к серверной части очень невысоки. По тестам SoftEther VPN обходит на том же оборудовании оригинальные решения. Поддерживается шифрование AES-256 и RSA-4096, IPv4/IPv6, журналирование трафика и событий. Аутентификация пользователей локальная, RADIUS и домен Windows.

Администрирование учетных записей и параметры безопасности могут быть настроены удаленно с помощью графического интерфейса Server Manager (локализация только английский, японский и китайский), который устанавливается на Win- или macOS-компьютере администратора или при помощи утилиты командной строки vpncmd. Возможна установка на Windows, Linux, macOS, FreeBSD и Solaris. Доступен исходный код и архив со скомпилированным приложением. Для установки потребуется выбрать ОС, платформу и компонент (сервер, клиент, bridge…). Официально поддерживаются Linux-ядра 2.4/2.6/3.x, но без проблем работает и в современных дистрибутивах с ядром 4.х. В Linux достаточно распаковать архив и запустить файл .install.sh, после чего раза три принять условия лицензии и по окончании запустить сервер:

Далее, отвечая на вопросы vpncmd (или при помощи Server Manager), настраиваем параметры подключения.

Управлять SoftEther VPN можно при помощи графического интерфейса
Другие статьи в выпуске:

Connect and Test Your L2TP VPN server

In this guide, we test the new L2TP with IPSec VPN on a mac. To get started, open System Preferencesand click Network.

Under the Network Preferences window, click the + sign and select VPN under the Interface dialog box. Then, choose L2TP with IPSec as the VPN Type and assign your connection a name.

Click create, then enter your public server IP Address (server address) and username (Account name). Next, click Authentication Settings to enter your account password and Pre-shared key (Shared secret) created earlier.

Next, click Advanced and select Send all Traffic over VPN Connection, then click Apply, and finally click Connect to establish a connection with your new L2TP VPN server.

NAT Translation

Some of our interfaces will run in masquerade mode. The source address of packets that will leave through these interfaces will be translated to the interface address itself. This is an unwanted contrast to VPN networks where IP addresses are usually untouched. Maybe sometime later we will have look at overlapping VPN subnets. This time our challenge lies in the NAT POSTROUTING chain. For each interface that you flagged with masquerading in LuCI a rule is inserted there. When taking no action something like this will happen.

Our LAN is connected via IPsec to the remote subnet 192.168.10.0/24
We send a packet to the remote subnet.
After all filter rules have been applied the packet enters the NAT table
Our tunnel is terminated on the WAN interface (PPPOE-WAN) with activated masquerading
The NAT ruleset chooses the WAN zone for the packet
Therefore the packet source address is translated to our offical WAN IP
Afterwards it is put into the tunnel
Ouch!

So once again we have to fix the queue. Therefore we will put a rule at the first position in the chain. This will ensure that packets to foreign VPN subnets will remain untouched.

Test your PPTP VPN

Using your personal computer (PC) or Smartphone, go to Networks, Add a new VPN and select PPTP as the VPN type. Then, enter the VPN username and password created earlier to connect.

In this guide, we cover and test the PPTP VPN on a Windows 10 PC. To get started, click the start menu and search for Control Panel, then, click Network and Internet.

Under Network and Internet, open the Network and Sharing Center and click Set up a new connection or network.

Under the open window, select Connect to a workplace and click Use my Internet connection (VPN).

Then, enter your serverâs public IP Address (Check your Vultr server dashboard), assign the connection a name, and click create.

Now, on the left pane, click Change adapter settings, then right click your created VPN interface and select Properties.

Under the pop-up, click Security, then choose Point to Point Tunneling Protocol (PPTP) under Type of VPN.

Finally, under Allow these protocols, select CHAP and MS-CHAP v2, then click OK to apply changes.

Your new VPN is configured successfully. Click the network connection icon on the taskbar, select your VPN on the list and click Connect to enter the VPN username and password created earlier to establish a connection to your new PPTP VPN server.

Testing the VPN

Assuming that the racoon daemon started correctly on both of the gateway hosts,
and that all our other configuration options are correct, there should now be a fully functional
Virtual Private Network (VPN) between the two networks using the IPsec ESP
protocol in tunnel mode. You can verify that this is indeed the case using the
ping utility as shown below.

host-on-net-1 ~ # ping -c 3 host.on.net2

PING 10.1.0.21 (10.1.0.21) 56(84) bytes of data.

64 bytes from 10.1.0.21: icmp_req=1 ttl=62 time=29.2 ms

64 bytes from 10.1.0.21: icmp_req=2 ttl=62 time=29.3 ms

64 bytes from 10.1.0.21: icmp_req=3 ttl=62 time=28.1 ms

--- 10.1.0.21 ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, time 2002ms

rtt min/avg/max/mdev = 28.107/28.895/29.300/0.574 ms

The fact that you received replies to the icmp messages during the test above should
be sufficient proof that the VPN is indeed working correctly however, just for completeness,
the network can also be tested in the opposite direction as shown below.

host-on-net-2 ~ # ping -c 3 host.on.net1

PING 10.0.0.73 (10.0.0.73) 56(84) bytes of data.

64 bytes from 10.0.0.73: icmp_req=1 ttl=62 time=28.0 ms

64 bytes from 10.0.0.73: icmp_req=2 ttl=62 time=29.5 ms

64 bytes from 10.0.0.73: icmp_req=3 ttl=62 time=28.5 ms

--- 10.0.0.73 ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, time 2003ms

rtt min/avg/max/mdev = 28.067/28.719/29.502/0.608 ms

Default Rules

We could build our own VPN firewall ruleset with iptables but why not go with LuCI. The interface should be flexible enough to build rules for our new OpenWrt IPsec enhanced router. The basic “Deny All” configuration can be achieved in the upper two panels. You should start with something like that:

Idea behind that is:

The standard rule is to deny all (first panel)
Depending on the zone we allow access to the device (INPUT). For our dual band router these are LAN, WLAN2 (2.5 GHz) and WLAN5 (5 GHz)
The router is allowed to send data into all zones (OUTPUT).
Sending data between zones is disabled (FORWARD). This will be achieved through firewall rules afterwards.

Шаг 2 — Создание центра сертификации

Серверу IKEv2 требуется сертификат, чтобы идентифицировать себя для клиентов. Чтобы помочь создать требуемый сертификат, в пакет входит утилита, вызываемая pkiдля создания центра сертификации и сертификатов сервера.

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

Затем заблокируйте разрешения, чтобы другие пользователи не могли видеть наши личные файлы:

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

Выполните эти команды, чтобы сгенерировать ключ:

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

Флаг используется для гарантии того, что корневой сертификат центра сертификации будет действителен в течение 10 лет. Корневой сертификат для центра обычно не меняется, поскольку его придется перераспределять на каждый сервер и клиент, которые полагаются на него, поэтому 10 лет — это безопасное значение срока действия по умолчанию.

Вы можете изменить значение отличительного имени (DN) на другое, если хотите. Общее имя (поле CN) здесь является просто индикатором, поэтому оно не должно соответствовать чему-либо в вашей инфраструктуре.

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

Устранение неполадок

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

Если у вас не получается подключиться к VPN, проверьте правильность доменного имени сервера или IP-адреса. Домен или IP должен совпадать со значением, указанным в параметре common name (CN) во время создания сертификата. Если они не совпадают, вы не сможете подключиться к VPN. К примеру, если в сертификате (в CN) вы указали vpn.example.com, вы должны использовать домен vpn.example.com при создании подключения к VPN.

Если вы указывали доменное имя, тогда также нужно проверить параметры VPN и убедиться, что в leftid перед доменом стоит символ @:

Если же вы указывали IP, убедитесь, что символа @ перед адресом нет. Также убедитесь, что при создании файла server-cert.pem вы включили флаги –san @IP_address и –san IP_address

WireGuard

WireGuard — результат исследований автора проекта Джейсона Доненфилда (Jason A. Donenfeld), главы компании Edge Security. Продукт со встроенной криптографией, одновременно простой в использовании и в реализации (чуть более 4000 строк кода), что существенно выделяет его среди остальных решений. Например, его код легче проанализировать, чем все, что написано в рамках *Swan/IPsec или OpenVPN. Самый молодой проект обзора. О нем заговорили в середине лета 2016-го после публикации анонса в списке рассылки разработчиков ядра Linux, где был представлен патч к ядру. Хотя сам проект развивается уже несколько лет и прошел стадию рецензирования криптографии, то есть его можно внедрять в основное ядро.

VPN-соединение инициализируется (handshake) путем обмена открытыми ключами и напоминает подход, применяемый в SSH. Все остальное прозрачно обрабатывается WireGuard, нет необходимости беспокоиться о ключах, роутинге, контроле состояния и прочем, это все забота WireGuard. Возможно использование симметричного шифрования, но это потребует чуть больших настроек. Маршрутизация производится по ключам шифрования, для этого к каждому сетевому интерфейсу привязывается закрытый ключ. Для обновления ключей handshake происходит через определенное время или по сигналу, что ключи устарели. Для согласования ключей и соединения вместо собственного демона в пространстве пользователя используется механизм Noise_IK из Noise Protocol Framework, похожий на поддержание authorized_keys в SSH, без усложнений в виде поддержки x509 и ASN.1.

Для шифрования применяются потоковый шифр ChaCha20 и алгоритм аутентификации сообщений (MAC) Poly1305. Для генерации совместного секретного ключа — протокол Диффи — Хеллмана на эллиптических кривых в реализации Curve25519, предложенной Дэниелом Бернштейном. Для хеширования используются BLAKE2s (RFC 7693) и SipHash-2-4. Избежать replay-атаки позволяет метка времени TAI64N, пакеты с меньшей меткой времени отбрасываются.

Передача данных осуществляется на третьем уровне ISO через инкапсуляцию в пакеты UDP. Поддерживаются IPv4 и IPv6, инкапсуляция v4 в v6 и v6 в v4. Может работать за NAT и файрволом. Поддерживается смена IP-адреса VPN-сервера без разрыва соединения с автоматической перенастройкой клиента.

После установки в системе появляется новый сетевой интерфейс wg0, который может быть настроен штатными инструментами ipconfig/ip-address и route/ip-route. Специальная утилита wg позволяет установить секретный ключ устройства и указать список ассоциаций для клиентов (его публичный ключ, разрешенный IP).

Для установки понадобится дистрибутив с ядром Linux >4.1. Пакет можно найти в репозиториях основных дистрибутивов Linux. Для Ubuntu 16.04 есть PPA.

Самостоятельная сборка из исходных текстов также несложна. Поднимаем интерфейс, генерируем пару ключей (для примера сохраняем в файлах privatekey и publickey):

Получаем публичный ключ от клиента и создаем соединение.

Возможно использование PresharedKey (генерируется командой wg genpsk), который добавляет еще один уровень симметричного шифрования к имеющемуся шифрованию с открытым ключом. Для пира можно указать PersistentKeepalive, позволяющий поддерживать соединение из-за NAT и файрвола. Поднимаем интерфейс:

Смотрим настройки:

Для удобства лучше заранее подготовить конфигурационный файл, содержащий секцию interface и секции peer. Формат можно увидеть, введя wg showconf.

Подходит как для небольших встроенных устройств вроде смартфонов, так и для магистральных маршрутизаторов. Тесты показали, что WireGuard имеет примерно в четыре раза лучшую пропускную способность и в 3,8 раза более отзывчив по сравнению с OpenVPN (256-bit AES c HMAC-SHA-2–256). Здесь сказывается не только реализация в виде модуля ядра, тогда как OpenVPN работает в userspace. Повышение производительности обусловлено отказом от использования CryptoAPI ядра, работающего достаточно медленно. Вместо него в WireGuard задействованы собственные реализации ChaCha20, Poly1305, BLAKE2s и Curve25519, которые позиционируются как быстрые и безопасные аналоги AES-256-CTR и HMAC, их программная реализация позволяет добиться фиксированного времени выполнения без аппаратной поддержки.

Также WireGuard благодаря меньшим задержкам чуть лучше выглядит в производительности по сравнению с IPsec (256-bit ChaCha20 + Poly1305 и AES-256-GCM-128), но вот настройки гораздо проще.

Пока WireGuard доступен только для Linux, после тестирования предполагается портировать в другие ОС. Код распространяется под лицензией GNU GPLv2.

Настройка WireGuardСмотрим конфигурацию WireGuard

Шаг 5 — Настройка аутентификации VPN

Наш VPN-сервер теперь настроен на прием клиентских подключений, но у нас еще нет настроенных учетных данных. Нам нужно настроить пару вещей в специальном файле конфигурации с именем :

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

Откроем файл секретов для редактирования:

Во-первых, мы сообщим StrongSwan, где найти наш закрытый ключ и как его разобрать.

Убедитесь, что строка начинается с символа и после него стоит пробел, чтобы вся строка читалась как .

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

Сохраните и закройте файл. Теперь, когда мы закончили работу с параметрами VPN, перезапустим службу VPN, чтобы наша конфигурация применилась:

Теперь, когда VPN-сервер полностью настроен как с параметрами сервера, так и с учетными данными пользователя, пришло время перейти к настройке самой важной части: брандмауэра

Решения

В большинстве случаев эта проблема связана с настройкой попыток одновременного входа в групповой политике. Для получения дополнительных сведений см. раздел Настройка групповых политик Выбранные процедуры настройки ASDM VPN для Cisco ASA серии 5500, версия 5.2.

Попытки одновременного входа

Если в ASDM установлен флажок «Наследовать», то для пользователя будет поддерживаться только то количество попыток одновременного входа, которое задано по умолчанию. По умолчанию значение для попыток одновременного входа устанавливается равным трем.

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

Запустите ASDM и перейдите в Настройка > VPN > Групповая политика.

Выберите необходимую Группу и щелкните кнопку Правка.

На вкладке «Общие» снимите флажок «Наследовать» для «Попытки одновременного входа» в «Настройки соединения». Выберите соответствующее значение в поле .

Примечание: Минимальным допустимым значением для этого поля является 0. При использовании этого значения отключается возможность входа и запрещается доступ для пользователей.

Настройте ASA/PIX с помощью интерфейса командной строки

Выполните эти шаги, чтобы задать необходимое значение для количества попыток одновременного входа. В этом примере для этого параметра было выбрано значение, равное 20.

Для получения дополнительных сведений об этой команде, см. Справочник команд Cisco Security Appliance, версия 7.2.

Troubleshoot

This section provides information you can use to troubleshoot your configuration.

Troubleshooting Commands for Router IPsec

Note: Refer to Important Information on Debug Commands before you issue debug commands.

debug crypto engine—Displays the traffic that is encrypted.
debug crypto ipsec—Displays the IPsec negotiations of phase 2.
debug crypto isakmp—Displays the Internet Security Association and Key Management Protocol (ISAKMP) negotiations of phase 1.

Clearing Security Associations

clear crypto isakmp—Clears Internet Key Exchange (IKE) security associations.
clear crypto ipsec sa—Clears IPsec security associations.

Troubleshooting Commands for PIX

Certain show commands are supported by the Output Interpreter Tool (registered customers only) , which allows you to view an analysis of show command output.

Note: Refer to Important Information on Debug Commands before you issue debug commands.

logging buffer debugging—Shows connections being established and denied to hosts that go through the PIX. The information is stored in the PIX log buffer and the output can be seen using the show log command.
ASDM can be used to enable logging and also to view the logs as shown in these steps.

Choose Configuration > Properties > Logging > Logging Setup > Enable Logging and then click Apply.
Choose Monitoring > Logging > Log Buffer > On Logging Level > Logging Buffer, then click View.

This is an example of the Log Buffer.