vpn:ipsec-l2tpserver

6to4 amavis apache backup bacula bgp bind ca cisco dhcp dkim dns firewall gentoo gre greylisting ipset ipv4 ipv6 linux mail net netmask nginx openssl openswan oracle postfix proxy rsync silent-mode spam_filter ssh student tranparent vlan vpn vyatta windows
, ,

Описание архитектуры сети.

Локальная сеть содержит 2 IP подсети с адресами 172.16.0.0/15 и 111.222.33.0/24. Адреса из сети 172.16. логически упорядочены. Например: сервера расположены в блоке адресов 172.16.0., привилегированные рабочие станции в 172.16.1. и т.д. Есть центральный межсетевой экран, который прикрывает локальную сеть от внешнего мира. Кроме того, каждый из серверов имеет свой собственный локальный firewall.

Постановка задачи

Под VPN выделяется VLAN 172.17.33.0/24. VPN-сервер будет иметь адрес 172.17.33.2. Для VPN-клиентов выделяется блок 172.17.33.100-200. Остальные адреса остаются в резерве.

Необходимо обеспечить доступ VPN-клиентов как в локальную сеть, так и в Internet вне зависимости от того, откуда «пришёл» VPN-клиент: из локальной сети или из внешнего мира.

Поскольку основную массу клиентов составляют M$ Windows, а устанавливать дополнительное ПО нежелательно, то выбор возможных схем реализации VPN ограничен либо PPTP, либо IPSec/L2TP. С другой стороны, к первому кандидату есть ряд вопросов в плане обеспечения безопасности. Таким образом понимаем, что выбора-то у нас и нет.

Выбранный тип VPN хорош по ещё одной причине: существует целый ряд альтернативных клиентов, практически для любой операционной системы. Openswan, FreeS/WAN, Racoon в связке с l2tpd, rp-l2tp, xl2tpd для Linux; SSH Sentinel, SafeNet SoftRemote, Netscreen Remote Client, CoSine, Fortinet VPN client, Netlock Contivity VPN Client для Windows. Есть выбор для *BSD и Mac OS X.

Необходимое оборудование.

  1. машина на которой будет работать VPN-сервер.
  2. клиентская машина, на которой будем тестировать VPN-соединение. Лучше всего, если это будет ноутбук, тогда настроив VPN-соединение можно будет пройтись по знакомым и протестировать соединение в «боевых» условиях.

Необходимое ПО на стороне сервера

  1. openswan
  2. xl2tpd
  3. openssl
  4. ppp
  5. зависимости от предыдущих пакетов.

Крайне желательно, иметь ещё tcpdump, как минимум на момент отладки.

Конфигурирование ядра.

Использовались ядра sys-kernel/gentoo-sources-2.6.19-r5 и более поздние. 

Networking --->
  Networking options --->
    <*> Packet socket
    <*> Unix domain sockets
    <M> Transformation user configuration interface
    <M> PF_KEY sockets
    <M>   IP: AH transformation
    <M>   IP: ESP transformation
    <M>   IP: IPComp transformation
    <M>   IP: IPsec transport mode
    <M>   IP: IPsec tunnel mode
    <M>   IP: IPsec BEET mode
    <M>   INET: socket monitoring interface
    [*] Network packet filtering (replaces ipchains)  --->

Device Drivers --->
  Network device support --->
    [*] Network device support
    <M> PPP (point-to-point protocol) support
    <M>   PPP support for async serial ports
    <M>   PPP support for sync tty ports
    <M>   PPP Deflate compression
    <M>   PPP BSD-Compress compression
    <M>   PPP MPPE compression (encryption) (EXPERIMENTAL)
    <M>   PPP over Ethernet (EXPERIMENTAL)

Cryptographic options --->
    --- Cryptographic API
    <*>   HMAC support
    <*>   MD5 digest algorithm
    <M>   SHA1 digest algorithm
    <*>   DES and Triple DES EDE cipher algorithms
    <M>   AES cipher algorithms
    <M>   AES cipher algorithms (i586)

Установка ПО на сервере.

echo "net-dialup/xl2tpd ~x86" >> /etc/portage/package.keywords
emerge -pvt openswan xl2tpd openssl ppp

Конфигурирование xl2tpd и ppp.

Как правило все «мурзилки» начинают настройку сервера с настройки ipsec. Идем другим путем, т.к. настройки ipsec мы будем менять, а ppp и xl2tpd настраиваются только один раз.

/etc/xl2tpd/xl2tpd.conf
[global]
port = 1701
 
