IPsec L2TP VPN сервер

From Gentoo Wiki
Jump to: navigation, search
This page is a translated version of the page IPsec L2TP VPN server and the translation is 100% complete.

Other languages:
English • ‎日本語 • ‎русский

Многие операционные системы поддерживают L2TP/IPsec VPN "из коробки". Объединяя сервисы конфиденциальности и аутентификации IPsec (безопасность Интернет-протокола), сетевое туннелирование протокола туннелирования второго уровня (L2TP) и идентификацию пользователя через pppd, администраторы могут создавать VPN-сети на множестве разнородных систем. Это позволяет настроить VPN на Android, Windows, Linux, MacOS и других операционных системах без использования какого-либо коммерческого ПО.

Contents

Введение

IPsec/L2TP – повсеместно используемый VPN протокол, применяемый в Windows и других операционных системах. Все версии Windows, начиная с Windows 2000, имеют встроенную поддержку этого протокола и не требуют сторонних клиентов (например, OpenVPN), что делает его более удобным. Однако, значительно сложнее настроить серверную сторону на Linux, поскольку задействованы как минимум 3 слоя: IPsec, L2TP и PPP.

  1. IPsec обеспечивает конфиденциальность сетевого соединения и авторизации клиента (системы)
  2. С L2TP туннель настроен так, что VPN трафик прозрачно проходит через IPsec
  3. PPP (протокол точка-точка) контролирует авторизацию пользователей

Это руководство не охватывает установку DHCP, RADIUS, Samba или Инфраструктуры Открытых Ключей (PKI). Оно также совсем не объясняет, как настраивать Linux-клиентов, хотя этот шаг может быть довольно легко получен из руководства. Будет освещена часть конфигурации Windows-клиентов с целью устранения неполадок в настройке сервера.

Условные обозначения

В этом руководстве будут использованы следующие условные обозначения (пример настроек):

  • Домен – example.com
  • Имя сервера – vpn.example.com
  • Имя файла сертификата CA – ca.crt
  • Сертификат сервера – vpn.example.com.crt
  • Ключ сервера – vpn.example.com.key
  • Сертификат клиента – client.example.com.crt
  • Ключ клиента – client.example.com.key

IPsec

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

Windows использует IKEv1. Существуют 3 реализации IPsec в Portage: ipsec-tools (racoon), LibreSwan и strongswan.

В следующих разделах объясняются различные конфигурации. Для каждого варианта документируется

  • как использовать PSK для авторизации и
  • как использовать сертификаты для авторизации

Выберете один из вариантов (PSK или сертификаты). При использовании авторизации на основе сертификата предполагается, что нужные сертификаты уже доступны.

Вариант 1: ipsec-tools (racoon)

Заметка
net-firewall/ipsec-tools должен быть скомпилирован с флагом nat, если либо сервер находится за NAT, либо необходима поддержка клиентов, находящихся за NAT.

ipsec-tools наименее функционален, но для тех, кто пришёл из *BSD, он может быть более близок. Однако, в отличие от *BSD, Linux не использует отдельный интерфейс для IPsec.

После установки ipsec-tools необходимо создать несколько файлов. Для начала создадим каталоги, в которых они будут хранится:

root #mkdir /etc/racoon/certs
root #mkdir /etc/racoon/scripts

Настройка PSK в ipsec-tools

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

user $dd if=/dev/random count=24 bs=1 2>/dev/null | hexdump -e '24/1 "%02x" "\n"'

Каждая запись в PSK файле состоит из идентификатора и ключа. Windows идентифицирует себя посредством полного имени домена (FQDN). Ключ должен быть обозначен как строка или шестнадцатеричное число, начинающееся с 0x. В любом случае, содержимое (сам ключ) – полностью в выборе администратора:

Файл /etc/racoon/psk.txt
client.example.com 0x87839cfdab5f74bc211de156d2902d128bec3243

В файле racoon.conf PSK файл обозначается через опцию path pre_shared_key:

Файл /etc/racoon/racoon.confИспользование racoon с PSK
path certificate "/etc/racoon/certs";
path pre_shared_key "/etc/racoon/psk.txt";
path script "/etc/racoon/scripts";
 
remote anonymous {
 
        exchange_mode main;
        my_identifier fqdn "vpn.example.com";
 
        passive on;
        generate_policy on;
        nat_traversal on;
 
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 14;
        }
}
 
