Linux vpn with tunneling

Как в Linux с помощью Openswan создать туннель IPsec VPN

Туннель виртуальной частной сети (VPN) используется для надежного обмена данными через интернет между двумя сетями, разделенными физически. Туннелирование необходимо в случае, когда отдельные сети являются частными подсетями локальной сети с глобально не маршрутизируемыми приватными адресами IP, маршрутизация между которыми невозможна с другом с помощью традиционных средств сети интернет. Например, туннели VPN часто устанавливаются для подключения различных филиалов офисных сетей, использующих NAT и принадлежащих к одной и той же организации.

Иногда туннелирование VPN можно также использовать просто в интересах безопасности. Провайдеры услуг или частные компании могут проектировать свои сети таким образом, чтобы жизненно важные серверы (например, база данных, VoIP, банковские серверы) размещались в подсетях, которые доступны для доверенных сотрудников только через туннель VPN. Когда требуется защищенный туннель VPN, часто предпочитают выбирать Ipsec, поскольку с помощью туннеля IPsec можно реализовать дополнительные уровни безопасности.

В данном руководстве будет показано, как в Linux с помощью пакета Openswan можно будет создать туннель VPN.

Топология

В настоящем руководстве будет рассказано о создании туннеля IPsec для следующих вариантов топологий сети.

Установка пакетов и подготовка серверов VPN

Как правило, управление будет происходить только со стороны A, но, согласно требованиям, вам нужно управлять сетью как на стороне A, так и на стороне B. Мы начинаем процесс с установки пакета Openswan.

На системах, основанных на Red Hat (CentOS, Fedora или RHEL):

На системах, основанных на Debian (Debian, Ubuntu или Linux Mint):

Теперь с помощью следующих команд мы отключаем на сервере VPN redirects, если таковой имеется:

Затем мы изменяем параметры ядра так, чтобы постоянно был включен IP forwarding, а IP redirects был постоянно отключен.

Перезагрузите файл /etc/sysctl.conf:

В брандмауэре мы включаем необходимые порты. Пожалуйста, убедитесь в том, что эти правила не конфликтуют с существующими правилами брандмауэра.

Наконец, мы создаем правила брандмауэра для NAT.

Пожалуйста, убедитесь, что правила брандмауэра будут сохранены и будут действовать постоянно.

• Вы можете вместо SNAT использовать MASQUERADE. С точки зрения логики это работать должно, но из-за этого у меня в прошлом возникали проблемы с виртуальными частными серверами (VPS). Так что я бы рекомендовал использовать SNAT, если вы не против.
• Если вы осуществляете управление на стороне B, то также следует создать подобные правила на сервере стороны B.
• Прямая маршрутизации не требует SNAT.

Подготовка конфигурационных файлов

Первым конфигурационным файлом, с которым мы будем работать, является файл ipsec.conf. Независимо от того, как вы сконфигурируете сервер, всегда рассматривайте вашу подсеть как расположенную «слева» (left), а подсеть, к которой доступ осуществляется дистанционно, сайт, как расположенный «справа» (right). Следующая конфигурация выполняется на сервере VPN на стороне A.

Аутентификацию можно делать по-разному. В настоящем руководстве будут использоваться ключ, который добавляется в файл /etc/ipsec.secrets .

Запуск сервиса и поиск возникающих проблем

Теперь сервер должен быть готов для создания туннеля VPN между полдсетями. Если вы также осуществляете управление на стороне B, то, пожалуйста, убедитесь, что вы настроили необходимые параметры на сервере стороны B. Для систем, основанных Red Hat, пожалуйста, убедитесь, что вы с помощью команды chkconfig добавили запуск сервиса в startup.

Если на обоих серверах нет ошибок, то туннель должен сейчас подняться. Вы можете проверить туннель с помощью команды ping с следующим образом.

1. Если туннель не поднят, то частная подсеть на стороне B не должна быть доступна со стороны А, т. е. команда ping не должна работать.
2. После того, как туннель будет поднят , попробуйте команду ping для доступа к частной подсети на стороне B со стороны A. Это должно работать.