[lns default]
ip range = 172.17.33.100-172.17.33.200
local ip = 172.17.33.2
require chap = yes
refuse pap = yes
require authentication = yes
name = SuperVPN
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd
length bit = yes
/etc/ppp/options.l2tpd
ipcp-accept-local
ipcp-accept-remote
ms-dns 172.16.0.5
ms-wins 172.16.0.3
auth
crtscts
idle 1800
mtu 1200
mru 1200
nodefaultroute
debug
lock
proxyarp
connect-delay 5000
nologfd
/etc/ppp/chap-secrets
# Secrets for authentication using CHAP
# client        server  secret                  IP addresses
 
#################################################################
#User1 Full Name
user1 * "user1_vpn_pwd" 172.17.33.101
* user1 "user1_vpn_pwd" 172.17.33.101
#################################################################
 
#################################################################
#User2 Full Name
user2 * "user2_vpn_pwd" 172.17.33.102
* user2 "user2_vpn_pwd" 172.17.33.102
#################################################################

Настройка PSK VPN сервера.

IPSec требует авторизации клиентской машины в момент установления связи. Такая авторизация может быть выполнена на основе симметричных ключей (PreShared Keys – PSK), либо на основе асимметричных ключей-сертификатов. В начале лучше всего настроить авторизацию на основе PSK, т.к. это сделать существенно проще. После достижения полной работоспособности VPN и правильной настройки firewall'ов можно будет перевести авторизацию на сертификаты. И так… 

111.222.33.22 %any: PSK "superG00dParol"
version 2.0
 
config setup
        interfaces=%defaultroute
        protostack=netkey
        nat_traversal=yes
        virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!172.16.0.0/15
 
conn %default
        keyingtries=1
        compress=yes
        disablearrivalcheck=no
        authby=secret
        keyexchange=ike
        ikelifetime=240m
        keylife=60m
        rekey=no
        left=111.222.33.22
        leftnexthop=111.222.33.5
        right=%any
        pfs=no
        type=transport
 
conn roadwarrior-l2tp-1
        leftprotoport=17/1701
        rightprotoport=17/0
        auto=add
 
conn roadwarrior-l2tp-2
        leftprotoport=17/1701
        rightprotoport=17/1701
        auto=add
 
conn roadwarrior-l2tp-3
        leftprotoport=17/1701
        rightprotoport=17/%any
        auto=add
 
conn block
        auto=ignore
 
conn private
        auto=ignore
 
conn private-or-clear
        auto=ignore
 
conn clear-or-private
        auto=ignore
 
conn clear
        auto=ignore
 
conn packetdefault
        auto=ignore

Настройки выполнены, теперь на время отладки снимаем firewall с сервера. Клиента помещаем в ту же IP сеть, что и сервер, что бы исключить влияние сторонних маршрутизаторов или firewall'ов.

Настройка VPN клиента.

Для настройки VPN клиента ознакомьтесь с соответствующим описанием

Тестирование.

После установления VPN соединения проверьте, что все работает как надо. Начните проверки с команды route print, пустите ping и tracert на стороннюю машину и проверьте с какого IP адреса приходят на нее пакеты. Либо проверьте, что есть сетевая активность между клиентом и VPN сервером. Для этого можно на сервере дать команду: 

vpnServer ~ # tcpdump -nn -i any port 500 or port 4500

Основные проблемы, которые могут возникнуть на этом этапе:

  1. Запрещена маршрутизация пакетов на VPN сервере. Команда 
     echo 1 > /proc/sys/net/ipv4/ip_forward

    поможет это исправить.

  2. На сервере или клиенте остался firewall
  3. Если можно пропингать серверный IP адрес VPN соединения (172.17.33.2 в нашем примере), а дальше все останавливается, то попробуйте выполнить команды: 
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
    echo 0 > $f
done
for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do
    echo 0 > $f