sainfo anonymous {
        encryption_algorithm aes, 3des;
        authentication_algorithm hmac_sha1, hmac_md5;
        compression_algorithm deflate;
}

Настройка ipsec-tools с использованием сертификата

Скопируйте ca.crt, vpn.example.com.crt и vpn.example.com.key в /etc/racoon/certs. Убедитесь, что vpn.example.com.key недоступен для всех пользователей.

Далее, обновите конфигурацию в файле racoon.conf, добавив эти файлы в разделе remote anonymous:

Файл /etc/racoon/racoon.confИспользование сертификатов с racoon
path certificate "/etc/racoon/certs";
path pre_shared_key "/etc/racoon/psk.txt";
path script "/etc/racoon/scripts";
 
remote anonymous {
        exchange_mode main;
        my_identifier fqdn "vpn.example.com";
 
        certificate_type x509 "vpn.example.com.crt" "vpn.example.com.key";
        ca_type x509 "ca.crt";
 
        passive on;
        generate_policy on;
        nat_traversal on;
 
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method rsasig;
                dh_group 14;
        }
}
 
sainfo anonymous {
        encryption_algorithm aes, 3des;
        authentication_algorithm hmac_sha1, hmac_md5;
        compression_algorithm deflate;
}

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

Когда возникают проблемы, этот раздел может дать несколько указаний в их решении.

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

Опция generate_policy on; должна заставить racoon создавать для нас нужную Политику Безопасности. Однако, в присутствие NAT (хотя бы, если сервер находится за NAT) он сделает это совсем не так, как хотелось бы. Таким образом, если трафик не проходит по туннелю, политика безопасности должна быть определена вручную.

Политика создаётся в файле /etc/ipsec-tools.conf:

Файл /etc/ipsec-tools.conf
#!/usr/sbin/setkey -f
 
flush;
spdflush;
spdadd vpn.example.com[l2tp] 0.0.0.0/0 udp -P out ipsec
        esp/transport//require;
spdadd 0.0.0.0/0 vpn.example.com[l2tp] udp -P in ipsec
        esp/transport//require;

Заметим, что хотя эта политика безопасности полагает, что мы хотим защитить "весь" L2TP трафик, проходящий к серверу и от него, если нет Ассоциации Безопасности, трафик не будет защищён и будет проходить через Интернет по обычному (неавторизованному/незашифрованному) пути, он не будет пропущен только потому, что нет Ассоциации Безопасности.

Вариант 2: LibreSwan

LibreSwan – ответвление от Openswan (который сам является ответвлением от FreeS/WAN). LibreSwan действительно раздвоился с сохранением настоящих разработчиков Openswan, однако после того, как они покинули Xelerance, спор о названии "Openswan" перерос в судебный иск, после которого было принято имя LibreSwan.

Желательно иметь каждую настройку VPN в своём собственном файле, что может быть сделано раскомментированием последней строки в /etc/ipsec.conf:

Файл /etc/ipsec.conf
# Файлы конфигурации (.conf) также могут быть помещены в папку "/etc/ipsec.d/"
# раскомментированием этой строки
#include /etc/ipsec.d/*.conf

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

Настройка PSK в LibreSwan

Должен быть создан общий ключ. Он может быть задан строкой в кавычках или шестнадцатеричным числом. В следующем примере PUT_VPN_SERVER_IP должен быть заменён на IP-адрес сервера. Можно использовать доменное имя, но оно не рекомендовано разработчиками LibreSwan. Опция %any позволяет любым клиентам использовать этот PSK.

Файл /etc/ipsec.d/vpn.example.com.secret
PUT_VPN_SERVER_IP %any : PSK 0x87839cfdab5f74bc211de156d2902d128bec3243
# Или используйте простой текстовый ключ вместо шестнадцатеричного:
# PUT_VPN_SERVER_IP %any : PSK "password_pass"

Затем создайте /etc/ipsec.d/vpn.example.com.conf:

Файл /etc/ipsec.d/vpn.example.com.conf
conn vpnserver
        type=transport
        authby=secret
        pfs=no
        rekey=no
        keyingtries=1
        left=%defaultroute
        leftprotoport=udp/l2tp
        leftid=@vpn.example.com
        right=%any
        rightprotoport=udp/%any
        auto=add

Настройка LibreSwan с использованием сертификата

LibreSwan требует, чтобы Network Security Services (NSS) были правильно сконфигурированы и использованы для управления сертификатами. Чтобы было проще выполнить настройку, необходимо создать пакет PKCS#12, содержащий секретный ключ сервера, его сертификат и сертификат ЦС.

