This is Gentoo's testing wiki. It is a non-operational environment and its textual content is outdated.
Please visit our production wiki at https://wiki.gentoo.org
IPsec L2TP VPN сервер
Многие операционные системы поддерживают L2TP/IPsec VPN "из коробки". Объединяя сервисы конфиденциальности и аутентификации IPsec (безопасность Интернет-протокола), сетевое туннелирование протокола туннелирования второго уровня (L2TP) и идентификацию пользователя через pppd, администраторы могут создавать VPN-сети на множестве разнородных систем. Это позволяет настроить VPN на Android, Windows, Linux, MacOS и других операционных системах без использования какого-либо коммерческого ПО.
Введение
IPsec/L2TP – повсеместно используемый VPN протокол, применяемый в Windows и других операционных системах. Все версии Windows, начиная с Windows 2000, имеют встроенную поддержку этого протокола и не требуют сторонних клиентов (например, OpenVPN), что делает его более удобным. Однако, значительно сложнее настроить серверную сторону на Linux, поскольку задействованы как минимум 3 слоя: IPsec, L2TP и PPP.
- IPsec обеспечивает конфиденциальность сетевого соединения и авторизации клиента (системы)
- С L2TP туннель настроен так, что VPN трафик прозрачно проходит через IPsec
- 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 с PSKpath 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
Использование сертификатов с racoonpath 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", которая может обозначать одно из двух:
- Искажать пакеты IPsec способом, не совместимым с обходом NAT IPsec
- Позволять всем IPsec пакетам без изменений проходить через роутер.
Если IPsec pass-through значит (1), отключите эту опцию. Если он значит (2), то включите её.
К несчастью, существуют роутеры, отбрасывающие IPsec трафик, даже если порты разрешены, и поддерживающие только опцию (1). Для тех, у кого такой роутер, есть 3 варианта:
- Обновить прошивку, если доступна более новая, правильно работающая версия.
- Открыть отчёт об ошибке/неисправности с моделью роутера, если он не устарел
- Найти другой роутер. По описаниям, роутеры Linksys и D-link работают правильно.
Это руководство изначально было написано с таким роутером (Zyxel P-330W), и единственным доступным вариантом был (3).
Клиенты Windows Vista/Server 2008
Эти операционные системы автоматически не поддерживают IPsec/L2TP сервера за NAT. См. KB926179 для изменений в реестре, заставляющих их поддерживать его.
В протоколе 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). Для работы требуются привилегии администратора.
Пуск -> Выполнить -> mmc Файл -> Добавить или удалить оснастку... -> Сертификаты -> Добавить учетной записи компьютера -> локальным компьютером -> Готово -> OK.
Разверните Сертификаты. Выберете любую папку (без разницы какую), щёлкните правой кнопкой мыши, выберете "Все задачи", затем "Импорт...". Только сейчас следуйте указаниям мастера, но на последнем шаге убедитесь, что выбрано "Автоматически выбрать хранилище на основе типа сертификата".
Windows: Сетевые ошибки RAS
Ошибка 766: Сертификат не может быть найден
Если происходит такая ошибка, значит сертификат не был правильно импортирован. Убедитесь, что импортировали его через MMC, а не двойным щелчком файла.
Ошибка 810: VPN соединение не завершено
При использовании 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 клиентом, поскольку его интересуют только сертификаты сервера.
Ссылки
- a Linux L2TP/IPsec VPN server от Jacco de Leeuw