Установка и настройка L2TP VPN-сервера на Ubuntu Server
L2TP сервер удобен тем, что позволяет использовать встроенные средства Windows для подключения. В данной инструкции рассмотрим процесс его установки и настройки на Ubuntu 16.04 и 18.04. В итоге мы получим:
- VPN-сервер, использующий туннельный протокол L2TP.
- Защита соединения посредством общего ключа + аутентификация пользователя.
- Доступ к локальной сети.
Мы выполним следующие настройки:
Настройка IPSEC
Для управления IPSec используется пакет strongswan — установим его командой:
apt-get install strongswan
Открываем конфигурационный файл для настройки ipsec:
Для config setup добавим:
config setup
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
protostack=netkey
* где virtual_private для нас является наиболее важным параметром и определяет приватные сети. В данном примере просто перечислены сети, зарезервированные под локальные — мы можем указать и другие.
. а также вставляем ниже:
conn l2tpvpn
type=transport
authby=secret
pfs=no
rekey=no
keyingtries=2
left=%any
leftprotoport=udp/l2tp
leftid=@l2tpvpnserver
right=%any
rightprotoport=udp/%any
auto=add
- type — тип соединения. Возможны варианты tunnel ( хост-хост, хост-подсеть или подсеть-подсеть); transport (хост-хост); passthrough (без обработки IPsec).
- authby — способы аутентификации двух узлов. Возможны варианты secret (по паролю) или rsasig (цифровые подписи RSA).
- pfs — расшифровывается как Perfect Forward Secrecy. Позволяет активировать совершенную секретность в канале ключей соединения.
- rekey — перепроверить соединение, когда оно истекает.
- keyingtries — число попыток, чтобы «договориться» о соединении или его замене.
- left — IP-адрес левого участника (сервера). %any означает, что адрес может быть любой.
- leftprotoport — определяет протокол и порт, на котором будет работать левая сторона (сервер). В данном примере указан UDP и порт 1701.
- leftid — идентификация левого участника соединения.
- right — IP-адрес правого участника (клиента). %any означает, что адрес может быть любой.
- rightprotoport — определяет протокол и порт, на котором будет работать правая сторона (клиент). В данном примере указан UDP и любой порт.
- auto — операция, которая должна запуститься автоматически при старте IPsec.
Создаем секретный ключ — для этого открываем на редактирование файл:
%any %any : PSK «my_key_password»
* в данном примере мы устанавливаем общий пароль my_key_password для соединений с любого IP.
Разрешаем автозапуск strongswan и перезапускаем службу:
systemctl enable strongswan
systemctl restart strongswan
Устанавливаем сервер L2TP:
apt-get install xl2tpd
Открываем файл настройки сервера:
[global]
port = 1701
access control = no
ipsec saref = yes
force userspace = yes
auth file = /etc/ppp/chap-secrets
[lns default]
ip range = 176.16.10.10-176.16.10.200
local ip = 176.16.10.1
name = l2tpserver
pppoptfile = /etc/ppp/options.xl2tpd
flow bit = yes
exclusive = no
hidden bit = no
length bit = yes
require authentication = yes
require chap = yes
refuse pap = yes
- port — порт UDP, на котором работает VPN. По умолчанию, 1701.
- access control — принимать или нет запросы только от клиентов с определенными IP, перечисленными в настройках клиентов.
- ipsec saref — указывает использовать или нет ipsec Security Association, позволяющий отслеживать несколько клиентов с одинаковыми IP-адресами.
- force userspace — повышает производительность за счет декапсуляции пакетов L2TP.
- auth file — путь к файлу аутентификации.
- ip range — диапазон адресов, которые назначаются подключенным клиентам.
- local ip — IP-адрес сервера в сети VPN.
- name — имя сервера для процесса согласования.
- pppoptfile — путь к файлу с настройкой pppd.
- flow bit — позволяет добавлять в пакеты порядковые номера.
- exclusive — если поставить в yes, сервер разрешит только одно соединение с клиентом.
- hidden bit — скрывать или нет AVP.
- length bit — использовать ли бит длины, указывающий полезную нагрузку.
- require authentication — требовать ли аутентификацию.
- require chap — требовать ли аутентификацию PPP по протоколу CHAP.
- refuse pap — требовать ли аутентификацию PPP по протоколу PAP.
Разрешаем автозапуск vpn-сервера и перезапускаем его:
systemctl enable xl2tpd
systemctl restart xl2tpd
Открываем на редактирование конфигурационный файл:
Источник
Установка и настройка L2TP/IPSec VPN сервера в Ubuntu
«Шифрование…это мощное оборонительное оружие для свободных людей. Оно предоставляет технические гарантии конфиденциальности, независимо от того кто управляет государством… Сложно представить более мощный и менее опасный инструмент для свободы.»
Эстер Дайсон
Цитата из книги «Buldings and Integrating Virtual Private Networks with Openswan, 2006, ISBN 1-904811-25-6»
О самой простой в реализации разновидности VPN соединения я уже писал (статья: «Установка и настройка PPTP–VPN сервера в Ubuntu 10.04»). Действительно, PPTP очень прост во внедрении, но не следует забывать, что эта технология не рекомендована для использования в системах, где безопасность критична. Кроме того, PPTP протокол часто блокируют (по каким-то причинам) операторы мобильной связи и обычные провайдеры. Но есть и еще одна, не такая очевидная причина, по которой от PPTP есть смысл отказываться. Для работы PPTP сервера нужно на роутере (через который входит интернет в квартиру) перенаправить «протокол 47», он же GRE на локальный адрес сервера. В моих любимых роутерах AirPort Extreme такой настройки нет (в DLink тоже не помню чтобы была, хотя в современных моделях скорее всего уже добавили, но зато она есть в TP-Link WR940N). Поэтому приходится пользоваться опцией «узел по умолчанию» – где можно указать внутренний IP машины, на который по умолчанию (если не указано другое) будет отправляться весь входящий из интернета трафик. А это потенциально небезопасно, так как сервер оказывается выставлен напрямую в интернет.
В противовес PPTP есть другая технология построения виртуальных частных сетей, – более изящная, безопасная, современная, правда гораздо более сложная во внедрении. О ней мы и поговорим в этой статье.
Популярный сегодня протокол для создания виртуальных защищенных туннелей – IPSec, достаточно хорошо работает с NAT по стандартным UDP портам, и поэтому более интересен для сетей, в которых сервер прячется за роутером. IPSec – это сокращение от IP Security Protocol. Это дополнительный уровень, поверх IP, который отвечает за шифрование. IPsec является неотъемлемой частью IPv6 — интернет-протокола нового поколения, и необязательным расширением существующей версии интернет-протокола IPv4.
Так как он работает на сетевом (IP) уровне (3-й уровень в модели OSI), нет необходимости добавлять функцию шифрования на уровне приложения (как например сделано в SSH, DNSSEC, HTTPS и т.п.) Другими словами, всем известно, что FTP считается небезопасным, так как пароль при соединении отправляется в открытом виде, но FTP через IPSec будет максимально безопасным, при чем никаких изменений в механизме FTP производить не нужно. Таким образом, IPSec добавляет дополнительный уровень безопасности и решает проблему безопасности прозрачно для всех приложений.
Прежде чем мы перейдем к особенностям настройки IPSec сервера, следует рассмотреть некоторые аппаратные преграды, которые могут помешать внедрению IPSec. Выше я упомянул, что IPSec достаточно хорошо работает с NAT по стандартным UDP портам. Однако не все так безоблачно как может показаться.
Проблема NAT
Network Address Translation (NAT) – это механизм, который был придуман для того чтобы объединить несколько сетей и хостов в группу, и назначить ей один IPv4 адрес. Таким образом рассчитывалось несколько придержать конец света, когда закончится адресное пространство IPv4, и дотянуть до того времени когда будет готова более совершенная система адресации (IPv6). Значительным ограничением (или наоборот, преимуществом – смотря как посмотреть) является то, что только компьютер находящийся за NAT-шлюзом может инициировать соединение с внешним миром. Но внешний мир никаким образом не может инициировать соединение с каким-то конкретным компьютером находящимся за NAT’ом, так как любое соединение извне с исходным отправителем закончится на NAT’е, так как его IP адрес значится как IP адрес места назначения в исходящем пакете. Когда NAT получит пакет для нового соединения, он не будет знать какому из своих локальных клиентов его передать, и пакет будет проигнорирован. Для решения этого придумана переадресация портов, но и этот механизм не лишен недостатков.
Обычная переадресация портов не поможет хотя-бы потому, что большинство бытовых NAT’ов могут обрабатывать только TCP, UDP и ICMP, но IP протокол содержит 256 различных протоколов, которые не поддерживаются устройствами SOHO-класса. Так например, многие бытовые роутеры не имеют поддержки протоколов IPSec, ESP или Multicast. Кроме того, переадресация пакетов роутером подразумевает нарушение целостности пакета, а идея IPSec наоборот, заключается в сохранении целостности от отправителя до получателя. Таким образом IPSec и NAT это противоречащие друг другу механизмы как например, палки и колеса.
NAT-Traversal – универсальное решение
NAT-T это дополнение к IPSec протоколу, предназначенное для определения наличия NAT устройства между двумя конечными точками. Работает это следующим образом. Обе точки сообщают друг другу свои IP адреса, которые как они думают у них есть. Затем, противоположная сторона сравнивает то что сообщил клиент с тем, что она видит сама. Если результаты отличаются, значит удаленная точка находится за NAT-ом. В таком случае удаленная сторона информируется об этой неприятной ситуации. Как только обе стороны обнаружили и согласились, что NAT роутер скорее всего будет искажать или терять IPsec пакеты, они договариваются об инкапсуляции каждого IPsec пакета в UDP пакет. NAT роутер может обрабатывать простые UDP пакеты, транслируя внешний IP адрес и не касаясь содержимого пакета, коим собственно является полный IPsec пакет, который в свою очередь содержит другой полный пакет, несущий полезную информацию.
На другом конце, IPsec узел просто отбросит внешний IP адрес и извлечет содержимое. Полученный в результате IPsec пакет, выживший во всевозможных «сетевых мясорубках» может быть аутентифицирован, верифицирован, расшифрован и обработан как любой нормальный IPsec пакет.
Лажа с IPSec Passthrough
Роутеры с поддержкой функции IPsec passthrough иногда определяют наличие IPsec в UDP пакетах и пытаются выполнить сквозную передачу таких пакетов. Это приводит к поломке NAT-T поскольку как минимум, роутер изменяет SPI (Security Parameter Index), чтобы самому иметь возможность следить за состоянием соединения.
В книге «Buldings and Integrating Virtual Private Networks with Openswan, 2006, ISBN 1-904811-25-6» настоятельно рекомендуется отключать поддержку IPsec passthrough всегда и без исключений, и если вы еще не успели приобрести устройство с поддержкой IPsec passthrough, поставьте его обратно на полку. Однако с момента выхода книги прошло уже 8 лет, и похоже ситуация изменилась в лучшую сторону. Apple говорит о поддержке IPsec passthrough в своих AirPort и Time Capsule; в более бюджетных роутерах, таких как TP-Link WR940N и ASUS RT-N10U (это только те, которые мне удалось протестировать лично) есть в явном виде функция IPsec passthrough, и похоже, что этот механизм в действительности работает. Возможно, название осталось, а алгоритм обработки изменился.
Скриншот админки роутера Asus с IPsec passthrough
Описанные выше аппаратные преграды, которые могут помешать во внедрении IPSec, следует иметь ввиду, для лучшего понимания механизма работы. Однако как вы понимаете, на сегодняшний день, они уже успешно решены.
Не используйте Authenticated Header (AH) или Транспортный режим. Используйте исключительно Encapsulated Security Payload (ESP) в Туннельном режиме. Это самое безопасное решение с криптографической точки зрения.
Цитата из книги «Buldings and Integrating Virtual Private Networks with Openswan, 2006, ISBN 1-904811-25-6»
IPSec для Linux
Одной из реализаций IPSec для семейства Linux является проект Openswan. Openswan поддерживает версии ядра Linux 2.0, 2.2, 2.4 и 2.6, и работает на множестве различных платформ, включая x86, x86_64, ia64, MIPS и ARM.
На момент последней редакции этой статьи (январь 2014) последней версией Openswan является версия 2.6.39. Однако не смотря на успешную сборку и установку она работала некорректно на моей Ubuntu 10.04, скорей всего нужно пересобрать программу с какими-то кастомными настройками. Разбираться в связке Openswan 2.6.39 и Ubuntu 10.04 я не стал, так как давно пора обновить Ubuntu до актуальной версии, и пока остановился на версии 2.6.38, которая и до этого успешно работала на моем сервере.
1. Сборка и установка Openswan IPSec из исходников
Заходим на наш сервер по SSH и устанавливаем необходимые для сборки пакета библиотеки:
Создаем временную папку, например на рабочем столе (mkdir Desktop/temp) и перейдя в нее (cd Desktop/temp), скачиваем, собираем и устанавливаем Openswan из исходников (как мы договорились, рассматриваем версию 2.6.38):
Хозяйке на заметку – не стоит удалять папку с исходниками после установки программы. В этой папке содержится скрипт, отвечающий за удаление программы, это относится ко всем корректно написанным программам для Linux. Если в будущем мы захотим удалить программу, собранную из исходников и установленную вручную, то нужно зайти в оригинальный каталог с исходниками и выполнить в нем sudo make uninstall.
Сборка должна пройти без ошибок и без дополнительного шаманства.
2. Настройка Openswan IPSec
Установив Openswan приступим к настройке. Мы будем рассматривать конфигурацию, когда к серверу, находящемуся за NAT’ом будет подключаться удаленный клиент, либо с реальным IP, либо также находящийся за NAT’ом. Мы не рассматриваем в данной статье вариант объединения двух удаленных серверов либо сетей.
Вначале откройте конфигурационный файл /etc/ipsec.conf и приведите его к примерно такому виду (в рассматриваемом случае VPN-сервер это компьютер с локальным адресом 10.0.0.2 за роутером 10.0.0.1. Сеть: 10.0.0.0/24). Обратите внимание на параметр virtual_private – здесь должны быть перечислены подсети, которые разрешены для использования подключающимся VPN-клиентам, и какие запрещены. Запрещенные перечисляются в конце, с восклицательным знаком. В данном случае запрещена подсеть 10.0.0.0/24, так как это подсеть, используемая локальными компьютерами.
Прокомментируем некоторые важные параметры:
Принудительная UDP инкапсуляция для ESP пакетов, даже если NAT не обнаружен. Это может помочь обойти ограничивающие файерволы. Значение по умолчанию =no, лучше начать с него, если будет работать со сбоями, попробуйте =yes.
Аутентификация по паролю (shared secret) — самый простой способ, хотя более правильно использовать сертификаты.
PFS = Perfect Forward Secrecy, этот параметр, если включен, позволяет быть уверенным, что тот же самый ключ не сгенерируется дважды. По умолчанию, pfs=no. Подробнее: PFS — VPN Tutorial.
Параметр rekey указывает, должно ли соединение быть пересмотрено, когда время на исходе. Согласно примерам поставляемым с Openswan IPSec (/etc/ipsec.d/examples), невозможно менять ключ сессии, если на другом конце туннеля %any (любой клиент), поэтому нужно предоставить клиенту возможность смены ключа. То есть, по умолчанию, rekey=no. Однако у меня по историческим причинам осталось rekey=yes, в таком виде я его и оставлю.
Тип соединения. Значения могут быть tunnel, transport, transport_proxy, passthrough, drop, reject. Значение по умолчанию =tunnel, этот режим самый правильный и безопасный. В режиме passthrough, например, никакой IPSec обработки производиться не будет.
Описание левого конца туннеля. Вообще говоря, «левый» и «правый» понятия условные, и взаимозаменяемые. В нашем примере, для определенности мы считаем, что левый конец туннеля это сервер, правый – удаленный клиент. Но можно их и поменять местами, ничего от этого измениться не должно.
Описание правого конца туннеля. leftprotoport и rightprotoport это параметры, разрешающие протоколы и порты соответствующим соединениям. Они также называются Port Selectors. В качестве аргумента – число или название, которое можно найти в /etc/protocols, например leftprotoport=icmp, или же комбинация протокол/порт, например tcp/smtp. Порт может быть обозначен числом (25) или названием (smtp), которое может быть найдено в /etc/services. Ключевое слово %any означает, что разрешены все порты указанного протокола. Наиболее часто эта опция используется для разрешения l2tp пакетов через UDP порт 1701: leftprotoport=17/1701. Некоторые клиенты, такие как старые версии Windows XP и некоторые Mac OS X используют случайно выбранный порт с высоким номером. В этом случае можно использовать rightprotoport=17/%any, чтобы разрешить весь UDP траффик для такого соединения. Другой обходной путь — указать 17/0, что означает любой единичный UDP порт (не UDP порт «0»).
Эти три параметра необходимы для определения и удаления мертвых соединений. Например, iPhone не разрывает соединение корректно, и такое поведение, в общем, характерно для мобильных устройств. Он просто «пропадает» из сети. Если при этом за мобильным устройством жестко закреплен IP адрес, то повторно переподключиться оно уже не сможет. В IPSec предусмотрен механизм определения мертвых соединений «Dead Peer Detection» (RFC3706), позволяющий на одном конце туннеля определить что туннель разрушен, и сделать соответствующие действия. Параметр delay это время в секундах, прошедшее от последнего полученного пакета через IPSec туннель, в течение которого нужно подождать прежде чем отправить DPD пакет для проверки состояния туннеля. Значение по умолчанию 30, поддерживаются значения от 0 до 86400, значение 0 отключит DPD. Параметр timeout это время в секундах, на протяжении которого должен прийти отклик DPD или любой новый траффик, если этого не происходит, туннель будет считаться разрушенным. Значение по умолчанию 120 сек, принимаются значения от 0 до 86400. Последний параметр action указывает что необходимо сделать если туннель разрушен. Значениями могут быть hold (по умолчанию), restart или clear. hold и restart будут перезапускать туннель как только он окажется разрушенным, с той разницей, что hold обеспечивает уверенность, что пакеты предназначенные для передачи по туннелю не будут передаваться пока туннель не возобновит работу. Значение clear просто удаляет туннель, если он оказался разрушенным.
auto=add означает загрузить соединение но не запускать его. Другие значения: ignore, route, start.
Теперь откроем файл /etc/ipsec.secrets и добавим в него общий пароль. Для этого просто дописываем в конец файла строку типа (10.0.0.2 это локальный адрес VPN сервера, SharedSec – собственно общий пароль):
Дополнение! Файл с паролями нужно заблокировать:
Когда настройки завершены, перезапускаем IPSec:
(другие доступные команды: start, stop, version)
3. Проверка работоспособности IPSec
Теперь самое время проверить работоспособность IPSec. Но вначале немножко донастроим роутер. Если включен NAT-T, а он по умолчанию включен (см. /etc/ipsec.conf), то нужно настроить на роутере переадресацию двух необходимых для IPSec портов UDP/500 (Internet Key Exchange (IKE)) и UDP/4500 (IPsec NAT-T) с внешнего IP на локальный адрес VPN сервера, а также разрешить трансфер протоколов ESP (протокол номер 50) и AH (51). Трансфер протоколов 50 и 51 осуществляется галочкой IPsec Passthrough (для роутеров типа TP-Link и Asus, и он по умолчанию включен для роутеров AirPort).
Также, сразу настройте переадресацию порта UDP/1701 на локальный адрес VPN сервера – этот порт нам пригодится при настройке L2TP.
Если ваш VPN сервер сам же является роутером, и имеет 2 сетевых интерфейса, следует добавить несколько правил в iptables в Chain INPUT:
Здесь 12.34.56.78 – это ВНЕШНИЙ IP адрес сервера. Подробнее о работе с iptables смотрим здесь: IptablesHowTo.
Теперь создайте на клиентской машине VPN соединение типа L2TP/IPSec, используя заданный Shared Secret и любой логин/пароль, и попробуйте подключиться к нему. Для отслеживания процесса подключения в режиме реального времени используйте команды:
Подключение оборвется, но вы должны найти в логе auth.log на сервере попытки подключения с таким отчетом: «STATE_QUICK_R2: IPsec SA established tunnel mode».
А на клиенте в логе ppp.log должно быть примерно такое (лог для Mac OS X Snow Leopard):
Хотя в Mountain Lion ppp.log будет менее информативен:
Это означает, что IPSec работает с preshared ключом.
Для проверки состояния IPSec можете использовать пару полезных команд:
В отчете команды verify вы можете увидеть такое:
Это значит, что нужно сделать то что оно просит, иначе ваша сеть будет засоряться лишними ICMP пакетами, а это нехорошо.
Чтобы отключить отправку и прием ICMP пакетов проще всего сделать и выполнить shell-скрипт следующего содержания:
Еще раз запустите sudo ipsec verify и убедитесь что все в порядке.
Пусть вас не смущают строки
Как описано в пользовательской рассылке Openswan это нормально. Просто убедитесь, что все остальные важные параметры отмечены как [OK].
4. Установка L2TP
L2TP обеспечивает туннель для обмена данными, но не обеспечивает шифрование и аутентификацию (правильнее сказать, что L2TP аутентифицирует пользователей, но не компьтеры). Поэтому L2TP часто используется в связке с IPSec. Примечательно, что Apple и Microsoft ссылаются на L2TP как на безопасную VPN технологию, но не уточняют, что собственно безопасность обеспечивается благодаря IPSec.
Реализация L2TP, которая чаще всего используется с IPSec от Opensawn это xl2tpd.
xl2tpd можно установить из репозитория текущей версии Ubuntu:
А можно сделать еще хитрее, и установить версию более новую, доступную в последнем репозитории Ubuntu (13.10 на момент написания статьи). Для этого в файл /etc/apt/sources.list надо добавить репозиторий (в данном примере это репозиторий для версии 13.10):
А потом той же командой
Качать и собирать xl2tpd из исходников у меня как-то не сложилось. В репозитории 13.10 относительно свежая версия 1.3.1. Можно также качнуть пакет из репозитория и установить вручную (http://packages.ubuntu.com/saucy/net/xl2tpd) но так не рекомендуется, поэтому сделайте лучше по схеме с подменой репозитория (если конечно у вас не самая новая версия Ubuntu).
Далее откройте конфигурационный файл /etc/xl2tpd/xl2tpd.conf и приведите его к примерно такому виду:
«ip range» это диапазон внутренних IP адресов, которые будут выдаваться клиентам, которые подключаются удаленно. Убедитесь, что этот диапазон не перекрывается с адресами вашей локальной сети и не конфликтует с адресным диапазоном во внутренней сети клиента. Так как большинство бытовых роутеров используют диапазоны 172.16.X.X и 192.168.X.X, лучшей стратегией будет избегать такой очевидной адресации в своей сети. «local ip» это внутренний адрес L2TP сервера, он НЕ должен быть в диапазоне адресов выдаваемых клиентам.
Для желающих в деталях ознакомиться с конфигурированием xl2tpd, вот man-страница об xl2tpd.conf на русском: http://manpages.ylsoftware.com/ru/xl2tpd.conf.5.html
Содержимое файла /etc/ppp/options.xl2tpd:
ms-dns — это адреса DNS серверов, которые вам предоставил ваш провайдер интернета. Соответственно, эти адреса раздадутся подключающимся клиентам, как рекомендуемые к использованию DNS. Можно использовать «восьмерки».
посмотреть последние записи в логе отладки можно командой:
Еще подробнее про настройку L2TP, в частности про путаницу с аутентификацией в L2TP, можно почитать здесь: http://www.jacco2.dds.nl/networking/openswan-l2tp.html#L2TPconfigLinux
Теперь, когда мы установили и настроили L2TP, проверим его работу. Добавим тестового пользователя в /etc/ppp/chap-secrets:
Перезагрузим xl2tpd, выполнив команду:
Также при отладке могут пригодиться следующие команды:
– команды для запуска и останова xl2tpd;
– запуск L2TP в отладочном режиме;
В дополнение, если вы используете iptables для файерволинга, убедитесь в том, что включено перенаправление пакетов, чтобы можно было пользоваться интернетом после подключения к VPN. Для этого выполните команду:
Теперь на клиентском компьютере отредактируйте VPN подключение, созданное на шаге 3 (Проверка работоспособности IPSec), добавив в него имя тестового пользователя и пароль.
Попробуйте подключиться. На этот раз соединение должно устанавливаться без ошибок. Желательно понаблюдать в режиме реального времени соответствующие логи, чтобы лучше понимать процесс установки соединения. Если все ок, включите на клиенте также опцию «Отправлять весь трафик через VPN», и проверьте, работает ли интернет в этом режиме. Это даст возможность понять, правильно ли работает форвардинг пакетов в iptables. Также проверьте, какие DNS сервера получает клиент как рекомендованные от L2TP сервера, неверные DNS могут стать очевидной причиной неработоспособности интернета.
На этом наше введение в работу с VPN L2TP/IPSec завершается. Надеюсь данная статья, написанная на основе 3-х летнего наблюдения и коррекции домашнего VPN сервера, позволит читателю избежать распространенных ошибок и главное, осознанно вносить изменения в конфигурационые файлы. Параметры из файлов настроек часто не комментируют, предлагая просто скопировать готовый конфиг, но как вы уже наверное поняли, без понимания деталей невозможно заставить эту сложную систему работать стабильно.
ДОПОЛНЕНИЕ
После перезагрузки компьютера Pluto (ядро Openswan) почему-то не стартует. Это сразу же проявляется в невозможности подключиться по VPN, и если ввести команду sudo ipsec verify, то увидим такой вывод:
Я не особо разбирался в причинах такого поведения, просто добавил следующий (уже знакомый вам) скрипт в /etc/rc.local:
1 Trackback / Pingback
Оставить комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
Источник