user $openssl pkcs12 -export -certfile ca.crt -inkey vpn.example.com.key -in vpn.example.com.crt -out /etc/ipsec.d/vpn.example.com.p12

Затем пакет может быть импортирован в базу данных NSS:

root #cd /etc/ipsec.d
root #pk12util -i путь к пакету/vpn.example.com.p12 -d .

Конфигурационные файлы LibreSwan будут ссылаться на псевдоним импортированных объектов. Используйте certutil -L -d . и certutil -K -d ., чтобы его узнать.

Файл /etc/ipsec.d/vpn.example.com.secrets
: RSA "vpn.example.com"

В приведённом примере vpn.example.com использован как псевдоним, полученный с помощью команды certutil -K -d ..

Файл /etc/ipsec.d/vpn.example.com.conf
conn vpnserver
        type=transport
        authby=rsasig
        pfs=no
        rekey=no
        keyingtries=1
        left=%defaultroute
        leftprotoport=udp/l2tp
        leftcert=vpn.example.com
        leftid=@vpn.example.com
        right=%any
        rightprotoport=udp/%any
        rightrsasigkey=%cert
        auto=add

Здесь vpn.example.com – псевдоним, полученный с помощью команды certutil -L -d ..

Вариант 3: strongSwan

strongSwan – это ответвление от FreeS/WAN (хотя большая часть кода была заменена).

Что касается strongSwan 5.0, обход NAT является автоматическим, ничего настраивать не требуется.

strongSwan не создаёт файл ipsec.secrets, поэтому его нужно создать:

root #touch /etc/ipsec.secrets && chmod 664 /etc/ipsec.secrets

Настройка PSK в strongSwan

Должен быть создан общий ключ. Он может быть задан строкой в кавычках или шестнадцатеричным числом. В следующем примере PUT_VPN_SERVER_IP должен быть заменён на IP-адрес сервера. Опция %any означает, что любой клиент может авторизоваться, используя этот PSK.

Файл /etc/ipsec.secrets
PUT_VPN_SERVER_IP %any : PSK 0x87839cfdab5f74bc211de156d2902d128bec3243
# Или используйте простой текстовый PSK вместо шестнадцатеричного:
# PUT_VPN_SERVER_IP %any : PSK "password_pass"

Далее отредактируйте /etc/ipsec.conf как показано ниже:

Файл /etc/ipsec.conf
conn vpnserver
        type=transport
        authby=secret
        pfs=no
        rekey=no
        keyingtries=1
        left=%any
        leftprotoport=udp/l2tp
        leftid=@vpn.example.com
        right=%any
        rightprotoport=udp/%any
        auto=add

Когда и left, и right заданы как %any, strongSwan подразумевает, что локальный компьютер – left.

Настройка strongSwan с использованием сертификата

Сертификаты и ключи должны быть скопированы в нужную папку:

root #cp ca.crt /etc/ipsec.d/cacerts
root #cp vpn.example.com.crt /etc/ipsec.d/certs
root #cp vpn.example.com.key /etc/ipsec.d/private
root #chown -R ipsec: /etc/ipsec.d

Далее, укажите strongSwan использовать открытые ключи для авторизации:

Файл /etc/ipsec.secrets
: RSA vpn.example.com.key

Наконец, обновите файл /etc/ipsec.conf как показано ниже:

Файл /etc/ipsec.conf
conn vpnserver
        type=transport
        authby=rsasig
        pfs=no
        rekey=no
        keyingtries=1
        left=%defaultroute
        leftprotoport=udp/l2tp
        leftcert=server.crt
        leftid=@vpn.example.com
        right=%any
        rightprotoport=udp/%any
        rightrsasigkey=%cert
        auto=add

Как и раньше, когда и left, и right равны %any, strongSwan подразумевает, что локальный компьютер – left.

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

Сквозной проход IPsec / повреждённый NAT

В предыдущих версиях strongSwan сквозной проход IPsec не казался рабочим. Он возвращал "cannot respond to IPsec SA request because no connection is known" или (со сложным редактирование конфигурационного файла) ошибку INVALID_HASH_INFORMATION. Такого не может быть со strongSwan версии 5.0 и выше.

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

С IPsec нелегко иметь дело. Этот раздел даёт несколько указаний на общие проблемы и ошибки.