Кроме того, в таблице маршрутизации сервера должны появиться маршруты к частной подсети.

Кроме того, мы можем проверить состояние туннеля с помощью следующих команд.

В журнальном файле /var/log/pluto.log также должна быть информация об аутентификации, обмене ключами и информация о различных этапах туннелирования. К этому файлу также нужно обратиться в случае, если туннель не поднимается.

Если вы уверены, что все настройки правильные, а ваш туннель все еще не поднимается, то вы должны проверить следующее.

1. Многие провайдеры отфильтровывают использование портов IPsec. Убедитесь, что вашим провайдером разрешено использовать порты UDP 500, TCP/UDP 4500. Вы можете с помощью telnet попробовать дистанционно подключиться к вашим портам IPsec на сервере.
2. Убедитесь, что в брандмауэре сервера / серверов открыты необходимые порты.
3. Убедитесь, что на обоих серверах правильные ключи.
4. На обоих серверах должны быть правильно настроены параметры left и right.
5. Если вы столкнулись с проблемами NAT, то вместо MASQUERADING попробуйте воспользоваться SNAT.

Если кратко, то в данном руководстве описана процедура создания VPN-туннеля IPSec с помощью пакета Openswan. Туннели VPN очень полезны для повышения безопасности, поскольку они позволяют администраторам открывать доступ к критическим ресурсам только через туннели. Также туннели VPN обеспечивают при передаче защиту данных от перехвата.

Надеюсь, что это руководство вам будет полезно.

Источник

SSH VPN over Internet (SSH tun туннелирование)

Появилась необходимость организации туннеля между своим рабочим компьютером и домашним сервером, с последующим транспортом всего рабочего трафика через домашний сервер в интернет.

Для решения этой задачи, лучше всего подходит технология Vitual Private Network (VPN). Но с помощью чего реализовать эту технологию?
— Я выбрал SSH.
Дело в том, что OpenSSH начиная с версии 4.3, поддерживает tun туннелирование. Этим я и воспользовался…

Схематически это будет выглядеть следующим образом:

Для начала необходимо установить OpenSSH на сервере. У меня Ubuntu Server, и я это делаю так:

sudo aptitude install openssh-server

Хотя, скорее всего, он уже установлен. У меня — точно установлен 😉

Взглянем на более подробную схему, и обсудим её.

Как видно из рисунка, рабочий компьютер имеет IP 172.16.0.1 с маской 255.255.255.0 и шлюзом по умолчанию 172.16.0.254, а в качестве DNS указан IP 8.8.8.8

Компьютер Work:
IP address: 172.16.0.1
Netmask: 255.255.255.0
Default Gateway: 172.16.0.254
DNS: 8.8.8.8

Таблица маршрутизации клиента (Work):

169.254.0.0 — это zeroconf маршрут.

Нюансы:
Дело в том, что для того что-бы организовать туннель, на сервер необходимо авторизироваться под учётной записью root, что не есть хорошо! Поэтому есть два варианта решения проблемы:
1. Ставим на root сложный пароль вида md5 хэша.
2. Настраиваем авторизацию по ключам.
Какой из методов выбрать — решать Вам. Для описываемого мной примера, это не имеет никакого значения.
Если вы хотите использовать парольную авторизацию, разрешите в конфиге PermitRootLogin yes для того, что-бы можно было авторизироваться под root.

Обязательно делать через sudo или root-а. Будут создаваться tun устройства, что требует привилегий.

Ключ -w создаст tun0 устройства на сервере и клиенте, объединив их между собой.
Вот описание из man-а.
-w local_tun[:remote_tun]
Requests tunnel device forwarding with the specified tun(4) devices between the client (local_tun) and the server(remote_tun)

Настройка tun устройств.
На сервере ifconfig tun0 10.0.0.1/30 pointopoint 10.0.0.2
На клиенте ifconfig tun0 10.0.0.2/30 pointopoint 10.0.0.1

Можно протестировать при помощи ping (с компьютера клиента):

Сейчас необходимо весь трафик пустить через tun0, для этого требуется просто указать tun0 шлюзом по умолчанию, но при этом потеряется связь с сервером (Home Server) и DNS сервером. Поэтому прежде чем удалить текущий шлюз по умолчанию (172.16.0.254) обязательно нужно добавить маршруты к серверу и DNS серверу в таблицу маршрутизации. Что можно сделать следующим образом:

route add -host 74.125.87.104 gw 172.16.0.254
route add -host 8.8.8.8 gw 172.16.0.254

После чего удаляем текущий шлюз по умолчанию (172.16.0.254) и указываем в качестве шлюза IP адрес, который мы назначили на интерфейсе tun0 сервера (10.0.0.1)

route del default
route add default gw 10.0.0.1

Выполнив вышеуказанные действия таблица маршрутизации клиента (Work) принимает следующий вид:

Теперь весь трафик, который направляется в неизвестные подсети, а неизвестные все, кроме адресов 8.8.8.8 и 74.125.87.104, направляется через 10.0.0.1, то есть через ШИФРОВАННЫЙ SSH туннель. Но сервер ничего с ним, трафиком, не делает. Потому что необходимо настроить NAT для клиента. Для этого добавляем правило в iptables

iptables -t nat -A POSTROUTING -s 10.0.0.2 -j MASQUERADE

Включаем в ядре ip forward-инг

sysctl -w net.ipv4.ip_forward=1

Не забываем сделать так, что бы он включался при загрузке системы…

mcedit /etc/sysctl.conf

P.S> mcedit — текстовый редактор. Можно использовать любой другой.

Находим закомментированную строку net.ipv4.ip_forward=1 и раскомментируем её.

Всё, mission complete, теперь весь трафик направляется через ssh туннель и NATится в Internet. Туннель шифрованный, трафик до сервера защищён!

Источник

Простой Ethernet-туннель на Linux в четыре-шесть команд

Четыре команды на туннель и две на firewall (не нужны если трафик между своими серверми уже разрешен)
Это всё что нужно, дальше длинное объяснение с подробностями.

Когда требуется объединить несколько компьютеров в псевдолокальную сеть через интернет часто это решается настройкой OpenVPN.

Решение хорошо работает, но не лишено недостатков:
1. Нужно ставить дополнительный софт и его настраивать. Причем с первого раза настраивается он не очень просто — надо посидеть и поразбираться.
2. Шифрование трафика происходит в пользовательском режиме и вносит дополнительные задержки, это не всегда важно но для IP-телефонии может быть заметно.
3. Шифрование не всегда нужно. Например в моем случае все соединения и так защищенные (ssh), мне нужна просто удобная плоская адресация между несколькими компьютерами так как будто они объединены в локальную сеть.

В Linux GRE-туннели настраиваются до неприличия просто (если не нужно шифрование), из требований Linux и по публичному IP на каждый.
В интернете на эту тему информации как-то исчезающе мало — в основном объясняются IP (а не ethernet) туннели и сразу вкупе с шифрованием трафика (которое нужно не всегда). man ip тоже очень обширный и информацию по

Пусть у нас есть два хоста:
HOST1 с внешним адресом 1.2.3.4
HOST2 с внешним адресом 2.3.4.5

Хочется сделать между ними ethernet-сеть, ну и для примера поверх нее можно настроить IP-адреса 192.168.0.1 192.168.0.2, но можно и любые другие или IPv6 или что угодно еще — получится обычная сеть как через коммутатор.

Все команды выполняются от ROOT, после перезагрузки — теряются. Чтобы не терялись нужно прописать команды в скрипты автозагрузки или в конфиги (у каждого дистрибутива свои).

1. Добавить виртуальную сетевую карту-шлюз на HOST1:

На HOST1 он будет выглядеть как обычная сетевая карта — можно назначать IP-адреса, запускать DHCP-сервер, включать в Bridge и т.п.

2. Включить добавленную карту

2. Если запущен IP-tables — разрешаем GRE-трафик

3. Симметричная настройка на втором хосте:

В этот момент ethernet-сеть уже работает. Для проверки этого можно настроить приватные IP-адреса на каждой стороне туннеля и пустить пинги.

Для пингов возможно тоже придется добавить правила в iptables (или вообще выключить его на время экспериментов).

Туннель спокойно настраивается между разными версиями linux, пока писал этот пост один конец был на ubuntu, второй на centos, разницы в настройке нет абсолютно никакой.

Повторяю — это туннель не дает никакой защиты от прослушивания/внедрения трафика.

Источник

VPN везде и всюду: IPsec без L2TP со strongSwan

достаточно сильный лебедь

Если вы когда-либо искали VPN, который будет работать на десктопах, мобильных устройствах и роутерах без установки дополнительного ПО и перепрошивки роутера, вы, вероятно, выбирали между PPTP и L2TP+IPsec. У протокола PPTP имеются проблемы с безопасностью и прохождением через брандмауеры и NAT, так что в 2015 году его уже использовать не стоит, а использование L2TP излишне, т.к. L2 VPN, по моему мнению, для обычного удаленного доступа не нужен практически никогда.

Удивительно, что в интернете не так-то просто можно найти информацию о настройке чего-то помимо L2TP+IPsec в транспортном режиме, учитывая, что это обширный стек протоколов, который можно конфигурировать буквально как душе угодно, поэтому я попытаюсь устранить такое несовершенство мира.

Небольшое введение в мир IPsec

Вообще говоря, не совсем правильно называть IPsec VPN. IPsec не предназначен для построения «виртуальных частных сетей», а создан для шифрования или защиты от подмены передаваемых по IP данных. Это специальный слой поверх IP, который, в зависимости от режима и настроек, работает по-разному. В отличие от привычного VPN, который создает новый интерфейс в системе, на который вы, как это чаще всего бывает, назначаете IP-подсеть из диапазона частных адресов (т.е. создаете новый сетевой сегмент), и через который маршрутизируется трафик в зашифрованном виде, IPsec просто шифрует трафик магическим образом между «внешними» интерфейсами сервера и клиента.

В современном IPsec используются:

• Authentication Header (AH) — протокол, обеспечивающий аутентификацию отправителя и целостность данных. Подписывает не только данные пакета, но и все заголовки, кроме изменяемых полей (ToS, TTL, чексумма).
• Encapsulating Security Payload (ESP) — протокол, обеспечивающий аутентификацию, целостность и конфиденциальность
• Security Association (SA) — параметр с настройками шифрования канала
• Internet Key Exchange (IKE и IKEv2) — протокол обмена параметрами, настройками и согласования SA

AH и ESP — транспортные протоколы, инкапсулируемые прямо в IP, имеющие собственные значение для поля Protocol в IP-заголовке. В современном мире, где NAT стоит за NAT у NAT с NAT’ом, следует использовать что-то более привычное, поэтому сейчас повсеместно используется инкапсуляция ESP-пакетов в UDP. AH не поддерживает работу через NAT.

Сам IPsec поддерживает работу в двух режимах:

• Транспортный режим. Подписывает заголовки и данные (если AH) или подписывает и шифрует данные (если ESP) пакета. Не скрывает IP-адрес получателя пакета, если он маршрутизируется. Этот режим используется для связки L2TP+IPsec.
• Туннельный режим. Подписывает (если AH) и еще шифрует (если ESP) весь пакет.

Протокол IKE позволяет проводить аутентификацию клиента с использованием X.509-сертификатов, Pre-Shared Key и Extensible Authentication Protocol (EAP). Поддерживается двухэтапная аутентификация.

Все современные десктопные ОС (Windows Vista/7/8/8.1, OS X, Linux), мобильные устройства (Android, iOS, Windows Phone, Blackberry) и некоторые роутеры поддерживают VPN с использованием IPsec ESP в туннельном режиме и его настройкой через протокол Internet Key Exchange (IKE) версии 1 или 2, а значит IPsec мы именно так и будем настраивать.

Кстати, писать правильно IPsec, но Cisco IPSec.

IPsec в Linux

В OpenVZ есть поддержка IPsec, и она вполне себе годна для запуска L2TP+IPsec, но там что-то явно не так с маршрутизацией на не-локальные интерфейсы. Вероятно, это можно починить добавлением пары правил на хостовую машину, но это довольно проблематично, если у вас нет доступа к ней, как бывает во подавляющем большинстве случаев. Поэтому для OpenVZ необходимо использовать userspace IPsec, который можно собрать параметром —enable-kernel-libipsec

Жизнь со swanctl:

Жизнь без swanctl:

Нам могут потребоваться некоторые модули, которых может не быть в стандартной поставке:

• xauth-noauth — поддельный аутентификатор, позволяет вводить любой логин и пароль. Нужен для iPhone и iPad при аутентификации только по ключам, т.к. там нет возможности отключить аутентификацию по логину и паролю.
• vici — интерфейс для swanctl.
• libipsec — для userspace IPsec (для OpenVZ и, возможно, других контейнеров).

Если вас не смущает необходимость вводить логин и пароль на iPhone, вам не нужен swanctl и вы не собираетесь запускать это все в OpenVZ-контейнере, то и пересобирать ничего не нужно.
К большому сожалению, мейнтейнеры strongSwan в Debian не запаковали ничего из этого (на февраль 2015), поэтому я сделал патчик, который вы можете использовать.

Переходим к настройке

Будем настраивать подключение через IKEv2 (Windows, Linux, Blackberry), IKEv1+XAUTH (iOS, OS X, Android) и IKEv2+EAP-TLS (Windows Phone). Используем ключи, никаких PSK!
Разработчики strongSwan предлагают нам использовать команду «ipsec pki» для генерации ключей, но она настолько же неудобная, насколько и обычный openssl, поэтому я адаптировал Easy-RSA v3 из OpenVPN для генерации как OpenVPN, так и IPsec-совместимых ключей. С ним вы можете использовать одну связку ключей для двух протоколов!
github.com/ValdikSS/easy-rsa-ipsec
Easy-RSA чрезвычайно простой, поддерживать PKI-инфраструктуру с ним одно удовольствие!

Итак, инициализируем PKI и создаем CA, серверный и клиентский ключи. Важно, чтобы название серверного ключа совпадало с FQDN (доменом, проще говоря) вашего сервера!

Ключи сгенерированы. Я добавлял параметр nopass на каждом шагу, чтобы ключи не были защищены паролем (его можно установить позже в любое время).

Теперь нам необходимо скопировать их в нужные директории внутри /etc/ipsec.d/ , чтобы strongSwan нашел их:

Переходим к настройке strongSwan!
Первым делом, указываем наш приватный ключ в /etc/ipsec.secrets
Редактируем конфигурационный файл /etc/ipsec.conf

Как видите, конфигурационный файл состоит из нескольких секций. В секции config setup два закомментированных параметра: strictcrlpolicy = yes будет требовать неистекший лист отзывов для проведения аутентификации клиента, а uniqueids = no позволяет подключаться нескольким клиентам с одним сертификатом одновременно.
Далее идут секции с описаниями подключений. Секция с названием %default описывает подключение по умолчанию, от которого будут наследоваться другие подключения. Здесь устанавливаются следующие параметры:

• dpdaction=clear включает механизм Dead Peer Detection (DPD) и указывает, что нужно забывать о клиенте, если он не отзывался дольше таймаута
• dpddelay=35s — задержка до включения DPD
• dpdtimeout=300s — таймаут для DPD
• fragmentation=yes — включение внутренней фрагментации пакетов. Позволяет использовать IPsec с провайдерами, у которых сломана IP-фрагментация пакетов (привет, мобильный МТС!)
• rekey=no — выключение инициации смены ключей со стороны сервера. Windows это не любит.
• ike — перечень ciphersuites для использования с IKE (т.е. во время установки шифрованного соединения для передачи конфигурационных параметров, в том числе и ключей для установки SA)
• esp — перечень ciphersuites для шифрования трафика
• left и right — случаем все интерфейсы и принимаем всех клиентов
• leftid — указываем наш FQDN. Нужно для сломанного IKEv2 в OS X El Capitan
• leftauth/rightauth=pubkey — используем аутентификацию по ключам
• leftsubnet — подсети, которые мы отправляем клиенту для маршрутизации (весь IPv4 и IPv6-интернет). Уберите IPv6, если не используете его.
• rightsourceip — пул IP-адресов, из которого выдаем адрес клиенту. Уберите IPv6, если не используете его.
• rightdns — IP-адреса DNS-серверов

Давайте разберемся с ciphersuites в ike и esp. Здесь перечислены методы шифрования в порядке убывания приоритета, и их так много из-за того, что некоторые из них могут быть недоступны на каких-то устройствах, например, мобильных. Первым делом идут так называемые AEAD-алгоритмы, т.е. такие шифры, которые не требуют отдельного алгоритма для аутентификации, с убывающей группой Диффи-Хеллмана для реализации Perfect Forward Secrecy (PFS). Это самые быстрые шифры, которые доступны в IPsec. Хоть это и AEAD-режим, в ike должны быть алгоритмы хеширования для процесса хендшейка. Затем идет привычный AES-CBC с группами Диффи-Хеллмана. Клиентам, которые не поддерживают PFS, мы не позволим подключиться.

Если у вас нет модуля xauth-noauth для соединения ikev1-fakexauth , то вы можете заменить его просто на xauth и создать пользователя в /etc/ipsec.secrets , например, с логином и паролем client1:

Теперь у нас есть три подключения: ikev2-pubkey для IKEv2, ikev1-fakexauth для IKEv1 с фейковой проверкой логина и пароля и ikev2-eap-tls — IKEv2+EAP-TLS для Windows Phone. Перезапускаем strongSwan.

Если все верно, вы увидите следующий вывод команды swanctl -L

Проблемы MTU

Из-за особенностей и ошибок в реализации разных IPsec-клиентов, MTU внутри туннеля нельзя угадать заранее, а на Android вообще устанавливается MTU 1500, из-за чего большие пакеты не передаются и вообще ничего не работает. Чтобы нивелировать этот недостаток, достаточно изменять параметр TCP MSS в момент установки TCP-соединения на стороне сервера. Будем использовать значение 1360 для IPv4 и 1340 для IPv6, чтобы размер пакета не превышал 1400 байт внутри туннеля:

На этом настройка сервера закончена. Не забудьте настроить NAT, если вам он нужен!

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

Алгоритм настройки клиентов в общих чертах заключается в импорте сертификатов из файла *.p12, создании нового подключения с типом IPsec PKI, IPsec XAUTH RSA или IKEv2 (в зависимости от устройства), указания клиентского сертификата и адреса сервера.
Внимание! Нужно вводить именно тот адрес сервера, который вы вводили при создании серверного ключа. Подключиться по другому домену или просто по IP-адресу, если сертификат был сгенерирован на домен, не получится!

Windows

OS X и iOS

Android

Вы можете использовать как IPsec-клиент Android и подключаться по протоколу IKE, так и клиент strongSwan и использовать IKEv2. Клиент strongSwan работает стабильнее и надежно переподключает в случае потери соединения.

Импортируйте сертификат либо через файловый менеджер, либо используя пункт «Установка с SD-карты» в разделе «Безопасность». Перейдите в настройки VPN, создайте новое подключение с типом «IPSec Xauth RSA», в поле «Адрес сервера» впишите, собственно, адрес сервера, в поле «Сертификат пользователя IPSec» и «Сертификат ЦС IPSec» укажите сертификат «client1». Нажмите на соединение, введите любые логин и пароль и попробуйте подключиться.

Источник