L2tp client linux debian
Подробности обо всех параметрах в конфигах, вы можете найти в man xl2tpd.conf и /etc/ppp/options
/etc/ppp/ip-up.d/corbinavpn
Причина создания этого файла, на прямую связана с общей недоработкой ppp-клиента в линуксе.
# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.227.168.0 0.0.0.0 255.255.248.0 U 0 0 0 eth0 0.0.0.0 10.227.168.1 0.0.0.0 UG 0 0 0 eth0
Первая строчка означает, что со всеми компьютерами в пределах моей подсети (10.227.168.0/21), мой компьютер общается на прямую, через устройство eth0.
# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 85.21.0.254 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 10.227.168.0 0.0.0.0 255.255.248.0 U 0 0 0 eth0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
Система больше ничего не знает о существовании шлюза 10.227.168.1. Существование и смысл маршрута 85.21.0.254 (на VPN-сервер), мне к примеру вообще непонятны. Эта строчка в таблице маршрутизации гласит о том, что система общается с VPN-сервером через устройство ppp0. Какой смысл, если она не знает о том, что это надо делать через шлюз? Да и вообще, зачем ей общаться с VPN-сервером, через VPN-тунель? По умолчанию мы общаемся через устройство ppp0, так что подключение у нас просто упадет и работать ничего не будет
Итак, в файле /etc/ppp/ip-up.d/corbinavpn мы обьясним системе, что с VPN и DNS серверами она должна общаться через наш локальный шлюз.
for i in $(grep "^nameserver" /etc/resolv.conf | awk '') ; do route add -host $i gw шлюз done
route add -net 85.21.0.0/24 gw шлюз
# vim /etc/ppp/ip-up.d/corbinavpn #!/bin/sh [ $6 = "corbina" ] || exit 0 export GATEWAY=10.227.168.1 for i in $(grep "^nameserver" /etc/resolv.conf | awk '') ; do route add -host $i gw шлюз done route del $5 dev $1 route add -net 85.21.0.0/24 gw $GATEWAY
chmod +x /etc/ppp/ip-up.d/corbinavpn
85.21.192.3 10.227.168.1 255.255.255.255 UGH 0 0 0 eth0 213.234.192.8 10.227.168.1 255.255.255.255 UGH 0 0 0 eth0 85.21.0.0 10.227.168.1 255.255.255.0 UG 0 0 0 eth0 233.32.240.0 10.227.169.6 255.255.255.0 UG 0 0 0 eth0 172.16.16.0 10.227.168.1 255.255.255.0 UG 0 0 0 eth0 10.227.168.0 0.0.0.0 255.255.248.0 U 0 0 0 eth0 10.0.0.0 10.227.168.1 255.0.0.0 UG 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
Первые две строчки адреса на DNS, чтобы наш компьютер не пытался общаться с ними через VPN туннель. Третья: общаемся с VPN сервером через наш районный шлюз. 4-5 — IPTV, с мультикастом (233.32.240.0) общаемся через интерфейс eth0, 10.227.169.6 — это мой ip. 6 — моя подсеть. 7 — юзеры за пределом моей подсети. 8 — локальное кольцо. 9 — маршрут по умолчанию (все что не описано выше, идет через этот маршрут).
Диагностика проблем
В первую очередь нужно обратить внимание на таблицу маршрутизации. Проверить доступность VPN-сервера (ping tp.corbina.net). Попробовать запустить xl2tpd с ключём -D.
if !([ -f /var/run/xl2tpd/l2tp-control ]) ; then mkdir -p /var/run/xl2tpd touch /var/run/xl2tpd/l2tp-control fi
Только не в секцию start (как это указано в некоторых руководствах), а где-то между DESC=xl2tpd и case «$1» in.
grep -E 'pppd|xl2tpd' /var/log/messages
/etc/network/interfaces
auto lo eth0 iface lo inet loopback iface eth0 inet dhcp
В Debian настроить VPN PPTP/L2TP можно также с помощью графической утилиты vpnpptp: http://code.google.com/p/vpnpptp/
Linux Debian + L2TP + IPsec ( Налаживаем подключение linux-системы к L2TP-серверу, с обязательным шифрованием VPN-трафика. )
OS: «Linux Debian 8/9/10», «Linux Ubuntu Server 16/18/20 LTS».
Apps: «strongswan», «xl2tpd», «ip», «netplan».
Задача: наладить подключение linux-системы к L2TP-серверу, с обязательным шифрованием VPN-трафика.
Для справки: L2TP («Layer 2 Tunneling Protocol») представляет собой сетевой протокол туннелирования канального уровня, сочетающий в себе протокол L2F («Layer 2 Forwarding»), разработанный компанией «Cisco», и протокол PPTP корпорации «Microsoft». Позволяет организовывать VPN с заданными приоритетами доступа, однако не содержит в себе средств шифрования и механизмов аутентификации — потому для создания защищённой VPN его используют совместно с IPSec.
Для управления L2TP-соединениями воспользуемся подсистемой «xl2tpd», а для шифрования — «strongSwan».
Последовательность действий такова:
1. Конфигурирование подсистемы IPsec-шифрования;
2. Конфигурирование подсистемы L2TP-подключений;
3. Автоматизация добавления сетевых маршрутов;
4. Ручное управление VPN-соединениями;
5. Автоматизация инициализации VPN-соединений.
Конфигурирование подсистемы IPsec-шифрования.
Инсталлируем необходимые приложения и утилиты:
У проекта «strongSwan» хорошая документация, из которой для решения нашей простой задачи вполне достаточно чтения пары страниц: «ConnSection» и «IpsecCommand».
В основном конфигурационном файле подсистемы IPsec-шифрования «strongSwan» описываем общие параметры и правила шифрования трафика от IP до IP (пример связи с L2TP/типовым IPsec-шлюзом на базе «RouterOS»):
# ipsec.conf — strongSwan IPsec configuration file
# Basic configuration
config setup
# strictcrlpolicy=yes
# uniqueids = no
# nat_traversal = yes
# protostack = netkey
# Default options for encryption of connections
conn %default
ikelifetime = 60m
keylife = 20m
rekeymargin = 3m
keyingtries = 1
keyexchange = ikev1
authby = secret
ike = aes128-sha1-modp2048!
esp = aes128-sha1-modp2048!
# Encryption of traffic to the «l2tp.example.net»
conn ipsec-gate.example.net
# Automatic start of encryption at system startup
auto = start
# Restarting encryption if negotiation fails
dpdaction = restart
# Restart encryption on unexpected close
closeaction = restart
# Reconnect unlimited number of times
keyingtries = %forever
keyexchange = ikev1
pfs = no
authby = secret
type = transport
left = %defaultroute
leftprotoport = 17/1701
right = 100.200.250.21
rightprotoport = 17/1701
Секретный ключ шифрования PSK («Pre-Shared Key»), используемый для предварительной клиент-серверной аутентификации, выносится в отдельный файл, где указывается, в каких условиях таковой должен применяться:
Защищаем файл с паролями от доступа посторонних:
Для применения изменений в конфигурации перезапускаем сервис подсистемы IPSec-шифрования:
Если конфигурация IPsec выше подразумевает автоматическое включение шифрования, то сразу после перезапуска «strongSwan» мы уже должны получить желаемое.
Если режим запуска шифрования для какого-то направления выбран «ручной» (auto=add), то запускаем его соответствующей командой:
Соответственно, при необходимости, аналогичной ручному запуску командой можно шифрование в заданном направлении остановить:
Просматриваем статус IPsec-соединений:
Security Associations (1 up, 0 connecting):
ipsec-gate.example.net[1]: ESTABLISHED 43 seconds ago, 10.20.30.45. 100.200.250.21
ipsec-gate.example.net{1}: INSTALLED, TRANSPORT, reqid 1, ESP in UDP SPIs: c57b51bb_i 04fa2652_o
ipsec-gate.example.net{1}: 10.20.30.45/32[udp/l2f] === 100.200.250.21/32[udp/l2f]
Теперь весь трафик к целевому сетевому узлу инкапсулируется в IPsec.
Конфигурирование подсистемы L2TP-подключений.
Инсталлируем необходимые приложения и утилиты:
Параметры для настройки L2TP-подключения посредством «xl2tpd» хорошо описаны во встроенном руководстве по эксплуатации, вызываемом командой «man xl2tpd.conf» (как вариант, можно посмотреть web-версию).
Описываем параметры VPN-канала, который должен быть установлен посредством «xl2tpd»:
[lac l2tp-gate.example.net]
lns = 100.200.250.21
;ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd.client-gate.example.net
length bit = yes
autodial = yes
redial = yes
redial timeout = 30
Описываем параметры PPP-соединения, включая логин и пароль для аутентификации:
ipcp-accept-local
ipcp-accept-remote
refuse-eap
require-mschap-v2
noccp
noauth
mtu 1280
mru 1280
noipdefault
nodefaultroute
usepeerdns
connect-delay 5000
name vpn-node0-tunnel
password strongSecretPassword
Защищаем файл с паролем от доступа посторонних:
Для применения изменений в конфигурации перезапускаем сервис:
Если конфигурация «xl2tpd» выше подразумевает автоматическое создание VPN-туннеля, то сразу после перезапуска «xl2tpd» мы уже должны получить желаемое.
Если режим запуска создания VPN-туннеля выбран «ручной» (autodial=no), то запускаем его соответствующей командой:
Соответственно, при необходимости, аналогичной ручному режиму командой можно определённый VPN-туннель выключить и удалить виртуальный интерфейс:
После вышеприведённых действий в перечне сетевых интерфейсов должен появится новый виртуальный PPP-интерфейс, через который осуществляется передача трафика до целевого L2TP-сервера:
.
ppp0: flags=4305 mtu 1280
inet 10.172.255.2 netmask 255.255.255.255 destination 10.172.255.1
ppp txqueuelen 3 (Point-to-Point Protocol)
.
Простейшим способом проверяем доступность опорного IP-адреса на стороне L2TP-сервера:
Слегка напрягает, что сервисы, обеспечивающие работу IPsec и L2TP прослушивают ряд портов в ожидании входящих подключений тогда, как нам требуется от них только работа в роли клиентов — но, насколько я понимаю, это неотъемлемая особенность работы подсистем, обеспечивающих двухсторонние сетевые туннели:
Proto . Local Address Foreign Address PID/Program name
udp . 0.0.0.0:4500 0.0.0.0:* . /charon
udp . 0.0.0.0:500 0.0.0.0:* . /charon
udp . 0.0.0.0:1701 0.0.0.0:* . /xl2tpd
.
Разумеется, можно прикрыть сетевые сервисы защитным экраном «iptables», предписав предоставлять доступ к портам только для запросов со стороны L2TP-сервера.
Автоматизация добавления сетевых маршрутов.
В производственной среде VPN-туннели чаще предназначены для передачи только выделенного трафика — к тем сервисам, что нуждаются в изоляции внутри корпоративной сети. Соответственно, после установления VPN-соединения, необходимо активировать дополнительные сетевые маршруты, направляющие выделенный трафик не через «шлюз по умолчанию», а через L2TP-сервер. Такой функционал давно реализован через систему «хуков (hook)», запускающий произвольные скрипты при изменении состояния PPP-соединений.
Пишем простой bash-скрипт, автоматически запускаемый при инициализации PPP-соединения и добавляющий произвольный набор маршрутов с предварительной проверкой наличия опорной IP-адресации (в имени скрипта «ppp-hook» не допускается символов «.», так что для наглядности заменяем их «-«):
if [[ «${PPP_LOCAL}» == «10.172.255.2» ]] ; then
sleep 1
ip route add 10.10.10.0/24 via 10.172.255.1
ip route add 192.168.10.0/24 via 10.172.255.1
fi
Не забываем сделать скрипт «исполняемым» (в противном случае подсистема PPP проигнорирует его):
Ручное управление VPN-соединениями.
Учитывая то, что сервисы шифрования и поддержки PPP-туннеля реализованы в двух независимых подсистемах, ради обеспечения должного уровня безопасности важно не забывать об очерёдности их включения и выключения — чтобы в какой-то момент через недоверенные участки сети не пошёл незашифрованный трафик.
Последовательная инициализации IPsec-шифрования и L2TP-туннеля:
Последовательное выключение L2TP-туннеля и IPsec-шифрования:
# xl2tpd-control disconnect l2tp-gate.example.net && xl2tpd-control remove l2tp-gate.example.net && ipsec down ipsec-gate.example.net
Автоматизация запуска посредством «ifupdown».
При автоматическом запуске IPsec-шифрования и L2TP-туннеля нет необходимости отдельно стартовать эти сервисы. Но, в каких-то конфигурациях это может потребоваться:
.
iface eth0 inet dhcp
.
sleep 5 && post-up ipsec up ipsec-gate.example.net && xl2tpd-control connect l2tp-gate.example.net &
Автоматизация запуска посредством «Netplan».
Новомодная подсистема управления сетевой конфигурацией «Netplan» не имеет встроенного обработчика изменения состояния, что странно. Придётся воспользоваться дополнительным инструментом «Network Dispatcher»:
if [[ «${IFACE}» == «eth0» ]] ; then
sleep 5
ipsec up ipsec-gate.example.net && xl2tpd-control connect l2tp-gate.example.net &
fi
Добавляем скрипту статус «исполняемого» (иначе «networkd-dispatcher» проигнорирует его):
Поблагодарить автора ( сделайте свой денежный вклад в хорошее настроение )
Заметки и комментарии к публикации:
Оставьте свой комментарий ( выразите мнение относительно публикации, поделитесь дополнительными сведениями или укажите на ошибку )