Сервер за NAT

Когда сервер находится за NAT (преобразование сетевых адресов), что обычно бывает в случае, если сервер размещается за домашним роутером, некоторые специальные указания могут помочь обеспечить стабильное и рабочее соединение IPsec.

Открытие портов

Необходимо открыть 2 порта:

  • UDP port 500 (for ISAKMP)
  • UDP port 4500 (for NAT Traversal)

Убедитесь, что отправили это VPN серверу.

Также следующие Протоколы Интернета (не порты) нуждаются в разрешении:

  • 50 (ESP)
  • 51 (AH)

Может потребоваться настроить их на стороне роутера, если у него есть особые параметры для протоколов (впрочем, у большинства их нет).

Сквозной проход IPsec / повреждённый NAT

Многие роутеры имеют опцию "IPsec pass-through", которая может обозначать одно из двух:

  1. Искажать пакеты IPsec способом, не совместимым с обходом NAT IPsec
  2. Позволять всем IPsec пакетам без изменений проходить через роутер.

Если IPsec pass-through значит (1), отключите эту опцию. Если он значит (2), то включите её.

К несчастью, существуют роутеры, отбрасывающие IPsec трафик, даже если порты разрешены, и поддерживающие только опцию (1). Для тех, у кого такой роутер, есть 3 варианта:

  1. Обновить прошивку, если доступна более новая, правильно работающая версия.
  2. Открыть отчёт об ошибке/неисправности с моделью роутера, если он не устарел
  3. Найти другой роутер. По описаниям, роутеры Linksys и D-link работают правильно.

Это руководство изначально было написано с таким роутером (Zyxel P-330W), и единственным доступным вариантом был (3).

Клиенты Windows Vista/Server 2008

Эти операционные системы автоматически не поддерживают IPsec/L2TP сервера за NAT. См. KB926179 для изменений в реестре, заставляющих их поддерживать его.

Ограничения Pre-Shared keys (PSK)

В протоколе IPsec нет поддержки согласования PSK. Единственная информация, доступная для выбора, какой ключ использовать, зависит от начального и конечного IP-адреса. Так как в обычной ситуации ответчик не будет заранее знать IP-адрес инициатора, каждый должен использовать тот же PSK. Поэтому, сертификаты (PKI) рекомендуются больше, чем PSK, даже только для единственного соединения. Однако, производство сертификатов и создание PKI – довольно сложный процесс и выходит за рамки этого руководства.

L2TP

Второй уровень, протокол туннелирования второго уровня (L2TP), настраивается намного проще. Как и IPsec, L2TP – одноранговый протокол. Клиентская сторона называется L2TP Access Concentrator или LAC, а серверная – L2TP Network Server или LNS.

Предупреждение
L2TP абсолютно небезопасен и не должен быть доступен вне соединения IPsec

При использовании iptables, примените следующие правила, чтобы заблокировать все соединения L2TP вне ipsec:

root #iptables -t filter -A INPUT -p udp -m policy --dir in --pol ipsec -m udp --dport l2tp -j ACCEPT
root #iptables -t filter -A INPUT -p udp -m udp --dport l2tp -j REJECT --reject-with icmp-port-unreachable
root #iptables -t filter -A OUTPUT -p udp -m policy --dir out --pol ipsec -m udp --sport l2tp -j ACCEPT
root #iptables -t filter -A OUTPUT -p udp -m udp --sport l2tp -j REJECT --reject-with icmp-port-unreachable

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

Файл /etc/ufw/before.rules
# Разрешить L2TP только через IPsec
-A ufw-before-input -m policy --dir in --pol ipsec -p udp --dport l2tp -j ACCEPT
-A ufw-before-input -p udp -m udp --dport l2tp -j REJECT --reject-with icmp-port-unreachable
-A ufw-before-output -m policy --dir out --pol ipsec -p udp --sport l2tp -j ACCEPT
-A ufw-before-output -p udp -m udp --sport l2tp -j REJECT --reject-with icmp-port-unreachable
 
# Разрешить авторизацию IPsec с использованием протокола ESP
-A ufw-before-input -p esp -j ACCEPT
-A ufw-before-output -p esp -j ACCEPT

Использование xl2tpd

В отличие от других серверов L2TP, xl2tpd может поддерживать пул IP-адресов без серверов DHCP или RADIUS. Это является нарушением расслоения, но для небольшой установки очень удобно:

