«Шифрование…это мощное оборонительное оружие для свободных людей. Оно предоставляет технические гарантии конфиденциальности, независимо от того кто управляет государством… Сложно представить более мощный и менее опасный инструмент для свободы.»
Эстер Дайсон
Цитата из книги «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: http://ru.wikipedia.org/wiki/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 и устанавливаем необходимые для сборки пакета библиотеки:
sudo apt-get install libgmp3-dev gawk flex bison
Создаем временную папку, например на рабочем столе (mkdir Desktop/temp) и перейдя в нее (cd Desktop/temp), скачиваем, собираем и устанавливаем Openswan из исходников (как мы договорились, рассматриваем версию 2.6.38):
wget http://www.openswan.org/download/openswan-2.6.38.tar.gz tar xf openswan-2.6.38.tar.gz cd openswan-2.6.38 make programs sudo make install
Хозяйке на заметку – не стоит удалять папку с исходниками после установки программы. В этой папке содержится скрипт, отвечающий за удаление программы, это относится ко всем корректно написанным программам для 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, так как это подсеть, используемая локальными компьютерами.
##############/etc/ipsec.conf############## version 2.0 # basic configuration config setup plutoopts="--perpeerlog" nat_traversal=yes # exclude networks used on server side by adding %v4:!a.b.c.0/24 virtual_private=%v4:192.168.0.0/16,%v4:192.168.1.0/24,%v4:172.16.0.0/12,%v4:!10.0.0.0/24 # OE is now off by default. Uncomment and change to on, to enable. oe=off protostack=netkey # Add connections here # for more examples, see /etc/ipsec.d/examples/ conn NAT-2-NAT forceencaps=yes authby=secret pfs=no rekey=yes keyingtries=6 ikelifetime=2h salifetime=8h type=tunnel left=10.0.0.2 leftsubnet=10.0.0.0/24 leftnexthop=%defaultroute leftprotoport=17/1701 right=%any rightsubnet=vhost:%priv,%no rightprotoport=17/0 dpddelay=10 dpdtimeout=90 dpdaction=clear auto=add ##########################################
Прокомментируем некоторые важные параметры:
forceencaps=yes
Принудительная UDP инкапсуляция для ESP пакетов, даже если NAT не обнаружен. Это может помочь обойти ограничивающие файерволы. Значение по умолчанию =no, лучше начать с него, если будет работать со сбоями, попробуйте =yes.
authby=secret
Аутентификация по паролю (shared secret) — самый простой способ, хотя более правильно использовать сертификаты.
pfs=no
PFS = Perfect Forward Secrecy, этот параметр, если включен, позволяет быть уверенным, что тот же самый ключ не сгенерируется дважды. По умолчанию, pfs=no. Подробнее: PFS — VPN Tutorial.
rekey=yes
Параметр rekey указывает, должно ли соединение быть пересмотрено, когда время на исходе. Согласно примерам поставляемым с Openswan IPSec (/etc/ipsec.d/examples), невозможно менять ключ сессии, если на другом конце туннеля %any (любой клиент), поэтому нужно предоставить клиенту возможность смены ключа. То есть, по умолчанию, rekey=no. Однако у меня по историческим причинам осталось rekey=yes, в таком виде я его и оставлю.
type=tunnel
Тип соединения. Значения могут быть tunnel, transport, transport_proxy, passthrough, drop, reject. Значение по умолчанию =tunnel, этот режим самый правильный и безопасный. В режиме passthrough, например, никакой IPSec обработки производиться не будет.
left=10.0.0.2 leftsubnet=10.0.0.0/24 leftnexthop=%defaultroute leftprotoport=17/1701
Описание левого конца туннеля. Вообще говоря, «левый» и «правый» понятия условные, и взаимозаменяемые. В нашем примере, для определенности мы считаем, что левый конец туннеля это сервер, правый – удаленный клиент. Но можно их и поменять местами, ничего от этого измениться не должно.
right=%any rightsubnet=vhost:%priv,%no rightprotoport=17/0
Описание правого конца туннеля. 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»).
dpddelay=10 dpdtimeout=90 dpdaction=clear
Эти три параметра необходимы для определения и удаления мертвых соединений. Например, 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
auto=add означает загрузить соединение но не запускать его. Другие значения: ignore, route, start.
Теперь откроем файл /etc/ipsec.secrets и добавим в него общий пароль. Для этого просто дописываем в конец файла строку типа (10.0.0.2 это локальный адрес VPN сервера, SharedSec – собственно общий пароль):
10.0.0.2 %any: "SharedSec"
Дополнение! Файл с паролями нужно заблокировать:
$ sudo chmod 640 /etc/ipsec.secrets
Когда настройки завершены, перезапускаем IPSec:
sudo /etc/init.d/ipsec restart
(другие доступные команды: 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:
-A INPUT -p 50 -j ACCEPT -A INPUT -p udp -d 12.34.56.78 --dport 500 -j ACCEPT -A INPUT -p udp -d 12.34.56.78 --dport 4500 -j ACCEPT
Здесь 12.34.56.78 – это ВНЕШНИЙ IP адрес сервера. Подробнее о работе с iptables смотрим здесь: IptablesHowTo.
Теперь создайте на клиентской машине VPN соединение типа L2TP/IPSec, используя заданный Shared Secret и любой логин/пароль, и попробуйте подключиться к нему. Для отслеживания процесса подключения в режиме реального времени используйте команды:
На сервере:
tail -f /var/log/auth.log
На клиенте:
tail -f /var/log/system.log tail -f /var/log/ppp.log
Подключение оборвется, но вы должны найти в логе auth.log на сервере попытки подключения с таким отчетом: «STATE_QUICK_R2: IPsec SA established tunnel mode».
А на клиенте в логе ppp.log должно быть примерно такое (лог для Mac OS X Snow Leopard):
Sun Apr 10 15:30:03 2011 : L2TP connecting to server 'server1.kaplunenko.name' (XXX.XXX.XXX.XXX)… Sun Apr 10 15:30:03 2011 : IPSec connection started Sun Apr 10 15:30:03 2011 : IPSec phase 1 client started Sun Apr 10 15:30:03 2011 : IPSec phase 1 server replied Sun Apr 10 15:30:04 2011 : IPSec phase 2 started Sun Apr 10 15:30:04 2011 : IPSec phase 2 established Sun Apr 10 15:30:04 2011 : IPSec connection established Sun Apr 10 15:30:04 2011 : L2TP sent SCCRQ Sun Apr 10 15:30:24 2011 : L2TP cannot connect to the server
Хотя в Mountain Lion ppp.log будет менее информативен:
Mon Jan 27 23:48:00 2014 : L2TP connecting to server 'server1.kaplunenko.name' (XXX.XXX.XXX.XXX)... Mon Jan 27 23:48:00 2014 : IPSec connection started Mon Jan 27 23:48:01 2014 : IPSec connection established Mon Jan 27 23:48:21 2014 : L2TP cannot connect to the server
Это означает, что IPSec работает с preshared ключом.
Для проверки состояния IPSec можете использовать пару полезных команд:
sudo ipsec verify sudo ipsec auto --status
В отчете команды verify вы можете увидеть такое:
NETKEY: Testing XFRM related proc values [FAILED]
Please disable /proc/sys/net/ipv4/conf/*/send_redirects or NETKEY will cause the sending of bogus ICMP redirects!
[FAILED]
Please disable /proc/sys/net/ipv4/conf/*/accept_redirects or NETKEY will accept bogus ICMP redirects!
Это значит, что нужно сделать то что оно просит, иначе ваша сеть будет засоряться лишними ICMP пакетами, а это нехорошо.
Чтобы отключить отправку и прием ICMP пакетов проще всего сделать и выполнить shell-скрипт следующего содержания:
#!/bin/bash # Disable ICMP Redirect Send for f in /proc/sys/net/ipv4/conf/*/send_redirects; do echo 0 > $f done # Disable ICMP Redirect Acceptance for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do echo 0 > $f done
Еще раз запустите sudo ipsec verify и убедитесь что все в порядке.
Пусть вас не смущают строки
SAref kernel support [N/A] Checking /bin/sh is not /bin/dash [WARNING] Opportunistic Encryption Support [DISABLED]
Как описано в пользовательской рассылке Openswan это нормально. Просто убедитесь, что все остальные важные параметры отмечены как [OK].
4. Установка L2TP
L2TP обеспечивает туннель для обмена данными, но не обеспечивает шифрование и аутентификацию (правильнее сказать, что L2TP аутентифицирует пользователей, но не компьтеры). Поэтому L2TP часто используется в связке с IPSec. Примечательно, что Apple и Microsoft ссылаются на L2TP как на безопасную VPN технологию, но не уточняют, что собственно безопасность обеспечивается благодаря IPSec.
Реализация L2TP, которая чаще всего используется с IPSec от Opensawn это xl2tpd.
xl2tpd можно установить из репозитория текущей версии Ubuntu:
sudo apt-get install xl2tpd
А можно сделать еще хитрее, и установить версию более новую, доступную в последнем репозитории Ubuntu (13.10 на момент написания статьи). Для этого в файл /etc/apt/sources.list надо добавить репозиторий (в данном примере это репозиторий для версии 13.10):
deb http://cz.archive.ubuntu.com/ubuntu saucy main universe
А потом той же командой
sudo apt-get install xl2tpd
произвести установку.
Качать и собирать xl2tpd из исходников у меня как-то не сложилось. В репозитории 13.10 относительно свежая версия 1.3.1. Можно также качнуть пакет из репозитория и установить вручную (http://packages.ubuntu.com/saucy/net/xl2tpd) но так не рекомендуется, поэтому сделайте лучше по схеме с подменой репозитория (если конечно у вас не самая новая версия Ubuntu).
Далее откройте конфигурационный файл /etc/xl2tpd/xl2tpd.conf и приведите его к примерно такому виду:
[global] port = 1701 auth file = /etc/ppp/chap-secrets access control = no ; rand source = dev ; [lns default] ip range = 10.0.0.22-10.0.0.30 local ip = 10.0.0.21 length bit = yes refuse chap = yes refuse pap = yes require authentication = yes ; unix authentication = no ; * Use /etc/passwd for auth. name = server1.kaplunenko.name ; * Report this as our hostname ppp debug = no pppoptfile = /etc/ppp/options.xl2tpd
«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:
require-mschap-v2 ms-dns 109.86.2.2 ms-dns 109.86.2.21 asyncmap 0 auth idle 1800 mtu 1410 mru 1410 connect-delay 5000 nodefaultroute crtscts lock hide-password modem debug name l2tpd proxyarp lcp-echo-interval 30 lcp-echo-failure 4
ms-dns — это адреса DNS серверов, которые вам предоставил ваш провайдер интернета. Соответственно, эти адреса раздадутся подключающимся клиентам, как рекомендуемые к использованию DNS. Можно использовать «восьмерки».
посмотреть последние записи в логе отладки можно командой:
less /var/log/debug
Еще подробнее про настройку L2TP, в частности про путаницу с аутентификацией в L2TP, можно почитать здесь: http://www.jacco2.dds.nl/networking/openswan-l2tp.html#L2TPconfigLinux
Теперь, когда мы установили и настроили L2TP, проверим его работу. Добавим тестового пользователя в /etc/ppp/chap-secrets:
# user server password ip test l2tpd testpassword *
Перезагрузим xl2tpd, выполнив команду:
sudo /etc/init.d/xl2tpd restart
Также при отладке могут пригодиться следующие команды:
/etc/init.d/xl2tpd stop /start
– команды для запуска и останова xl2tpd;
xl2tpd -D
– запуск L2TP в отладочном режиме;
В дополнение, если вы используете iptables для файерволинга, убедитесь в том, что включено перенаправление пакетов, чтобы можно было пользоваться интернетом после подключения к VPN. Для этого выполните команду:
iptables --table nat --append POSTROUTING --jump MASQUERADE echo 1 > /proc/sys/net/ipv4/ip_forward
Теперь на клиентском компьютере отредактируйте VPN подключение, созданное на шаге 3 (Проверка работоспособности IPSec), добавив в него имя тестового пользователя и пароль.
Попробуйте подключиться. На этот раз соединение должно устанавливаться без ошибок. Желательно понаблюдать в режиме реального времени соответствующие логи, чтобы лучше понимать процесс установки соединения. Если все ок, включите на клиенте также опцию «Отправлять весь трафик через VPN», и проверьте, работает ли интернет в этом режиме. Это даст возможность понять, правильно ли работает форвардинг пакетов в iptables. Также проверьте, какие DNS сервера получает клиент как рекомендованные от L2TP сервера, неверные DNS могут стать очевидной причиной неработоспособности интернета.
На этом наше введение в работу с VPN L2TP/IPSec завершается. Надеюсь данная статья, написанная на основе 3-х летнего наблюдения и коррекции домашнего VPN сервера, позволит читателю избежать распространенных ошибок и главное, осознанно вносить изменения в конфигурационые файлы. Параметры из файлов настроек часто не комментируют, предлагая просто скопировать готовый конфиг, но как вы уже наверное поняли, без понимания деталей невозможно заставить эту сложную систему работать стабильно.
ДОПОЛНЕНИЕ
После перезагрузки компьютера Pluto (ядро Openswan) почему-то не стартует. Это сразу же проявляется в невозможности подключиться по VPN, и если ввести команду sudo ipsec verify, то увидим такой вывод:
Checking your system to see if IPsec got installed and started correctly: Version check and ipsec on-path [OK] Linux Openswan U2.6.38/K2.6.32-37-generic (netkey) Checking for IPsec support in kernel [OK] SAref kernel support [N/A] NETKEY: Testing XFRM related proc values [FAILED] Please disable /proc/sys/net/ipv4/conf/*/send_redirects or NETKEY will cause the sending of bogus ICMP redirects! [FAILED] Please disable /proc/sys/net/ipv4/conf/*/accept_redirects or NETKEY will accept bogus ICMP redirects! [OK] Checking that pluto is running [FAILED] whack: Pluto is not running (no "/var/run/pluto/pluto.ctl") Checking for 'ip' command [OK] Checking /bin/sh is not /bin/dash [WARNING] Checking for 'iptables' command [OK] Opportunistic Encryption Support [DISABLED]
Я не особо разбирался в причинах такого поведения, просто добавил следующий (уже знакомый вам) скрипт в /etc/rc.local:
for each in /proc/sys/net/ipv4/conf/* do echo 0 > $each/accept_redirects echo 0 > $each/send_redirects done /etc/init.d/ipsec restart
Оставить комментарий
Для отправки комментария вам необходимо авторизоваться.