Настройка vpn debian 11
Обновлено: 07.07.2024
После обновления домашней машины с Debian 10 (Buster) на Debian 11 (Bullseye) методом In-Place Upgrade, можно обнаружить, что клиентское ПО SSTP VPN, установленное и работающее ранее в Debian 10 больше не работает в Debian 11. В общем-то в этом нет ничего удивительного, так как в ходе выполнения обновления старые пакеты SSTP клиента могут быть удалены из системы, как несовместимые с основной пакетной базой новой версии ОС. В этой заметке мы рассмотрим один из вариантов того, как можно вернуть утраченный функционал SSTP клиента в Debian Bullseye.
Ссылку на исходные коды проекта SSTP клиента для Linux можно найти, например, на сайте проекта - sstp-client.sourceforge.net. Однако их самостоятельная сборка под определённый дистрибутив Linux классическим методом "configure/make/make install" занятие не очень интересное и "модное". В окружении Debian гораздо интересней собрать готовые deb-пакеты, которые можно будет в дальнейшем неоднократно использовать на других системах, оперируя пакетным менеджером APT.
Для систем Ubuntu (и производных от Ubuntu) можно использовать готовые пакеты, предоставляемые автором проекта Eivind Naess в его Personal Packages Archive (PPA). В случае с Debian, ранее мне удалось использовать эти же пакеты и они без особых проблем устанавливаюсь и работали в Debian 10. Однако после обновления до Debian 11 последние актуальные версии пакетов в этом PPA в моём случае не заработали. И основной причиной этого стало то, что в Debian 11 по умолчанию используется более новая версия пакета "ppp" (2.4.9), чем та, что требуется для актуальных пакетов из PPA (2.4.7).
Вообще, если "пошуршать" в поисковом индексе Google, то можно найти частные репозитории, где уже есть готовые собранные deb-пакеты, например, здесь. Но использование пакетов из таких частных репозиториев всегда несёт дополнительные риски. К тому же, как говорится, мы не ищем лёгких путей, и поэтому попробуем самостоятельно собрать нужные нам deb-пакеты в собственном системном окружении.
Перед сборкой deb-пакетов, нам потребуется "дебианизировать" исходные коды. Учитывая то, что задача эта хоть и вполне подъёмная, но и не совсем тривиальная, мы можем воспользоваться готовыми файлами дебианизации, которые уже были подготовлены ранее для сборки пакетов под Ubuntu.
Сборку пакетов, исходя из лучших практик, правильней выполнять на специально отведённой для это чистой системе Debian (без работающих продуктивных сервисов). В нашем же случае всё будет выполняться в рамках домашней машины, экспериментировать в рамкой которой в обще-то не особо и страшно.
Подготовка сборочной среды
Устанавливаем на время сборки пакеты, необходимые для обеспечения общей сборочной среды:
Так как в нашем случае, на системе используется графическая среда Gnome 3.38, поставляемая в составе c Debian 11, то помимо сборки пакетов самого SSTP клиента, нам может понадобиться сборка пакетов расширения графического интерфейса Network Manager.
Устанавливаем пакеты, необходимые для возможности сборки SSTP клиента:
Устанавливаем пакеты, необходимые для возможности сборки пакетов расширения Network Manager:
Собираем пакеты SSTP клиента
Создаём временный каталог, переходим в него и скачиваем в этот каталог актуальные исходные файлы sstp-client с файлами дебианизации:
В текущем каталоге запускаем команду распаковки исходных текстов ( .orig.tar.gz ) и внедрения файлов дебианизации ( .debian.tar.xz ) с помощью файла *.dsc
Перед сборкой можем добавить запись в debian/changelog о новом релизе пакета, немного подняв версию пакета. Для этого переходим в подготовленный подкаталог с уже дебианизированными исходниками ( ./sstp-client-1.0.15 ) и выполняем команду добавления информации в changelog:
В открывшемся текстовом редакторе пишем какой-нибудь комментарий о версии и, при желании, указываем информацию о сборщике пакета (желтым подчёркнуты изменения в changelog, которые были внесены в нашем случае):
Сохраняем изменения в файле и закрываем его.
Теперь можем приступить к сборке deb-пакетов. Выполняем в текущем каталоге команду сборки:
Проверяем результат сборки, перейдя на подкаталог уровнем выше, где должны появится готовые deb-пакеты.
Из собранных deb-пакетов нам потребуется установить лишь 3 пакета:
Первые 2 пакета нужны для работы SSTP клиента, как такового. Третий пакет потребуется нам лишь время, для последующей сборки пакетов для Network Manager.
Собираем пакеты интеграции в Network Manager
Создаём временный каталог, переходим в него и скачиваем исходные файлы network-manager-sstp с файлами дебианизации:
В текущем каталоге запускаем команду распаковки исходных текстов ( .orig.tar.bz2 ) и внедрения файлов дебианизации ( .debian.tar.xz ) с помощью файла *.dsc :
Перед сборкой можем добавить запись в debian/changelog о новом релизе пакета. Для этого переходим в подготовленный подкаталог с уже дебианизированными исходниками ( ./network-manager-sstp-1.2.6 ) и выполняем команду добавления информации в changelog:
В открывшемся текстовом редакторе пишем комментарий о версии и указываем информацию о сборщике пакета:
Сохраняем изменения в файле и закрываем его.
Выполняем сборку пакетов в текущем каталоге:
Проверяем результат сборки, перейдя на подкаталог уровнем выше, где должны появится готовые deb-пакеты:
Устанавливаем 2 пакета, которые потребуются для возможности управления настройками SSTP клиента из графического интерфейса Network Manager:
Проверка результата
В результате предыдущих действий мы имеем в системе 5 установленных пакетов:
Уже сейчас функциональность SSTP клиента должна стать нам доступной и работать. Можем настроить VPN-подключение по протоколу SSTP в графической среде Gnome.
Очистка после сборки
После сборки и установки, пакет libsstp-api-0-dev нам больше уже не нужен, так как он требовался исключительно для сборки других пакетов. Его можем удалить:
Также можем удалить все пакеты, которые мы ранее устанавливали для обеспечения сборочной среды (второй командой удаляем все неиспользуемые более пакеты-зависимости):
При желании сохраняем в отдельное место все собранные deb-пакеты, а затем удаляем временные каталоги сборки со всем содержимым:
Любители "мануальной терапии", закрывающие глаза на ранее упомянутые риски использования частных источников, и желающие забрать уже готовые (и проверенные в работе) файлы deb-пакетов под Debian 11.0 64-bits могут заглянуть сюда.
Возникла необходимость настроить vpn сервер для доступа к локальной сети организации. В качестве vpn сервера я предпочитаю использовать openvp за ее гибкость, удобство и простоту настройки. Но в данном случае мне был нужен именно pptp сервер с возможностью автоматической передачи маршрутов клиентам. С последним пришлось немного повозиться.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на . Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.Введение
Сама по себе настройка pptp сервера на Debian очень проста не представляет никакой сложности. Все настраивается за 10 минут. Проблема здесь в другом. По-умолчанию, windows при подключении по pptp использует удаленный vpn сервер в качестве шлюза по умолчанию. За это отвечает галка в настройках vpn соединения "Использовать основной шлюз в удаленной сети". При такой конфигурации весь трафик компьютера пользователя идет через vpn сервер. Это очень неудобно, да и не нужно. Эту настройку обычно отключают.
Когда ее отключаешь, pptp клиент ничего не знает о маршрутах в удаленный офис. Чтобы туда попасть, маршруты нужно прописывать вручную, например так:
| 192.168.0.0 | Сеть удаленного офиса. |
| 192.168.10.1 | Адрес vpn сервера |
Этот маршрут нужно либо в командной строке прописывать, либо bat файл сделать и запускать. И то и другое неудобно, так как пользователю нужно выполнять дополнительные действия. В openvpn этот вопрос решается очень просто. Там можно на уровне сервера задать любые настройки пользователя, в том числе и маршруты. Они будут передаваться после подключения openvpn клиента. В pptp так сделать нельзя, он это не умеет. Вместо него передать маршруты может dhcp сервер, его для этого нужно специальным образом настроить. Этим мы и займемся.
Установка pptp сервера
Подразумеваю, что у вас установлен и настроен сервер. Если это не так, то воспользуйтесь моими материалами по установке и настройке debian сервера.
Сначала установим pptp сервер:
Рисуем следующий конфиг /etc/pptpd.conf:
| eth1:1 | Виртуальный интерфейс. Нужен для передачи dhcp параметров клиентам pptp. |
| 192.168.10.1 | IP адрес pptp сервера в vpn сети |
| 192.168.10.30-50 | Диапазон адресов, которые будут назначены pptp пользователям в vpn сети |
Редактируем файл с дополнительными параметрами /etc/ppp/options:
Не буду подробно описывать параметры, в интернете есть описание. Обращаю внимание на proxyarp, без него не будет работать задуманная схема, и на nodefaultroute. Если вам иногда нужно ставить пользователям vpn сервер в качестве шлюза по-умолчанию, закомментируйте этот параметр. Отключить шлюз можно будет вручную на клиенте.
Дальше создаем учетки для подключения в файле /etc/ppp/chap-secrets:
Первый столбец - имя пользователя, второй - тип сервера, он всегда один и тот же, третий - пароль, четвертый - ip адрес в vpn сети, который будет назначен клиенту. Если его явно не указать, то ему будет назначен первый свободный из диапазона remoteip в pptpd.conf.
На этом настройка непосредственно pptp сервера закончена. Им можно пользоваться, но маршруты пользователям передаваться не будут.
Настраиваем dhcp сервер для раздачи маршрутов
У меня на сервере уже был настроен isc-dhcp-server, поэтому я использовал именно его. Но можно воспользоваться и dnsmasq. Я приведу пример с dhcpd. Если у вас его еще нет, то устанавливайте командой:
Рисуем следующий конфиг /etc/dhcp/dhcpd.conf:
Я тут не разбирался, что и зачем настроено именно так. Сервер настраивал не я, он мне достался в наследство. Мне нужно было только грамотно настроить pptpd с раздачей маршрутов. Поэтому я не расписываю все от и до, а просто делюсь рабочим конфигом, который сейчас у меня работает.
Подсеть 192.168.10.0 и 2 строчки с options перед ней это то, что я добавил для раздачи маршрутов pptp клиентам в vpn подсеть.
Теперь создадим виртуальный интерфейс, добавив в самый конец конфигурационного файла сети:
О настройке 2-х ip адресов на одном интерфейсе можно подробно прочитать в статье - настройка сети в debian. В моем случае eth1 это интерфейс, который смотрит в локальную сеть, доступ к которой мы организуем с помощью vpn.
Перезапускаем сеть для применения настроек:
По сути все готово. Запускаем pptpd и dhcpd и проверяем.
У меня почему-то команда pptpd restart отрабатывает с ошибкой и не перезапускает демон. Приходится запускать вручную:
Проверяем работу клиента windows. Список маршрутов до vpn подключения:
Вот пример такой же конфигурации для dnsmasq:
Нашел, пока разбирался с вопросом. У себя не проверял, так как решил все на одном dhcp сервере делать, который уже был.
Заключение
Немного сложно реализуется функционал, который доступен в openvpn из коробки без дополнительных настроек. Я поэтому и не очень люблю с pptp возиться, после openvp он мне кажется не таким удобным. Но иногда приходится и его настраивать. К примеру, микротики, к сожалению, так и не научились работать с openvpn по udp, приходится использовать pptp. Да и встроенный в windows клиент тоже добавляет удобство.
Я немного повозился, поразбирался, прежде чем у меня получилось настроить рабочий вариант. Ключевым моментом оказался виртуальный интерфейс eth1:1, который я создал для pptp подсети. Без него у меня не работала передача маршрута.
Ничего не предвещало беды, как вдруг в 2 часа ночи раздался телефонный звонок.
— Алло, милый! У меня youtube не работает!
— Прекрасно, иди спать!
— Нууу! Там новая серия вышла!
— Завтра всё сделаю!
— Ну Заяя, нуууу!
— Ладно! Ладно! Сейчас.
…
Начало
После этого я подкинул пару хороших и быстрых прокси, чтобы моя милая успокоилась и пошла смотреть свой любимый сериал. Попутно объяснил ей где найти очередные прокси, если эти помрут, а так же провел инструктаж о мерах предосторожности при использовании чужих прокси. Её все устроило, скорость была отменной, она визжала как поросенок, после чего пропала на пару часов в бездне кинематографа. Это был самый простой и быстрый способ ее успокоить и вернуть возможность вновь наслаждаться благами цивилизации.
Прокси, тем более публичные, это не серьезно, проблемно и очень не безопасно, нам нужен VPN подумал я, и поэтому решил — пока меня не отвлекают надо приступить к реализации. Для начала выберем сервер.
vServer VQ 7 — от Hetzner подойдет, цена вопроса всего 7.90 Евро/мес, а т.к. ничего кроме VPN мы запускать пока не планируем, этой простейшей конфигурации вполне хватит.
Как зарегистрироваться и купить сервер, объяснять не буду, скажу только что у меня попросили любой документ удостоверяющий личность, на котором видна дата рождения. Платил картой VISA.
Настройка сервера
И так, мы зарегистрировались и купили vServer VQ 7, заходим в админку и видим наш сервер
Теперь установим на него debian (кстати это можно сделать прямо во время оформления заказа). Переходим на вкладку Linux, выбираем конфигурацию Debian 6.0 minimal, 32bit, жмем Activate.
Установка начнется при следующем запуске сервера, т.е. нам надо его перезагрузить, сделать это можно на вкладке vServer, или по SSH.
Через некоторое время на почту придет письмо что все готово. Там же будет и пароль root пользователя, подключаемся по SSH к серверу и приступаем к настройке.
Всё, серверная часть готова. Можно подключаться. Для перехода к следующим этапам, надо выгрузить с нашего сервера сертификаты из папки: Это можно сделать при помощи SSH, либо mc если у вас есть ftp сервер. Нам нужны только некоторые файлы, какие именно читаем ниже.
Настройка android клиента (root не требуется)
- Basic > Server Address: IP адрес вашего VPN сервера, либо имя домена если вы его привязали
- Type: PKCS12 File
- Select: Выбираем наш файл *.p12
- PKCS12 Password: вводим пароль импорта сертификата, заданный при его генерации.
- upd: используйте последнюю версию приложения, в ней проверка remote-cert-tls server включена по-умолчанию. либо включите вручную в настройках авторизации, проверку сертификата сервера
- Если вы включили tls-auth на сервере, включите в настройках профиля tls-auth и выберите ta.key
Настройка Windows клиента
1. Скачиваем и устанавливаем клиент: 32bit | 64bit
2. Создаем файл конфигурации myvpnconfig.ovpn (обычный текстовый файл):
3. Создаем batch скрипт (start_my_vpn.cmd) для запуска VPN сессии:
4. Скрипт и конфиг ложим в одну папку, в эту же папку кидаем vpn.windows.p12 сертификат, брать его тут
5. Готово, ярлык на скрипт кидаем на рабочий стол, запускаем от имени администратора или от пользователя с его правами, при запуске он попросит ввести пароль для «импорта» сертификата.
Если пароль верный, то несколько секунд и мы подключились:
Для не параноиков или автостарта туннеля без ввода пароля, можно вместо p12 использовать связку сертификатов ca.crt, vpn.windows.key и vpn.windows.crt, выглядит это так,
вместо пишем:
Файлы брать все там же и положить в папку с myvpnconfig.ovpn и start_my_vpn.cmd.
Настройка Linux клиента
Настройка на примере debian 6.0
Готово. Не забудьте положить vpn.debian.p12 или ca.crt, vpn.debian.key и vpn.debian.crt в папку со скриптом и файлом конфигурации.
Для подключения к VPN, просто выполните с повышенными привилегиями:
Настройка роутера на dd-wrt (Big или Mega)
В данном случае будет проведена настройка роутера, как клиента сети VPN, для возможности удаленного подключения к роутеру, если подключение по внешнему адресу недоступно, например провайдер внезапно выдал вам NAT'ированный IP. Подключаться можно будет с любого устройства, внутри вашего VPN.
1. Перейдите на страницу router_ip/Diagnostics.asp (тех.обслуживание->команды)
2. Если у вас уже есть «Параметры запуска», то нажмите Редактировать и добавьте ниже приведенный код, после, либо до вашего. Если нет то просто вставьте его в «Командный процессор» и нажмите «Сохранить параметры запуска»
3. Собственно сам код запуска:
4. Переменные CA_CRT, CLIENT_CRT и CLIENT_KEY, это содержимое файлов ca.crt, vpn.ddwrt.crt и vpn.ddwrt.key соответственно, просто открывайте их текстовым редактором и копируйте содержимое, в vpn.ddwrt.crt блок будет в самом конце, в двух других копируем содержимое полностью. Брать файлы известно где
5. Не забудьте заменить IP_ВАШЕГО_СЕРВЕРА и нажать «Сохранить параметры запуска».
6. Перезагружаем роутер, пробуем подключиться к нему с другого устройства в вашем VPN. Посмотреть VPN IP адрес роутера можно например через ifconfig.
Настоятельно рекомендую запускать VPN туннель сразу после того как вы подключаетесь к открытым точкам доступа Wi-Fi.
Как показала моя последняя командировка, ловить в wi-fi сетях гостиниц и прочих учреждений не заботящихся о безопасности своих клиентов можно очень долго и невозбранно (особенно удивляет обилие сканов паспортов, в почтовых ящиках тур. агентов).
Помимо прочего, вы получаете возможность подключаться между устройствами, даже если они находятся за NAT провайдера, это очень удобно. Если конечно вы раскомментировали строку client-to-client в конфиге сервера.
Иногда возникает необходимость, зайти в локальную сеть, чтобы пользоваться ее внутренними ресурсами, это могут быть файловые, почтовые, сервера баз данных, VoIP и многое другое на что хватает фантазии и знаний. Для этого мы воспользуемся VPN, а конкретно протоколом PPTP. Он представляет, из себя, соединение точка-точка и помогает организовать защищенное соединение поверх не защищенного. В настоящее время поддерживается, большинством современных операционных систем и не требует сложной настройки.
Данное руководство актуально для Dedian/Ubuntu 10.х, а при небольшой адаптации и для других дистрибутивов.
Схема работы:
Но также можно соединять сервера в удаленных филиалах.
Установку операционной системы я опущу.
Ставим необходимые пакеты.
Нам придется отредактировать 3 конфигурационных файла:
Нас интересуют следующие пункты:
Вообще при установке VPN соединения имя шлюза не выдается, а шлюзом по умолчанию становится тот сетевой интерфейс, который принимает соединения от пользователей локальной сети и отправляет их в интеренет, в нашем случае это eth0, его IP мы и указываем, но если необходимо блокировать доступ в Интернет пользователям использующим подключающимся удаленно, то можно указать другой IP и в интеренет они через наш сервер выйти не смогут.
Этот пункт отвечает за то, какие IP адреса будут выданы клиентам подключенным по VPN, в данном случае – IP адреса будут выдаваться из диапазона начиная с192.168.1.240 по 192.168.1.254 из этого становиться ясно что в текущей конфигурации, к серверу могут подключиться 14 клиентов, зачастую больше и не требуется. Естественно эту группу IP адресов необходимо исключить из выдачи нашего DHCP сервера, который работает в нутри локалки, чтобы не возникало конфликтов между повторяющимися адресами внутри сети.
Также в этот файл можно добавить параметр listen и указать в нем IP адрес нашего внешнего сетевого интерфейса, который будет принимать внешние подключения, должно выгладеть
Где: 000.000.00.000 необходимо заменить на свой внешний, реальный IP.
Сохраняем изменения, выходим.
Далее нам необходимо отредактировать
В пункте –Encryption привести к виду указанному ниже.
Этим пунктом мы запрещаем использовать протоколы, которые давно и успешно взломаны и по рекомендации Microsoft, не должны использоваться: pap, chap, mschap, а также жестко указываем что можно использовать только mschap версии 2.
В разделе Network and Routing, можно указать
ms-dns 192.168.1.20
Если в сети работает DNS сервер, например в ОС сервества Windows 2003/2008, который работает совместно с Active Directory, то можно указать его IP и тогда клиенты смогут увидеть все компьютеры и прочие сетевые ресурсы, присутствующие в нашей сети, обращаясь к ним по именам, а не по IP.
ms-wins 192.168.1.20
Из названия данного пункта, можно догадаться, что он отвечает за адрес сервера WINS, если конечно он используется, в нашем случае, служба WINS работает на одном сервере с DNS, его IP мы и указываем. Данная служба существенно снижает нагрузку на сеть. Если она не используется, то данный параметр, можно оставить закомментированным.
На этом все, сохраняем изменения и выходим.
Теперь самое главное, нам необходимо добавить клиентов которые будут подключатся к нашему серверу из вне. Для этого отредактируем:
Можно добавлять в него записи вида
Username * secretpassword -тогда пользователю будет выдан IP из диапазона который мы установили в файле pptpd.conf
Но бывает и так, что за определенным пользователем необходимо закрепить определенный IP например 192.168.1.250, тогда запись приобретает вид
Username * secretpassword 192.168.1.250
Где: Username-имя пользователя, secretpassword-пароль
На этом настройку сервера можно считать завершенной, его необходимо перезагрузить
(Небольшое, но важное дополнение: Если после завершения настроек при попытке перезапустить pptpd-зависает, то необходимо, убедиться что во всех конфигурационных файлах, а особенно в pptpd.conf, после последней строки необходимо нажать Enter, чтобы курсор перешел на новую строку!)
Все работает нормально, теперь нам необходимо настроить клиентов, рассмотрим эту ситуацию на примере windows 7.
Настройка VPN происходит стандартно и в большинстве случае сложности не вызывает, но все-таки рассмотрим ее подробнее.
Настройка самого соединения проходит штатно
Указываем доменное имя нашего VPN сервера, для этого, заранее необходимо создать DNS запись в вашем домене, если доменное имя еще не куплено-не проблема, можно указать IP адрес нашего сервера в интернет. Устанавливаем галочку, чтобы система не начала устанавливать соединение по окончанию настройки.
Указываем имя пользователя и пароль и жмем кнопку создать
Теперь находим наше свежесозданное подключение и настраиваем его-перейдя в его свойства
Переходим во вкладку Безопасность
В тип VPN указываем PPTP переходим в меню-Разрешить следующие протоколы и оставляем галочку на против MSCHAP v2
Переходим во вкладку Сеть:
Необходимость этого пункта зависти от того для чего мы используем этот сервер!
Если планируем соединить удаленные офисы в единую сеть, при этом офисы подключаются к нам через WLAN, и не имеют местного доступа в интернет, будут выходить в глобальную сеть через головой офис или через тот где интернет обходится дешевле, то необходимость того что написано ниже, отпадает, нажимаем OK и пробуем подключиться, мы сразу получим доступ в Интернет, а шлюзом будет выступать сервер головного офиса.
Если сервер VPN будет использоваться для подключения удаленных сотрудников для работы с ресурсами локальной сети, то им нет необходимости выходить в интернет через наш сервер-он и так у них есть на месте и в этой ситуации этот пункт нам понадобится. По умолчанию VPN соединение получает более высокий приоритет, а VPN сервер становится шлюзом по умолчанию, данный параметр регулируется сетевой метрикой, чем число в метрике меньше-тем приоритет этого соединения выше. В этой ситуации, нам необходимо, сказать системе не использовать это соединение для доступа в интернет, а только для работы в локальной сети.
Выбираем протокол TCP/IP v4 и переходим в его свойства
В свойствах выбираем Дополнительно
В дополнительных параметрах нам необходимо снять галочку с пункта: Использовать основной шлюз удаленной сети
Теперь это соединение не будет использоваться как основное, для подключения к интернет, но работоспособность локальной сети сохранится.
На этом можно и закончить. В результате проделанной работы у нас получился первоклассный VPN шлюз, который обеспечивает передачу данных по шифрованному каналу между двумя точками, что позволит защитить их от третьих лиц. На его настройку уйдет примерно 15 мин.
Теперь можно смело подключать сетевые диски файловых серверов и подключаться к сетевым принтерам или непосредственно к серверу печати если такой имеется.
Читайте также: