Vpn туннель для linux

Как в 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 обеспечивают при передаче защиту данных от перехвата.

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

Источник

VPN-канал с помощью OpenSSH. Часть первая

Начиная с версии 4.3 OpenSSH поддерживает устройства tun/tap , позволяющие создавать шифрованный туннель, что может быть полезно для удаленного администрирования. Это очень похоже на OpenVPN, основанный на TLS, но для реализации не нужно ничего дополнительно устанавливать и настраивать.

В терминологии компьютерных сетей, TUN и TAP — виртуальные сетевые драйверы ядра системы. Они представляют собой программные сетевые устройства, которые отличаются от обычных аппаратных сетевых карт.

TAP эмулирует Ethernet устройство и работает на канальном уровне модели OSI, оперируя кадрами Ethernet. TUN (сетевой туннель) работает на сетевом уровне модели OSI, оперируя IP пакетами. TAP используется для создания сетевого моста, тогда как TUN для маршрутизации.

Итак, есть сервер с белым ip-адресом 123.123.123.123 и клиент. На сервере и на клиенте установлена Ubuntu 18.04, на сервере установлен OpenSSH сервер. Нам надо построить туннель между клиентом и сервером, так что они будут в одной сети 192.168.200.0/30 . У сервера в этой сети будет ip-адрес 192.168.200.1 , а у клиента — 192.168.200.2 .

Настройка сервера

Для начала редактируем файл конфигурации ssh-сервера:

Параметр PermitTunnel разрешает использование перенаправления для устройств TUN и может принимать значения yes , point-to-point (3-й уровень модели OSI), ethernet (2-й уровень модели OSI) и no . Значение yes означает, что одновременно разрешается point-to-point и ethernet . Значение по умолчанию — no .

С помощью параметра PermitRootLogin мы разрешаем пользователю root подключаться к серверу. Это не очень хорошо, но необходимо для создания туннеля — чтобы «поднять» tun-интерфейсы, которые мы создадим на клиенте и на сервере, нужны права суперпользователя. Пока оставим так, а потом настроим аутентификацию по ключу и изменим значение этого параметра на without-password .

Теперь создаем виртуальный интерфейс tun5 :

Удалить созданный виртуальный интерфейс можно командой

Смотрим сетевые интерфейсы:

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

Аналогично, создаем виртуальный интерфейс tun5 :

Смотрим сетевые интерфейсы:

Создаем туннель

Обратите внимание, что команда выполняется от имени пользователя root и подключаемся к серверу как пользователь root .

Включаем интерфейсы на клиенте и на сервере:

Смотрим сетевые интерфейсы на сервере:

Пингуем клиента по ip-адресу 192.168.200.2

На клиенте открываем еще один терминал и тоже смотрим сетевые интерфейсы:

Пингуем сервер по ip-адресу 192.168.200.1

Обратите внимание на состояние state интерфейсов tun5 на клиенте и на сервере — оно должно быть UP , т.е. интерфейсы включены.

Аутентификаци по ключу

Включаем на сервере аутентификацию по ключу:

Создаем ключи на клиенте:

Копируем публичный ключ на сервер:

Проверяем, что можем подключаться к серверу как root без пароля:

Запрещаем пользователю root вход по паролю:

Добавляем разные фишки

Поднимаем туннель с помощью команды:

Опции команды для создания туннеля:

• Опция -S указывает расположение управляющего сокета для общего доступа к соединению. По его наличию можно сделать вывод о состоянии нашего туннеля. Если файл отсутствует, значит, по каким-то причинам, наше соединение разорвалось.
• Опция -M применяется вместе с опцией -S , создает «мастер» подключение. Нам это потребуется для разрыва соединения.
• Опция -N означает, что после создания туннеля никакая команда на стороне сервера не будет выполняться.
• Опция -f переводит процесс в фоновый режим.

Мультиплексирование — это возможность посылать более одного сигнала по одной линии или соединению. В OpenSSH мультиплексирование может повторно использовать существующее исходящее TCP-соединение для нескольких одновременных SSH-сеансов с удаленным SSH-сервером, избегая затрат на создание нового TCP-соединения и повторную проверку подлинности каждый раз.

Клиент OpenSSH поддерживает мультиплексирование своих исходящих соединений, начиная с версии 3.9, используя директивы конфигурации ControlMaster , ControlPath и ControlPersist , которые задаются в