done
for f in /proc/sys/net/ipv4/conf/*/send_redirects; do
    echo 0 > $f
done

Настройка firewall'ов.

Настройка промежуточного межсетевого экрана проблем не представляет. Достаточно открыть порты udp500 и udp4500 для VPN сервера, а также разрешить протокол ESP. 

allowed_vpnServer_udp="500 4500"
for a in $allowed_vpnServer_udp; do
    iptables -A forward_udp_packets -p UDP -i $INET_IF -s 0/0 -d 111.222.33.2 --dport $a -j ACCEPT
done
 
iptables -A FORWARD -p ESP  -d 111.222.33.2 -j ACCEPT
iptables -A FORWARD -p AH   -d 111.222.33.2 -j ACCEPT
iptables -A FORWARD -p UDP  -j forward_udp_packets

Настройка локального firewall'а, к сожалению, выглядит несколько хитрее. Объясняется это тем, что на момент срабатывания правил цепочки INPUT из таблицы filter, openswan уже успевает декапсулировать IPSec пакеты. Соответственно, для таблицы filter эти пакеты принадлежат UDP протоколу и идут с клиента на сервер на порт udp1701 (этот порт слушает l2tpd). Про протокол ESP уже никто не знает :(. Единственный способ обойти эту проблему состоит в том, что на этапе PREROUTING'а мы маркируем пакеты, принадлежащие протоколу ESP. Трафик от VPN клиентов, идущий по VPN туннелю принимаем полностью. 

iptables -t mangle -A PREROUTING -i eth+ -p esp -j MARK --set-mark 1
iptables -A FORWARD -i eth+ -m mark --mark 1 -j ACCEPT
iptables -A FORWARD -i ppp+ -j ACCEPT
Важно! Никогда, ни при каких условиях не открывайте порт udp1701!!! Это дыра в безопасности неописуемых размеров!!!

Теперь поднимаем firewall'ы и еще раз тестируем наш VPN. Все должно работать.

Настройка PKI VPN-сервера

Ежли вы дошли до этого места и у вас всё работает, я вас поздравляю! Ща будем всё ломать!!! :)

Первое, что необходимо сделать – сохранить рабочие настройки для ipsec: 

cp /etc/ipsec.conf{,-PSK-_work_-saved}
cp /etc/ipsec.secrets{,-PSK-_work_-saved}

Ещё во-первых (© А. Милн), надо создать центр сертификации.

После чего надо создать как минимум 2 сертификата: для VPN-сервера и VPN-клиента. Далее будем считать, что FQDN сервера vpnServer, а клиента vpnClient. Запускаете скрипт создания сертификатов 2 раза, заходите в директорию clients и видите 6 свеженьких файлов, по 3 для сервера и клиента. Учтите, что Common Name и Email Address должны различаться у этих сертификатов. Иначе VPN-сервер будет ругаться, и соединения не будет. Что с ними делать рассказано ниже.

Изменяем файл ipsec.secrets. Всё, что там написано, убиваем и пишем новую запись:

/etc/ipsec.secrets
#: RSA vpnServer.key "some_pwd"
: RSA vpnServer.key

Тут необходим маленький комментарий. Дело в том, что net-misc/openswan позволяет работать с запароленым приватным ключом. Проблема в том, что периодически openswan начинал ругаться в лог, что не может подгрузить приватный ключ. Снятие пароля решило эту проблему «на корню». С точки зрения безопасности, если Вы умеете пользоваться командой chmod, оба варианта, примерно, одинаковы.

Приводим /etc/ipsec.conf к следующему виду:

/etc/ipsec.conf
version 2.0
 
config setup
        interfaces=%defaultroute
        protostack=netkey
        nat_traversal=yes
        virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!172.16.0.0/15
 
conn %default
        keyingtries=1
        compress=yes
        disablearrivalcheck=no
        authby=rsasig
        pfs=no
        type=transport
        #Local side
        leftrsasigkey=%cert
        left=111.222.33.2
        leftnexthop=111.222.33.5
        leftcert=vpnServer.pem
        #Remote side
        rightrsasigkey=%cert
        rightca=%same
        right=%any
 
conn roadwarrior-l2tp-1
        leftprotoport=17/1701
        rightprotoport=17/0
        auto=add
 
conn roadwarrior-l2tp-2
        leftprotoport=17/1701
        rightprotoport=17/1701
        auto=add
 
conn roadwarrior-l2tp-3
        leftprotoport=17/1701
        rightprotoport=17/%any
        auto=add
 
conn block
        auto=ignore
 
conn private
        auto=ignore
 
conn private-or-clear
        auto=ignore
 
conn clear-or-private
        auto=ignore
 
conn clear
        auto=ignore
 
conn packetdefault
        auto=ignore

Раскладываем ключи и сертификаты: 

cp /var/sslca/clients/vpnServer.key /etc/ipsec.d/private
cp /var/sslca/clients/vpnServer.pem /etc/ipsec.d/certs
cp /var/sslca/demoCA/cacert.pem /etc/ipsec.d/cacerts
cp /var/sslca/crl.pem /etc/ipsec.d/crls/crl.pem

Рестартуем IPSec-демон. Файл /var/sslca/clients/vpnServer.p12 можно удалить – он нам не нужен. Всё, осталось только настроить Ваш любимый VPN-клиент.

  • vpn/ipsec-l2tpserver.txt
  • Последнее изменение: 2013-08-24 21:14
  • — Andrew A. Sabitov