Файл /etc/xl2tpd/xl2tpd.conf
[global]
port = 1701
access control = no
 
[lns default]
ip range = 172.21.118.2-172.21.118.254
local ip = 172.21.118.1
require authentication = yes
name = LinuxVPN
pppoptfile = /etc/ppp/options.xl2tpd

Для использования сервера RADIUS или DHCP, оставьте отключенными опции ip range и local ip. Если соединение нестабильно, попробуйте добавить length bit = yes в раздел lns default. Чтобы не использовать PPP аутентификацию, замените require authentication = yes на refuse authentication = yes.

Создайте файл опций:

Файл /etc/ppp/options.xl2tpd
noccp
auth
crtscts
mtu 1410
mru 1410
nodefaultroute
lock
proxyarp
silent

Использование rp-l2tp

Настраивать rp-l2tp просто:

Файл /etc/rp-l2tp/rp-l2tpd.conf
# Глобальный раздел (по умолчанию, мы начнём в глобальном режиме)
global
 
# Загрузка модулей
load-handler "sync-pppd.so"
load-handler "cmd.so"
 
# Адрес привязки
listen-port 1701
 
section peer
peer 0.0.0.0
mask 0
lns-handler sync-pppd
 
lns-pppd-opts "noccp auth crtscts mtu 1410 mru 1410 nodefaultroute lock proxyarp silent"

Укажите IP сервера в lns-pppd-opts. Также не забудьте настроить pppd для использования пула IP-адресов или при помощи DHCP, или через RADIUS.

PPP

Заключительный уровень для настройки – Протокол точка-точка (PPP). Пакет для установки – net-dialup/pptpd.

root #emerge --ask net-dialup/pptpd

Авторизация

PPP используется для выполнения авторизации. В отличие от аутентификации на основе сертификата или PSK, PPP более предназначен для аутентификации (и авторизации) доступа к VPN конечного пользователя.

Без авторизации

Самый простой путь настройки pppd – вообще не использовать авторизацию. В этом случае, убедитесь что указан "noauth". Это может оказаться полезным с целью тестирования, но в противном случае не рекомендуется, особенно с использованием PSK. Для некоторых установок PKI, такая конфигурация может быть благоразумной, например,

  • все клиентские компьютеры полностью доверены и находятся под контролем, или
  • все пользователи доверены и ключи есть только на компьютерах рядом с самими пользователями, имеющими доступ, и нигде более, или
  • все соединения являются автоматическими (этот метод используется для подключения нескольких мест)

Авторизация через chap.secrets

Для небольших пользователей (обычно тех, кто хочет подключаться к своей домашней сети в другом месте), авторизация может быть произведена через файл chap.secrets:

Файл /etc/ppp/chap-secrets
# Пароли для авторизации с использованием CHAP
# клиент        сервер  пароль                  IP-адрес
avatar          *       unontanium              *
Заметка
При авторизации с доменами, имя клиента должно быть правильно изменено, в этом примере, EXAMPLE\\avatar.
Предупреждение
/etc/ppp/chap-secrets содержит незашифрованные пароли, поэтому убедитесь, что только root может выполнять чтение или запись в этот файл

Авторизация через Samba

Если компьютер является частью домена Microsoft или леса Active Directory, а клиенты используют winbind, то авторизацию может выполнять Samba. Добавьте plugin winbind.so к опциям ppp. Настройка Samba и pppd находится за пределами этого руководства.

Авторизация через RADIUS

Если на компьютере запущен сервер RADIUS, то pppd может использовать его. Убедитесь, что net-dialup/ppp собран с USE-флагом radius. Затем добавьте plugin radius.so к опциям PPP. Настройка RADIUS и pppd находится за пределами этого руководства.

Авторизация через EAP-TLS

Если у пользователя есть сертификаты (не такие, как сертификаты компьютера, о которых говорилось раньше), тогда настройте pppd для авторизации через EAP-TLS. Рекомендуется, чтобы пользователи авторизовались с помощью смарт-карт или RSA secureID. Убедитесь, что net-dialup/ppp собран с USE-флагом eap-tls. Требуется, чтобы был настроен RADIUS (см. выше). Может потребоваться включить require-eap в файл опций PPP. Настройка pppd выходит за пределы этого руководства.

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

Windows: Правильная установка сертификата (для пользователей PKI)

Сертификат должен быть запакован в пакет PKCS12. Это может быть сделано посредством openssl или gnutls:

user $openssl pkcs12 -export -certfile ca.crt -inkey client.example.com.key -in client.example.com.crt -out client.example.p12
user $certtool --load-ca-certificate ca.crt --load-certificate client.example.com.crt --load-privkey client.example.com.key --to-p12 --outfile client.example.com.p12

Когда создан файл .p12, импортируйте его в Windows. Однако, способ не очевиден. Не надо дважды щёлкать по ключу и следовать инструкциям, это не будет работать. Ключ будет импортирован в личное хранилище сертификатов, но в Windows в авторизации нуждается локальный компьютер, таким образом сертификат должен быть добавлен в хранилище ключей локального компьютера. Для этого используйте Консоль управления Microsoft (MMC). Для работы требуются привилегии администратора.

Код Импорт ключа в Windows
Пуск -> Выполнить -> mmc
Файл -> Добавить или удалить оснастку... -> Сертификаты -> Добавить
учетной записи компьютера -> локальным компьютером -> Готово -> OK.

Разверните Сертификаты. Выберете любую папку (без разницы какую), щёлкните правой кнопкой мыши, выберете "Все задачи", затем "Импорт...". Только сейчас следуйте указаниям мастера, но на последнем шаге убедитесь, что выбрано "Автоматически выбрать хранилище на основе типа сертификата".

Windows: Сетевые ошибки RAS

Ошибка 766: Сертификат не может быть найден

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

Ошибка 810: VPN соединение не завершено

При использовании ipsec-tools (racoon) в системном логе может появится следующее сообщение:

Код Сообщение об ошибке в системном логе при использовании ipsec-tools/racoon
ERROR: ignore information because ISAKMP-SAhas not been established yet.

Это значит, что сертификат был неправильно импортирован, или пакет p12 отсутствует в сертификате ЦС. Убедитесь, что импортировали ключ через MMC и выбрали "Автоматически выбрать хранилище на основе типа сертификата" в конце процесса импорта.

XP SP2 и выше: Ошибка 809: Сервер не отвечает (Сервер за NAT)

Windows XP SP2 и Vista умолчанию не будут подключаться к серверу за NAT. Требуется взлом реестра. Отдельные исправления требуются для Windows XP и Windows Vista.

Vista: Ошибка 835 Невозможно авторизоваться

Эта ошибка появляется только при использовании PKI. Она значит, что subjectAltName не соответствует серверу, к которому подключается клиент. Такое часто случается при использовании динамического DNS, – сертификат имеет внутреннее имя, а не внешнее. Добавьте к сертификату внешнее имя или отключите опцию "Проверить атрибуты имени и использования у сертификата сервера" в настройках соединения: Безопасность -> Дополнительные параметры -> L2TP.

Ошибка 741: Локальный компьютер не поддерживает требуемый тип шифрования

Windows будет пытаться реализовать MPPE (слабое) шифрование, когда

  • система не использует авторизацию PPP, или
  • система не имеет pppd с поддержкой MPPE, или
  • MPPE поддерживается, но не скомпилировано с ядром (или как модуль)

тогда происходит данная ошибка.

Если используется авторизация PPP, рекомендуется исправить pppd или ядро (с минимальными изменениями конфигурации), даже если нет смысла в двойном шифровании. Если система не использует авторизацию PPP, или двойное шифрование однозначно не требуется, тогда отключите его на вкладке Безопасность.

Заметка
Соединение всё же так или иначе защищено шифрованием IPsec, отключится только потребность в MPPE.

Mac OS X

Mac OS X клиенты должны быть требовательны к рекомендациям, с которыми они соглашаются. В частности:

  • dh_group должен быть modp1024.
  • my_identifier должен быть адресом, а не полным именем домена (адрес используется по умолчанию, таким образом просто уберите эту строку из racoon.conf).

Mac OS X не будет подключаться, если subjectAltName не соответствует имени сервера, с которым он соединяется. В отличие от Vista, эта проверка не может быть отключена.

Также, Mac OS X не подключится, если сертификат сервера содержит поля "Расширенное использование ключа" (EKU) (кроме устаревших ikeIntermediate). В частности, при использовании сертификатов из утилиты easy-rsa OpenVPN, добавляются EKU "TLS WWW Сервер" или "TLS WWW Клиент", поэтому такие сертификаты не будут работать. Однако, они всё же могут быть использованы Mac OS X клиентом, поскольку его интересуют только сертификаты сервера.

Ссылки