stihl не предоставил(а) никакой дополнительной информации.
Вступление:
Ни для кого не секрет, что такое системы туннелирования трафика VPN и proxy. Ни для кого не является секретом и то, для чего эти технологии были придуманы, какой путь развития они прошли от момента создания, реализации, развития и трансформации с течением времени и как модифицировались под те или иные нужды в тех или иных условиях. Обо всем этом с легкостью можно почитать на просторах глобальной сети Интернет, как и о том, как это настраивать и применять во множестве вариантов реализаций любой прикладной области и практически в любых системных средах и условиях. Но среди всего этого разнообразия разноплановых схем туннелирования меньше всего внимания уделено специфическим конструкциям указанных решений, применяемых в области обеспечения безопасности и анонимности, таким как backconnect vpn или backconnect proxy, особенно актуальной для применения в случае ограничений сегментов сети такими технологиями как NAT. Вот об одной из таких реализаций мы и поговорим в данной статье и достаточно подробно разберем один из вариантов конфигурации подобной реализации с использованием подручных(штатных) средств операционной системы linux и готовых приложений предназначенных для этой системы.
Теперь относительно коротко и тезисно, насколько это возможно для полноценного понимания статьи, разберем перечень используемых в рассматриваемом решении средств с описанием их функционального назначения с целью хотя-бы общего представления того, для чего, что и как мы будем делать и как именно все это устроено:
Рисунок представленной инфраструктуры схемы backconnect vpn для замаскированного vpn сервиса расположенного за NAT любой сети:
Рис.1
Что можно увидеть на графической схеме инфраструктуры, по отдельным ее узлам:
Node 1: Клиент-сервер который осуществляет собственное внешнее обращение к себе от любого внешнего источника, например ожидает от Node 3 запрос на необходимость создать vpn туннель к Node 3, и затем через посредника - Node 2 инициализирует установление, либо завершение backconnect соединение в свою сторону и принимает их на себя от Node 3.
Node 2: Сервер который ожидает запросы на установление или на завершение backconnet соединения и на основании типа запроса производит подготовку сигнальных файлов для непосредственно устанавливающего такое соединение сервера клиентского типа Node 3, передавая ему данную информацию уже по запросу самого Node 3.
Node 3: VPN сервер клиентского типа за NAT(условная граница внутреннего сегмента NAT, в котором расположен данный узел, обозначена на рисунке зеленой пунктирной линией), который инициирует собственное VPN соединение на Node 1 по его запросу, периодически проверяя наличие такого запроса на его создание через сервер Node 2, и при существования признаков его существования, сам же его и создающий, либо гипотетически запускающий такую инициализацию через Node 1 со своей стороны(синяя стрелка-пунктир).
Опишем функциональное назначение применяемых в схеме технологий и инструментов, отдельно по каждому используемому инструменту:
UDEV - это система управления устройствами в Linux, которая отвечает за динамическое управление устройствами в реальном времени. Она заменяет устаревшие технологии hotplug/devfs, предоставляя при этом более гибкий и мощный способ автоматизированного управления устройствами и их жизненным циклом в системе. В основные функции udev входит динамическое управление аппаратными средствами вычислительной системы посредством заранее созданных правил, позволяющих автоматически создавать устройства в каталоге /dev в случае их подключения к шине устройств, или отключения от нее, а так же гибко реагировать на практически любые изменения в аппаратной конфигурации данных средств.
D-BUS - это система межпроцессного взаимодействия (IPC), используемая в операционных системах на базе Linux. Она позволяет различным приложениям и сервисам обмениваться сообщениями и данными, обеспечивая взаимодействие между процессами, работающими на одном или нескольких компьютерах. Основными компонентами D-BUS являются системная и сессионная шины, которые работают на разных уровнях привилегий, но в конечном счете имеющих одно и то же назначение-обмен сообщениями между процессами и службами и реагирование на указанные события. Данная служба позволяет подобно UDEV автоматизировать многие важные функции в операционной системе, в том числе на низком уровне.
CRON - судя по всему это самая известная из представленных система(приложение) linux планирования запускаемых событий по времени. В детальном представлении не нуждается, но информации о ней довольно много и найти ее нетрудно в документации, руководствах и в Интернет.
INCRON (в нашем случае установлена работает только на третьем хосте Node3, который является пассивным сервером) - это прикладное приложение, функционирующее на основе подсистемы inotify ядра операционной системы linux, и которая, в свою очередь, позволяет получать уведомления об изменениях в файловой подсистеме в реальном режиме времени, реагируя ни них определенным образом. Простыми словами, эта подсистемы информирует о различных изменениях состояния файловой системы linux, таких как создание, модификация и удаление любого файла, используемого файловой системой. К файлам же относятся и директории. Так как в рамках системы linux и в частности в контексте ее файловой системы действует неизменная до сих пор концепция: "все есть файл", к ним относятся в том числе и все виды специальных файлов - директории, каналы/конвееры и другие файловые структуры. Сама же утилита INCRON это оболочка-обертка подсистемы ядра inotify, которая выполняет установленную команду в случае наступлении ожидаемого в заданной конфигурации события, аналогично тому, как делает это система CRON, но которая, в отличие от incron реагирует согласно расписанию во временных интервалах. Для более подробной информации о работе и настройке данного инструмента следует изучить официальную документацию.
KNOCKD (установлена на 2 хоста - Node1 и Node2, но в качестве сервера работает только на втором узле) - это приложение транспортного уровня, которая предоставляет механизм реагирования на заранее заданные и сформированные по определенной конфигурации правилам и параметрам комбинации сетевых пакетов, отправляемых клиентом этого приложения на сетевой интерфейс сервера, который данные последовательности принимает, интерпретирует их, и реагирует, выполняя определенные действия, установленные в заданных правилах. В общем по-сути, это приблизительно то же самое, что делает система inotify/incron, только в отличие от файловой системы, здесь в качестве триггеров используется сетевой трафик транспортного уровня. Подробности, опять таки, можно легко отыскать в официальной документации и в руководствах к данной утилите.
Далее, когда у нас с вами имеется более полное представление, рассмотрим более углубленно детальное, но в то же время обобщенное и целостное описание инфраструктурной схемы, обозначенной на рисунке выше:
Давайте с вами опишем общим, но в то же время максимально, насколько это возможно развернутым планом схему реализации предлагаемого решения. В данной статье рассматривается конфигурационная сетевая инфраструктура прикладного назначения состоящая их трех хостов на основе и под управлением операционной системы linux. Первый хост (Node1) представляет собой клиентскую машину которая осуществляет инициативный запуск процесса создания backconnect vpn связки между сервером и клиентом, где в качестве инициатора выступает не клиент, а сервер (Node3) уже устанавливает непосредственно само соединение. Если же описывать процесс происходящий в данной сетевой связке более подробно, то для выполнения указанных действий, существует дополнительная нода (Node2) задача которой состоит в том, чтобы быть посредником в процессе запуска туннеля между клиентом и сервером, эта нода осуществляет мониторинг с целью реагирования на определенные события в сетевом трафике поступающем на Node2, принимая тем самым заявки от клиента Node1 на установку соединения клиента с сервером Node3. Для этого Node2 производит определенные технические мероприятия внутри собственного хоста и затем передает инициативу клиента серверу Node3 по запросу самого сервера, опять таки, выступая при этом не активным, а пассивным элементом схемы. Формированием и отправкой запроса первого хоста на второй хост с извещением о намерении установить vpn соединение занимается клиентская утилита knock из прикладного пакета knockd, предназначенного для осуществления процесса сетевого "простукивания"(кнокинга) сетевых портов. Второй хост осуществляет собственное реагирование при помощи утилиты knockd по запросу от первого хоста и инициирует либо изменение, либо создание, при его отсутствии, специального либо стартового, либо стопового файла, в зависимости от целевого запроса клиента в собственной файловой системе по заранее определенному для этого пути, а так же открывает отдельный сетевой порт для каждого из типов файла предназначенного для различных функций - стопового, либо стартового, закрывая при этом порт предназначенный для другой функции. Третий хост Node3 периодически с итерацией периода повторения раз в минуту и с использованием стандартной службы CRON осуществляет постоянные попытки достучаться до управляющей ноды Node2 отдельно на каждый из портов и в случае успеха, скачивает указанный файл по сети в собственную файловую систему по определенному отдельно каждого типа файла пути. Затем система производит сравнивание скачанного файла с ранее скачанными файлами того же типа, и в случае обнаружения разницы между ними, запускает, либо завершает непосредственный процесс установки соединения инициативным образом путем организации ssh туннеля, либо его закрытия. Автоматизацией большинства основных операций по использованию утилит в раках операционной системы будет заниматься оболочка bash и ее одноименный скриптовый язык.
Итак, настало время приступать непосредственно к настройке узлов схемы, приводя с подробные пояснения к элементам конфигурации и с детализацией по каждому узлу инфраструктуры:
Предполагается что вы уже обладаете базовыми знаниями и понимаете как устанавливать то или иное программное обеспечение в операционной системе Linux и с ее использованием и умеете это делать. Если нет, то это такие навыки вы можете получить самостоятельно такую, так как статья не предполагает обучение данным основам.
Настройка узла node1 (10.10.10.1):
1. ШАГ ПЕРВЫЙ.
Используем UDEV:
1.1 Для реагирования системы на подключение определенного usb-устройства с целью запуска bash-скрипта, перезагружающего сетевую подсистему хоста и открывающего необходимый сетевой порт для подготовки системы к установлению впоследствии входящего vpn-соединения:
Вносим в файл /etc/udev/rules.d/99-usb.rules следующую строку:
То есть, в случае подключения конкретного устройства на шину usb, udev перезагрузит сеть и, тем самым, сбросив все существующие сетевые соединения, отправит сигнал системной шине dbus на отстук с целью запуска vpn подключения, что и является нашей основной целью.
1.2 Для реагирования системы на отключение определенного, заранее подключенного usb-устройства с целью запуска того же самого bash-скрипта, но закрывающего ранее открытый для установления vpn-соединения сетевой порт и сбрасывающего установленное и активное входящее vpn-соединение но без перезагрузки всей сетевой подсистемы, так как в данном случае такой необходимости нет, кроме того, при перезагрузке сети система вновь отправит отстук на установление нового vpn-туннеля:
При подключении usb устройства /etc/udev/rules.d/99-usb.rules:
Здесь же, в случае отключения конкретного устройства на шину usb, udev самостоятельно совершит отстук на управляющую ноду с целью начала процесса закрытия vpn подключения, код которого описан в скрипте /home/myuser/network_restart.sh в разделе stop_vpn.
2. ШАГ ВТОРОЙ.
Используем DBUS:
Создадим файл службы systemd, которая будет отслеживать события D-Bus и запускать bash скрипт который, в свою очередь, через запрос на промежуточный сервер Node02 инициализирует процесс создания backconnect vpn соединения с использованием службы ssh.
Содержимое файла /etc/systemd/system/net_monitor.service:
В случае перезагрузки сетевой подсистемы linux, системная шина DBUS отреагирует запуском процесса инициализации установления обратного vpn соединения, причем инициатором его непосредственного установления будет сервер, а не клиент, как принято в классических случаях. Ведь мы с вами организуем некое подобие схемы backconnect. При этом сам процесс инициализации, а фактически первые его шаг выполняется клиентом методом кнокинга(отстуком) на промежуточный управляющий узел, который, в свою очередь, выполняет определенные действия по уведомлению сервера vpn о начале установления соединения с клиентом. Код запуска описан в скрипте network_restart.sh в разделе query_backconnect.
3. ШАГ ТРЕТИЙ.
Используем knockd:
Пишем скрипт network_restart.sh, выполняющий свою часть работы для каждой из трех возможных ситуаций - для каждого шага инициирования установки vpn соединения: перезагрузки сети со стороны udev и соответственно отстука на управляющий сервер шиной DBUS, а так же для команды с целью его закрытия. Приводим содержимое самого скрипта:
Развернутое описание скрипта /home/myuser/network_restart.sh:
Скрипт разбит на три секции. Секции START_VPN и STOP_VPN вызываются службой DBUS. Первая секция инициирует запрос на процесс установления соединения vpn путем перезагрузки сетевой службы хоста в случае подключения к хосту конкретного usb устройства, например флеш-карты, чем в свою очередь, запускает триггер для службы UDEV, которая снова обращается к скрипту на секцию QUERY_BACKCONNECT с целью отстука запроса на второй узел. Секция STOP_VPN инициирует закрытие vpn соединения путем отстука на узел node2 другой последовательности в случае отсоединения ранее подключенного usb устройства от порта.
4. ШАГ ЧЕТВЕРТЫЙ.
После создания скрипта и правила реагирования(их может быть сколько угодно) делаем его исполняемым, а затем перезагрузим службу udev:
Выдаем необходимые скрипту права, а так же запускаем правила UDEV в работу:
# chmod +x /home/myuser/network_restart.sh
# udevadm control --reload-rules && udevadm trigger
Настройка узла node2 (10.10.10.2):
1. ШАГ ПЕРВЫЙ:
Редактируем файл:
# vi /etc/default/knockd
И приводим указанный ниже параметр к такому виду внутри конфигурационного файла /etc/default/knockd:
Этот параметр автоматического запуска данной службы по умолчанию.
Далее, правим(или дополняем) основной файл конфигурации сервера knockd:
Блок конфигурации файла /etc/knockd.conf:
Детальное описание настроек knockd.conf:
В секции TUNTAP_start_on_QUERY_BACKCONNECT_from_node1 сервера knockd описаны параметры варианта сетевой последовательности, в случае поступления которой на интерфейс сервера будет автоматически выполнена команда заданная параметром command, исполняющая bash скрипт vpnquery.sh с параметром start_vpn и код которой описан в секции START_VPN данного скрипта и предназначенная для выполнения очередного этапа установления backconnect vpn в контексте вспомогательной ноды Node2. В секции TUNTAP_stop_on_STOP_VPN_from_node1 обозначена другая последовательность, как легко понять из названия, предназначенная для исполнения контекста остановки соединения и код которой описан в секции STOP_VPN скрипта network_restart.sh.
2. ШАГ ВТОРОЙ:
Содержимое bash скрипта /home/myuser/vpnquery.sh:
Развернутое описание скрипта /home/myuser/vpnquery.sh:
Указанный скрипт предназначен для создания или заполнения файлов инициализации пуска либо останова. в зависимости от поступившей от службы knockd команды. Так же скрипт открывает, либо же закрывает сетевые порты используя которые третья нода инфраструктуры инициирует попытки посредством наличия данных файлов получить сигнальную информацию о необходимости непосредственного создания процессов установления или же завершения backconnect vpn соединения с первым узлом (node 1) исходя из конкретной ситуации.
Выдаем привилегии на исполнение скрипту vpnquery.sh:
# chmod +x /home/myuser/vpnquery.sh
Настройка узла node3 (10.10.10.3):
1. ШАГ ПЕРВЫЙ:
Настраиваем на хосте службу временного расписания CRON:
Редактируем основной конфигурационный файл:
# crontab -e
Приводим содержимое файла конфигурации crontab к следующему виду(добавляем строки для функционирования нашей инфраструктуры):
Тем самым мы ставим в расписание службы CRON два задания. Первое задание каждую минуту запускает блок check_start_vpn скрипта /home/myuser/my_script.sh, а второе отрабатывает блок check_stop_vpn. Таким образом хост запрашивает у промежуточного сервера текущее состояние файлов-триггеров, сигнализирующих о необходимости Node 3 поднять vpn подключение с Node1. Для чего текущий хост при наличии возможности в виде открытых портов на Node2, а так же наличия самих файлов, скачивает указанные их на собственную файловую систему и сравнивает их с теми, которые были загружены до этого момента в прошлые попытки загрузки в случае если таковые имели место быть.
2. ШАГ ВТОРОЙ
Разрешаем пользователю root использовать сервис incron:
# echo root >>/etc/incron.allow
Редактируем конфигурацию службы incron:
# incrontab -e:
Файл конфигурации incron:
Подробное пояснение по конфигурации функционала incron в представленном решении:
Сервис incron ведет наблюдение за множеством объектов файловой системы управляющего узла Node2 на предмет модификации ее состояния на наблюдаемых участках которые являются триггерами для запуска очередного звена в цепочке событий по созданию обратного vpn подключения между первым и третьим узлом, то есть между клиентом и сервером. В данном случае сервис отслеживает две директории и два файла, расположенных в этих директориях. Как можно увидеть из названия директорий и файлов, одна директория и один файл в ней относятся к процессу запуска vpn, а если быть точнее, то в случае создания нового файла в директории start, либо при модификации уже существующего start_file, срабатывает триггер и производится запуск скрипта /home/myuser/my_script.sh с параметром start_vpn, который и устанавливает непосредственное vpn соединение с клиентом Node1 путем создания ssh туннеля с поднятием полноценных виртуальных интерфейсов на оконечных нодах. Другая пара директория-файл соответственно выполняют обратную функцию и разрывают уже организованный vpn туннель. Сам код обоих вариантов подробно описан в скрипте с необходимыми пояснениями.
Ну и разумеется в качестве дополнения приведу таблицу с основными триггерами файловой системы, которые возможно использовать в конфигурации incron(на самом деле, более поздние версии приложения умеют применять гораздо больше событийных триггеров):
IN_MODIFY реагирование на изменение файла
IN_DELETE триггер удаления файла
IN_MOVE_SELF на перемещение файла или директории
IN_MOVED_FROM на перемещение файла из наблюдаемой директории
IN_CREATE на создание файла в наблюдаемой директории
IN_ACCESS на получение доступа к файлу (чтение)
IN_ATTRIB триггер изменения служебных данных/метаданных файлового объекта
IN_MOVED_TO на перемещение файлового объекта в наблюдаемый контекст(директорию)
IN_DELETE_SELF на удаление наблюдаемого файла или директории
IN_OPEN на открытие файла
IN_CLOSE_WRITE на закрытие файла, ранее открытого для записи
IN_CLOSE_NOWRITE на закрытие файла без записи
При этом, в рамках правил incron имеется возможность использовать специальные переменные для передачи основных параметров правил incron например во входящих потоках данных сторонних служб, программ или в скриптов в качестве параметров потоков данных или внешних переменных.
Для большей наглядности разберем следующий простой пример:
/home/myuser/start IN_CREATE /home/myuser/my_script.sh start_vpn
Если в каталоге /home/myuser/start был создан файл (директива IN_CREATE), то система автоматически выполняет скрипт my_script.sh, передавая ему в качестве двух аргументов две переменные: слово create, а также специальную комбинацию: $@/$#. Эта комбинация состоит из двух внутренних переменных: $@ - что означает наблюдаемый путь, содержащий абсолютный путь до отслеживаемой директории, а также специальной переменной $#, обозначающей сам объект наблюдения. Коротко, если будет создан некоторый объект(файл), его имя будет содержаться в указанной переменной, которой можно оперировать в конфигурации.
3. ШАГ ТРЕТИЙ
Содержимое файла /home/muuser/my_script.sh:
Пояснения по скрипту: В секции START_VPN последовательно на каждой из нод Node1 и Node3 выполняется по четыре команды - создание виртуального сетевого интерфейса, назначение этому интерфейсу ip адреса будущей виртуальной vpn-сети, активизация интерфейса и создание записи в таблице маршрутизации с целью включения этого интерфейса в область сетевой доступности. Ну и наконец, при помощи команды ssh -w 0:0 myuser@10.10.10.1 устанавливаем само vpn соединение с Node1 (10.10.10.1)
Выдаем права на исполнение скрипта:
# chmod +x /home/myuser/my_script.sh
Заключение:
Вот наверное нам удалось описать все то, что изначально хотелось и одновременно предполагалось к рассмотрению в текущей статье касаемо технологии backconnect. Это было сделано на примере одного из достаточно простых в части реализации вариантов организации такой технологии с использованием исключительно штатных и проверенных средств операционной системы linux, выбранной в данном случае в качестве наилучшего для статьи и как наиболее наглядного и доступного примера, а так же как открытого в части лицензирования и готовых к использованию прикладных приложений решения. И хочу особо подчеркнуть, что в данной статье вариант именно схемы, но специально не затронуты вопросы безопасности внутри нее и в контексте взаимодействия с ней из внешних контуров. То есть, не обозначены такие вопросы как шифрование, сетевая фильтрация различного уровня, безопасность прикладных приложений. В список целей статьи данные вопросы целенаправленно не были помещены из-за достаточной громоздкости тематики. Возможно к этим вопросам придется вернуться отдельно в других, будущих статьях или работах. И возвращаясь к теме, то становится совершенно очевидно, что целей, способов и методов применения подобной технологии, ее конфигураций в целостном виде, либо частями, а так же их различных вариаций можно придумать великое множество. Кроме того, никто не мешает все это улучшать, развивать и дополнять собственными наработками или разработками в зависимости от стоящих перед вами интересных и разнообразных задач, наличие которых в вашей работе, учебе или в просто повседневном досуге и хочу искренне пожелать всем читателям. Многое в ваших руках, только дерзайте!
Спасибо за внимание -)
Ни для кого не секрет, что такое системы туннелирования трафика VPN и proxy. Ни для кого не является секретом и то, для чего эти технологии были придуманы, какой путь развития они прошли от момента создания, реализации, развития и трансформации с течением времени и как модифицировались под те или иные нужды в тех или иных условиях. Обо всем этом с легкостью можно почитать на просторах глобальной сети Интернет, как и о том, как это настраивать и применять во множестве вариантов реализаций любой прикладной области и практически в любых системных средах и условиях. Но среди всего этого разнообразия разноплановых схем туннелирования меньше всего внимания уделено специфическим конструкциям указанных решений, применяемых в области обеспечения безопасности и анонимности, таким как backconnect vpn или backconnect proxy, особенно актуальной для применения в случае ограничений сегментов сети такими технологиями как NAT. Вот об одной из таких реализаций мы и поговорим в данной статье и достаточно подробно разберем один из вариантов конфигурации подобной реализации с использованием подручных(штатных) средств операционной системы linux и готовых приложений предназначенных для этой системы.
Теперь относительно коротко и тезисно, насколько это возможно для полноценного понимания статьи, разберем перечень используемых в рассматриваемом решении средств с описанием их функционального назначения с целью хотя-бы общего представления того, для чего, что и как мы будем делать и как именно все это устроено:
Рисунок представленной инфраструктуры схемы backconnect vpn для замаскированного vpn сервиса расположенного за NAT любой сети:
Рис.1
Что можно увидеть на графической схеме инфраструктуры, по отдельным ее узлам:
Node 1: Клиент-сервер который осуществляет собственное внешнее обращение к себе от любого внешнего источника, например ожидает от Node 3 запрос на необходимость создать vpn туннель к Node 3, и затем через посредника - Node 2 инициализирует установление, либо завершение backconnect соединение в свою сторону и принимает их на себя от Node 3.
Node 2: Сервер который ожидает запросы на установление или на завершение backconnet соединения и на основании типа запроса производит подготовку сигнальных файлов для непосредственно устанавливающего такое соединение сервера клиентского типа Node 3, передавая ему данную информацию уже по запросу самого Node 3.
Node 3: VPN сервер клиентского типа за NAT(условная граница внутреннего сегмента NAT, в котором расположен данный узел, обозначена на рисунке зеленой пунктирной линией), который инициирует собственное VPN соединение на Node 1 по его запросу, периодически проверяя наличие такого запроса на его создание через сервер Node 2, и при существования признаков его существования, сам же его и создающий, либо гипотетически запускающий такую инициализацию через Node 1 со своей стороны(синяя стрелка-пунктир).
Опишем функциональное назначение применяемых в схеме технологий и инструментов, отдельно по каждому используемому инструменту:
UDEV - это система управления устройствами в Linux, которая отвечает за динамическое управление устройствами в реальном времени. Она заменяет устаревшие технологии hotplug/devfs, предоставляя при этом более гибкий и мощный способ автоматизированного управления устройствами и их жизненным циклом в системе. В основные функции udev входит динамическое управление аппаратными средствами вычислительной системы посредством заранее созданных правил, позволяющих автоматически создавать устройства в каталоге /dev в случае их подключения к шине устройств, или отключения от нее, а так же гибко реагировать на практически любые изменения в аппаратной конфигурации данных средств.
D-BUS - это система межпроцессного взаимодействия (IPC), используемая в операционных системах на базе Linux. Она позволяет различным приложениям и сервисам обмениваться сообщениями и данными, обеспечивая взаимодействие между процессами, работающими на одном или нескольких компьютерах. Основными компонентами D-BUS являются системная и сессионная шины, которые работают на разных уровнях привилегий, но в конечном счете имеющих одно и то же назначение-обмен сообщениями между процессами и службами и реагирование на указанные события. Данная служба позволяет подобно UDEV автоматизировать многие важные функции в операционной системе, в том числе на низком уровне.
CRON - судя по всему это самая известная из представленных система(приложение) linux планирования запускаемых событий по времени. В детальном представлении не нуждается, но информации о ней довольно много и найти ее нетрудно в документации, руководствах и в Интернет.
INCRON (в нашем случае установлена работает только на третьем хосте Node3, который является пассивным сервером) - это прикладное приложение, функционирующее на основе подсистемы inotify ядра операционной системы linux, и которая, в свою очередь, позволяет получать уведомления об изменениях в файловой подсистеме в реальном режиме времени, реагируя ни них определенным образом. Простыми словами, эта подсистемы информирует о различных изменениях состояния файловой системы linux, таких как создание, модификация и удаление любого файла, используемого файловой системой. К файлам же относятся и директории. Так как в рамках системы linux и в частности в контексте ее файловой системы действует неизменная до сих пор концепция: "все есть файл", к ним относятся в том числе и все виды специальных файлов - директории, каналы/конвееры и другие файловые структуры. Сама же утилита INCRON это оболочка-обертка подсистемы ядра inotify, которая выполняет установленную команду в случае наступлении ожидаемого в заданной конфигурации события, аналогично тому, как делает это система CRON, но которая, в отличие от incron реагирует согласно расписанию во временных интервалах. Для более подробной информации о работе и настройке данного инструмента следует изучить официальную документацию.
KNOCKD (установлена на 2 хоста - Node1 и Node2, но в качестве сервера работает только на втором узле) - это приложение транспортного уровня, которая предоставляет механизм реагирования на заранее заданные и сформированные по определенной конфигурации правилам и параметрам комбинации сетевых пакетов, отправляемых клиентом этого приложения на сетевой интерфейс сервера, который данные последовательности принимает, интерпретирует их, и реагирует, выполняя определенные действия, установленные в заданных правилах. В общем по-сути, это приблизительно то же самое, что делает система inotify/incron, только в отличие от файловой системы, здесь в качестве триггеров используется сетевой трафик транспортного уровня. Подробности, опять таки, можно легко отыскать в официальной документации и в руководствах к данной утилите.
Далее, когда у нас с вами имеется более полное представление, рассмотрим более углубленно детальное, но в то же время обобщенное и целостное описание инфраструктурной схемы, обозначенной на рисунке выше:
Давайте с вами опишем общим, но в то же время максимально, насколько это возможно развернутым планом схему реализации предлагаемого решения. В данной статье рассматривается конфигурационная сетевая инфраструктура прикладного назначения состоящая их трех хостов на основе и под управлением операционной системы linux. Первый хост (Node1) представляет собой клиентскую машину которая осуществляет инициативный запуск процесса создания backconnect vpn связки между сервером и клиентом, где в качестве инициатора выступает не клиент, а сервер (Node3) уже устанавливает непосредственно само соединение. Если же описывать процесс происходящий в данной сетевой связке более подробно, то для выполнения указанных действий, существует дополнительная нода (Node2) задача которой состоит в том, чтобы быть посредником в процессе запуска туннеля между клиентом и сервером, эта нода осуществляет мониторинг с целью реагирования на определенные события в сетевом трафике поступающем на Node2, принимая тем самым заявки от клиента Node1 на установку соединения клиента с сервером Node3. Для этого Node2 производит определенные технические мероприятия внутри собственного хоста и затем передает инициативу клиента серверу Node3 по запросу самого сервера, опять таки, выступая при этом не активным, а пассивным элементом схемы. Формированием и отправкой запроса первого хоста на второй хост с извещением о намерении установить vpn соединение занимается клиентская утилита knock из прикладного пакета knockd, предназначенного для осуществления процесса сетевого "простукивания"(кнокинга) сетевых портов. Второй хост осуществляет собственное реагирование при помощи утилиты knockd по запросу от первого хоста и инициирует либо изменение, либо создание, при его отсутствии, специального либо стартового, либо стопового файла, в зависимости от целевого запроса клиента в собственной файловой системе по заранее определенному для этого пути, а так же открывает отдельный сетевой порт для каждого из типов файла предназначенного для различных функций - стопового, либо стартового, закрывая при этом порт предназначенный для другой функции. Третий хост Node3 периодически с итерацией периода повторения раз в минуту и с использованием стандартной службы CRON осуществляет постоянные попытки достучаться до управляющей ноды Node2 отдельно на каждый из портов и в случае успеха, скачивает указанный файл по сети в собственную файловую систему по определенному отдельно каждого типа файла пути. Затем система производит сравнивание скачанного файла с ранее скачанными файлами того же типа, и в случае обнаружения разницы между ними, запускает, либо завершает непосредственный процесс установки соединения инициативным образом путем организации ssh туннеля, либо его закрытия. Автоматизацией большинства основных операций по использованию утилит в раках операционной системы будет заниматься оболочка bash и ее одноименный скриптовый язык.
Итак, настало время приступать непосредственно к настройке узлов схемы, приводя с подробные пояснения к элементам конфигурации и с детализацией по каждому узлу инфраструктуры:
Предполагается что вы уже обладаете базовыми знаниями и понимаете как устанавливать то или иное программное обеспечение в операционной системе Linux и с ее использованием и умеете это делать. Если нет, то это такие навыки вы можете получить самостоятельно такую, так как статья не предполагает обучение данным основам.
Настройка узла node1 (10.10.10.1):
1. ШАГ ПЕРВЫЙ.
Используем UDEV:
1.1 Для реагирования системы на подключение определенного usb-устройства с целью запуска bash-скрипта, перезагружающего сетевую подсистему хоста и открывающего необходимый сетевой порт для подготовки системы к установлению впоследствии входящего vpn-соединения:
Вносим в файл /etc/udev/rules.d/99-usb.rules следующую строку:
Код:
SUBSYSTEM=="usb", ATTR{idVendor}=="0382", ATTR{idProduct}=="b02f", ACTION=="add", RUN+="/home/myuser/network_restart.sh start_vpn"То есть, в случае подключения конкретного устройства на шину usb, udev перезагрузит сеть и, тем самым, сбросив все существующие сетевые соединения, отправит сигнал системной шине dbus на отстук с целью запуска vpn подключения, что и является нашей основной целью.
1.2 Для реагирования системы на отключение определенного, заранее подключенного usb-устройства с целью запуска того же самого bash-скрипта, но закрывающего ранее открытый для установления vpn-соединения сетевой порт и сбрасывающего установленное и активное входящее vpn-соединение но без перезагрузки всей сетевой подсистемы, так как в данном случае такой необходимости нет, кроме того, при перезагрузке сети система вновь отправит отстук на установление нового vpn-туннеля:
При подключении usb устройства /etc/udev/rules.d/99-usb.rules:
Код:
SUBSYSTEM=="usb", ATTR{idVendor}=="0383", ATTR{idProduct}=="b02f", ACTION=="remove", RUN+="/home/myuser/network_restart.sh stop_vpnЗдесь же, в случае отключения конкретного устройства на шину usb, udev самостоятельно совершит отстук на управляющую ноду с целью начала процесса закрытия vpn подключения, код которого описан в скрипте /home/myuser/network_restart.sh в разделе stop_vpn.
2. ШАГ ВТОРОЙ.
Используем DBUS:
Создадим файл службы systemd, которая будет отслеживать события D-Bus и запускать bash скрипт который, в свою очередь, через запрос на промежуточный сервер Node02 инициализирует процесс создания backconnect vpn соединения с использованием службы ssh.
Содержимое файла /etc/systemd/system/net_monitor.service:
Код:
[Unit]
Description=USB Device Monitor
[Service]
Type=simple
ExecStart=/usr/bin/dbus-monitor --system "sender=org.freedesktop.NetworkManager, path=/org/freedesktop/NetworkManager, member=StateChanged" | sed -u -n 's/ uint32 70/network is restart/p' | while read line; do "sh /home/myuser/network_restart.sh query_backconnect"; done
[Install]
WantedBy=multi-user.targetВ случае перезагрузки сетевой подсистемы linux, системная шина DBUS отреагирует запуском процесса инициализации установления обратного vpn соединения, причем инициатором его непосредственного установления будет сервер, а не клиент, как принято в классических случаях. Ведь мы с вами организуем некое подобие схемы backconnect. При этом сам процесс инициализации, а фактически первые его шаг выполняется клиентом методом кнокинга(отстуком) на промежуточный управляющий узел, который, в свою очередь, выполняет определенные действия по уведомлению сервера vpn о начале установления соединения с клиентом. Код запуска описан в скрипте network_restart.sh в разделе query_backconnect.
3. ШАГ ТРЕТИЙ.
Используем knockd:
Пишем скрипт network_restart.sh, выполняющий свою часть работы для каждой из трех возможных ситуаций - для каждого шага инициирования установки vpn соединения: перезагрузки сети со стороны udev и соответственно отстука на управляющий сервер шиной DBUS, а так же для команды с целью его закрытия. Приводим содержимое самого скрипта:
Код:
#!/bin/bash
if [[ $# -eq 2 ]]; then
#START_VPN
if [[ $1 = start_vpn ]]; then
systemctl restart systemd-networkd
#QUERY_BACKCONNECT
elseif [[ $1 = query_backconnect ]]; then
knock -d 7 10.10.10.2 7520:tcp 1827:tcp 9303:tcp 45621:tcp
#STOP_VPN
elseif [[ $1 = stop_vpn ]]; then
knock -d 7 10.10.10.2 2341:tcp 7815:tcp 3207:tcp 51422:tcp
else fi
else fiРазвернутое описание скрипта /home/myuser/network_restart.sh:
Скрипт разбит на три секции. Секции START_VPN и STOP_VPN вызываются службой DBUS. Первая секция инициирует запрос на процесс установления соединения vpn путем перезагрузки сетевой службы хоста в случае подключения к хосту конкретного usb устройства, например флеш-карты, чем в свою очередь, запускает триггер для службы UDEV, которая снова обращается к скрипту на секцию QUERY_BACKCONNECT с целью отстука запроса на второй узел. Секция STOP_VPN инициирует закрытие vpn соединения путем отстука на узел node2 другой последовательности в случае отсоединения ранее подключенного usb устройства от порта.
4. ШАГ ЧЕТВЕРТЫЙ.
После создания скрипта и правила реагирования(их может быть сколько угодно) делаем его исполняемым, а затем перезагрузим службу udev:
Выдаем необходимые скрипту права, а так же запускаем правила UDEV в работу:
# chmod +x /home/myuser/network_restart.sh
# udevadm control --reload-rules && udevadm trigger
Настройка узла node2 (10.10.10.2):
1. ШАГ ПЕРВЫЙ:
Редактируем файл:
# vi /etc/default/knockd
И приводим указанный ниже параметр к такому виду внутри конфигурационного файла /etc/default/knockd:
Код:
START_KNOCKD=1Этот параметр автоматического запуска данной службы по умолчанию.
Далее, правим(или дополняем) основной файл конфигурации сервера knockd:
Блок конфигурации файла /etc/knockd.conf:
Код:
[TUNTAP_start_on_QUERY_BACKCONNECT_from_node1]
sequence = 7520:tcp 1827:tcp 9303:tcp 45621:tcp
seq_timeout = 7
tcpflags = syn
command = /home/myuser/vpnquery.sh start_vpn
[TUNTAP_stop_on_STOP_VPN_from_node1]
sequence = 2341:tcp 7815:tcp 3207:tcp 51422:tcp
seq_timeout = 7
tcpflags = syn
command = /home/myuser/vpnquery.sh stop_vpnДетальное описание настроек knockd.conf:
В секции TUNTAP_start_on_QUERY_BACKCONNECT_from_node1 сервера knockd описаны параметры варианта сетевой последовательности, в случае поступления которой на интерфейс сервера будет автоматически выполнена команда заданная параметром command, исполняющая bash скрипт vpnquery.sh с параметром start_vpn и код которой описан в секции START_VPN данного скрипта и предназначенная для выполнения очередного этапа установления backconnect vpn в контексте вспомогательной ноды Node2. В секции TUNTAP_stop_on_STOP_VPN_from_node1 обозначена другая последовательность, как легко понять из названия, предназначенная для исполнения контекста остановки соединения и код которой описан в секции STOP_VPN скрипта network_restart.sh.
2. ШАГ ВТОРОЙ:
Содержимое bash скрипта /home/myuser/vpnquery.sh:
Код:
#!/bin/bash
if [[ $# -eq 2 ]]; then
#START_VPN
if [[ $1 = start_vpn ]]; then
iptables -A INPUT -p tcp -s 10.10.10.2 --dport 22222 -j ACCEPT
iptables -A INPUT -p tcp -s 10.10.10.2 --dport 33333 -j DROP
if [ -f /home/myuser/init_file ]; then
echo "xxxxxx" >> /home/myuser/start_file
else
dd if=/dev/urandom of=/home/myuser/start_file
#STOP_VPN
elseif [[ $1 = stop_vpn ]]; then
iptables -A INPUT -p tcp -s 10.10.10.2 --dport 33333 -j ACCEPT
iptables -A INPUT -p tcp -s 10.10.10.2 --dport 22222 -j DROP
if [ -f /home/myuser/stop_file ]; then
echo "xxxxxx" >> /home/myuser/stop_file
else
dd if=/dev/urandom of=/home/myuser/stop_file
else fi
else fiРазвернутое описание скрипта /home/myuser/vpnquery.sh:
Указанный скрипт предназначен для создания или заполнения файлов инициализации пуска либо останова. в зависимости от поступившей от службы knockd команды. Так же скрипт открывает, либо же закрывает сетевые порты используя которые третья нода инфраструктуры инициирует попытки посредством наличия данных файлов получить сигнальную информацию о необходимости непосредственного создания процессов установления или же завершения backconnect vpn соединения с первым узлом (node 1) исходя из конкретной ситуации.
Выдаем привилегии на исполнение скрипту vpnquery.sh:
# chmod +x /home/myuser/vpnquery.sh
Настройка узла node3 (10.10.10.3):
1. ШАГ ПЕРВЫЙ:
Настраиваем на хосте службу временного расписания CRON:
Редактируем основной конфигурационный файл:
# crontab -e
Приводим содержимое файла конфигурации crontab к следующему виду(добавляем строки для функционирования нашей инфраструктуры):
Код:
* * * * * /home/myuser/my_script.sh check_start_vpn
* * * * * /home/myuser/my_script.sh check_stop_vpnТем самым мы ставим в расписание службы CRON два задания. Первое задание каждую минуту запускает блок check_start_vpn скрипта /home/myuser/my_script.sh, а второе отрабатывает блок check_stop_vpn. Таким образом хост запрашивает у промежуточного сервера текущее состояние файлов-триггеров, сигнализирующих о необходимости Node 3 поднять vpn подключение с Node1. Для чего текущий хост при наличии возможности в виде открытых портов на Node2, а так же наличия самих файлов, скачивает указанные их на собственную файловую систему и сравнивает их с теми, которые были загружены до этого момента в прошлые попытки загрузки в случае если таковые имели место быть.
2. ШАГ ВТОРОЙ
Разрешаем пользователю root использовать сервис incron:
# echo root >>/etc/incron.allow
Редактируем конфигурацию службы incron:
# incrontab -e:
Файл конфигурации incron:
Код:
/home/myuser/start/start_file IN_MODIFY /home/myuser/my_script.sh start_vpn
/home/myuser/start/ IN_CREATE /home/myuser/my_script.sh start_vpn
/home/myuser/stop/stop_file IN_MODIFY /home/myuser/my_script.sh stop_vpn
/home/myuser/stop/ IN_CREATE /home/myuser/my_script.sh stop_vpnПодробное пояснение по конфигурации функционала incron в представленном решении:
Сервис incron ведет наблюдение за множеством объектов файловой системы управляющего узла Node2 на предмет модификации ее состояния на наблюдаемых участках которые являются триггерами для запуска очередного звена в цепочке событий по созданию обратного vpn подключения между первым и третьим узлом, то есть между клиентом и сервером. В данном случае сервис отслеживает две директории и два файла, расположенных в этих директориях. Как можно увидеть из названия директорий и файлов, одна директория и один файл в ней относятся к процессу запуска vpn, а если быть точнее, то в случае создания нового файла в директории start, либо при модификации уже существующего start_file, срабатывает триггер и производится запуск скрипта /home/myuser/my_script.sh с параметром start_vpn, который и устанавливает непосредственное vpn соединение с клиентом Node1 путем создания ssh туннеля с поднятием полноценных виртуальных интерфейсов на оконечных нодах. Другая пара директория-файл соответственно выполняют обратную функцию и разрывают уже организованный vpn туннель. Сам код обоих вариантов подробно описан в скрипте с необходимыми пояснениями.
Ну и разумеется в качестве дополнения приведу таблицу с основными триггерами файловой системы, которые возможно использовать в конфигурации incron(на самом деле, более поздние версии приложения умеют применять гораздо больше событийных триггеров):
IN_MODIFY реагирование на изменение файла
IN_DELETE триггер удаления файла
IN_MOVE_SELF на перемещение файла или директории
IN_MOVED_FROM на перемещение файла из наблюдаемой директории
IN_CREATE на создание файла в наблюдаемой директории
IN_ACCESS на получение доступа к файлу (чтение)
IN_ATTRIB триггер изменения служебных данных/метаданных файлового объекта
IN_MOVED_TO на перемещение файлового объекта в наблюдаемый контекст(директорию)
IN_DELETE_SELF на удаление наблюдаемого файла или директории
IN_OPEN на открытие файла
IN_CLOSE_WRITE на закрытие файла, ранее открытого для записи
IN_CLOSE_NOWRITE на закрытие файла без записи
При этом, в рамках правил incron имеется возможность использовать специальные переменные для передачи основных параметров правил incron например во входящих потоках данных сторонних служб, программ или в скриптов в качестве параметров потоков данных или внешних переменных.
Для большей наглядности разберем следующий простой пример:
/home/myuser/start IN_CREATE /home/myuser/my_script.sh start_vpn
Если в каталоге /home/myuser/start был создан файл (директива IN_CREATE), то система автоматически выполняет скрипт my_script.sh, передавая ему в качестве двух аргументов две переменные: слово create, а также специальную комбинацию: $@/$#. Эта комбинация состоит из двух внутренних переменных: $@ - что означает наблюдаемый путь, содержащий абсолютный путь до отслеживаемой директории, а также специальной переменной $#, обозначающей сам объект наблюдения. Коротко, если будет создан некоторый объект(файл), его имя будет содержаться в указанной переменной, которой можно оперировать в конфигурации.
3. ШАГ ТРЕТИЙ
Содержимое файла /home/muuser/my_script.sh:
Код:
#!/bin/bash
if [[ $# -eq 2 ]]; then
#CHECK_START_VPN
if [[ $1 = check_start_vpn ]]; then
rsync -az -e 'ssh -p 22222' root@192.168.1.1:/home/myuser/init_file /home/myuser/init_file
#CHECK_STOP_VPN
elseif [[ $1 = check_stop_vpn ]]; then
rsync -az -e 'ssh -p 22223' root@192.168.1.1:/home/myuser/stop_file /home/myuser/stop_file
#START_VPN
elseif [[ $1 = start_vpn ]]; then
ip tuntap add dev tun0 mode tun && \
ip addr add 10.0.0.3/24 dev tun0 && \
ip link set tun0 up \
ip route add 10.0.0.0/24 dev tun0 && \
ssh myuser@10.10.10.1 > "ip tuntap add dev tun0 mode tun && \
ip addr add 10.0.0.1/24 dev tun0 && \
ip link set tun0 up && \
ip route add 10.0.0.0/24 dev tun0" && \
ssh -w 0:0 myuser@10.10.10.1
#STOP_VPN
elseif [[ $1 = stop_vpn ]]; then
ip link set tun0 down && \
ip tuntap del dev tun0 mode tun
else fi
else fiПояснения по скрипту: В секции START_VPN последовательно на каждой из нод Node1 и Node3 выполняется по четыре команды - создание виртуального сетевого интерфейса, назначение этому интерфейсу ip адреса будущей виртуальной vpn-сети, активизация интерфейса и создание записи в таблице маршрутизации с целью включения этого интерфейса в область сетевой доступности. Ну и наконец, при помощи команды ssh -w 0:0 myuser@10.10.10.1 устанавливаем само vpn соединение с Node1 (10.10.10.1)
Выдаем права на исполнение скрипта:
# chmod +x /home/myuser/my_script.sh
Заключение:
Вот наверное нам удалось описать все то, что изначально хотелось и одновременно предполагалось к рассмотрению в текущей статье касаемо технологии backconnect. Это было сделано на примере одного из достаточно простых в части реализации вариантов организации такой технологии с использованием исключительно штатных и проверенных средств операционной системы linux, выбранной в данном случае в качестве наилучшего для статьи и как наиболее наглядного и доступного примера, а так же как открытого в части лицензирования и готовых к использованию прикладных приложений решения. И хочу особо подчеркнуть, что в данной статье вариант именно схемы, но специально не затронуты вопросы безопасности внутри нее и в контексте взаимодействия с ней из внешних контуров. То есть, не обозначены такие вопросы как шифрование, сетевая фильтрация различного уровня, безопасность прикладных приложений. В список целей статьи данные вопросы целенаправленно не были помещены из-за достаточной громоздкости тематики. Возможно к этим вопросам придется вернуться отдельно в других, будущих статьях или работах. И возвращаясь к теме, то становится совершенно очевидно, что целей, способов и методов применения подобной технологии, ее конфигураций в целостном виде, либо частями, а так же их различных вариаций можно придумать великое множество. Кроме того, никто не мешает все это улучшать, развивать и дополнять собственными наработками или разработками в зависимости от стоящих перед вами интересных и разнообразных задач, наличие которых в вашей работе, учебе или в просто повседневном досуге и хочу искренне пожелать всем читателям. Многое в ваших руках, только дерзайте!
Спасибо за внимание -)