/.ssh/config и /etc/ssh/ssh_config . Опции времени выполнения -M и -S соответствуют ControlMaster и ControlPath соответственно.

Вот так создается управляющее TCP-соединение, которое может использоваться другими ssh-сеансами:

Теперь в другом терминале можно выполнять команды на сервере www.example.com без ввода пароля:

Состояние управляющего TCP-соединения можно запросить с помощью опции -O check :

Опция -O exit удаляет управляющий сокет и немедленно завершает все существующие подключения:

Давайте проверим, что процесс работает в фоне:

Теперь — команда на отключение. Вот тут как раз нам пригодится файл-сокет и контроль соединения через него:

Направляем трафик клиента в туннель

Чтобы перенаправить весь трафик клиента в туннель, нужно вместо старого шлюза — 192.168.110.1 (через интерфейс enp0s3 ) указать новый — 192.168.200.1 (через интерфейс tun5 ). Но при этом потеряется связь с сервером — поэтому перед заменой шлюза нужно добавить маршрут до сервера.

После этого весь трафик клиента направляется в туннель, но что делать с этим трафиком — сервер не знает. Нужно включить пересылку трафика между интерфейсами tun5 и ens3 и добавить SNAT, чтобы сервер подменял серый ip-адрес клиента на свой белый ip-адрес.

На клиенте выполняем команды:

На сервере выполняем команды:

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

Источник

Простой 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-туннеля на Windows и Linux

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

В этой статье я покажу, как создать VPN-тунель в Windows и Linux через TCP (L3-туннель), ICMP, DNS и через SSH (L2/L3-туннели).

Настройка VPN-туннелей

Все примеры использования туннелей требуют прав администратора или root.

VPN-туннель через TCP в одну команду (L3-туннель)

В Linux мы можем очень элегантно поднять туннель, не используя настраиваемый VPN-сервер:

Туннель создан. Теперь, чтобы превратить victim в gateway, нужно проделать следующее:

Готово, с этого момента мы можем направлять трафик во внутреннюю сеть как есть, используя только роутинг:

Стоит отметить, что, используя pppd , мы можем создавать туннель по инициативе любой из сторон (victim или attacker). Это значит, что мы получили возможность обойти проблемы с межсетевыми экранами. Для работы требуется поддержка ядра (модуль ppp_generic ).

А вот еще один способ поднять туннель, используя IPIP:

VPN туннель через SSH (L2/L3-туннели)

Если на victim или attacker есть SSH-сервер, то этого достаточно, чтобы создать VPN. Сперва нужно разрешить подключение в /etc/ssh/sshd_config :

После этого можно создать подключение:

Для организации доступа в сеть L3-туннеля будет достаточно. Но если мы хотим не просто просканировать порты, а выполнять атаки, такие как ARP/NBNS/DHCP-spoofing, то потребуется L2-туннель. Для этого прописываем в /etc/ssh/sshd_config следующее:

Перезапускаем SSH-сервер и выполняем подключение:

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

VPN-туннели на Windows

Windows из коробки тоже поддерживает VPN (в варианте PPTP/L2TP). Более того, управлять можно из командной строки благодаря встроенному компоненту:

Конфиг для network.ini выглядит следующим образом:

Отключают VPN-соединения следующей командой:

Не стоит забывать про классический OpenVPN, который прекрасно работает и на Linux, и на Windows. При наличии прав администратора его использование не должно вызвать проблем.

Также достаточно экзотический, но действенный способ L2-туннелирования на Windows через виртуализацию был описан в этой статье.

VPN-туннель через ICMP

Если выход в интернет запрещен, но разрешены пинги, то можно воспользоваться hans и в две команды создать L3-туннель ( 172.16.0.1 на attacker и 172.16.0.10 на victim):

Клиентская сторона для Windows работает аналогичным образом, но для работы потребуется tap-интерфейс, который можно создать с помощью OpenVPN.

VPN-туннель через DNS

В последний раз возвращаемся к DNS. Если в настройках DNS разрешены резолвы произвольных доменов, что бывает достаточно часто, то с помощью iodine мы можем создать полноценный L3-туннель ( 172.16.0.1 на attacker и 172.16.0.2 на victim):

VPN-туннели можно организовать как напрямую между attacker и victim, так и сочетанием разных техник проброса портов. Например, мы можем вместо DNS-туннеля iodine использовать сочетание DNS2TCP + pppd.

Заключение

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

Источник