Wireguard настройка сервера ubuntu
Обновлено: 05.07.2024
Что такое WireGuard?
Будет ли WireGuard выполнить свое обещание, еще неизвестно, но пока что он продемонстрировал большой успех в росте своей популярности. Тот факт, что WireGuard вошел в ядро Linux 5.6, является твердым свидетельством его надежности. Как Линус однажды выразился, это просто произведение искусства.
Примеры использования WireGuard VPN Server
Хотя название этого руководства посвящено настройке сервера WireGuard VPN, технически это неверно. В отличие от OpenVPN, в WireGuard нет понятия сервера и клиента. Скорее всего, конечные точки сети, подключенные WireGuard, называются одноранговыми узлами, и они общаются друг с другом напрямую через попарные туннели WireGuard. Подобные концепции уже доступны в существующих одноранговых VPN, таких как Tinc или n2n. Даже в такой одноранговой схеме VPN один назначенный одноранговый узел может играть роль VPN-сервера для всех остальных одноранговых узлов. Это традиционный вариант использования службы VPN, цель которого состоит в том, чтобы скрыть свой цифровой след, обойти геозону, защитить себя от слежки в общедоступной сети Wi-Fi и т. д. В этом случае вы настраиваете назначенный одноранговый узел WireGuard на виртуальный частный сервер (VPS) , и пусть он маршрутизирует весь ваш трафик в качестве шлюза по умолчанию. Поскольку одноранговый узел WireGuard работает на VPS, полностью под вашим контролем, вам не нужно беспокоиться о том, что ваши онлайн-действия в VPN тайно регистрируются, что всегда возможно для существующего бесплатного VPN-хостинга. Сервер WireGuard VPN также может быть настроен для ретрансляции трафика между подключенными пользователями (в случае, если они хотят, но не могут напрямую обмениваться трафиком за NAT).
Установите WireGuard на Ubuntu
Неудивительно, что WireGuard уже включен в репозитории по умолчанию всех современных дистрибутивов Linux, включая Ubuntu 20.04. Это делает установку WireGuard довольно простой:
Настройте WireGuard как VPN-сервер
Большую часть ручной настройки WireGuard можно выполнить стандартными средствами ip или ifconfig инструментами, за исключением криптографической конфигурации. Для настройки шифрования и прочего WireGuard поставляется с инструментами командной строки, называемыми wg и wg-quick .
Конфигурацию WireGuard лучше всего выполнять с помощью root, поскольку она включает в себя привилегированные операции. Итак, сначала переключитесь в корень:
Остальная часть процедуры будет выполняться как корень.
В WireGuard каждый подключенный одноранговый узел (включая сервер и клиентов) должен сгенерировать свою собственную пару криптографических (открытый/закрытый) ключей для аутентификации и шифрования. Итак, первым шагом в настройке сервера WireGuard является создание пары ключей для сервера следующим образом.
В приведенном выше примере, команда umask гарантирует, что только корень имеет разрешения на чтение, запись и выполнение /etc/wireguard. Ключевая пара, сгенерированная с помощью, wg будет найдена в /etc/wireguard. Каждому клиенту, который хочет подключиться к серверу, также необходимо сгенерировать свою собственную пару ключей. Конфигурация на стороне клиента рассматривается в другом руководстве.
Затем создайте файл конфигурации сервера WireGuard в формате /etc/wireguard/wg0.conf. Файл конфигурации WireGuard называется именем интерфейса WireGuard, за которым следует .conf. Поэтому при активации wg0.conf будет создан виртуальный интерфейс с именем wg0. В файле конфигурации мы определяем, среди прочего, порт прослушивания сервера, закрытый ключ и частный IP-адрес, который будет назначен серверу, и т.д.
Команда iptables включает и отключает маскировку IP, которая необходима для того, чтобы одноранговые узлы с частными IP-адресами могли связываться друг с другом через свои общедоступные IP-адреса. Здесь убедитесь, что интерфейс, указанный с помощью -o ( ens3в этом примере), является интерфейсом WAN вашего сервера Ubuntu.
Убедитесь, что wg0.conf он недоступен для чтения непривилегированным пользователям.
Теперь активируйте эту конфигурацию с помощью:
Это активирует wg0виртуальный интерфейс, назначит ему частный IP-адрес и активирует IP-маскарад на интерфейсе. Вы можете проверить состояние интерфейса с помощью:
Если вы видите виртуальный интерфейс wg0, это означает, что одноранговый узел WireGuard успешно запущен и работает в Ubuntu.
Шаги настройки WireGuard Post
Чтобы этот одноранговый узел WireGuard мог успешно допустить других одноранговых узлов и действовать как их VPN-сервер, вам необходимо выполнить следующие шаги.
Во-первых, вам необходимо разрешить входящие UDP-соединения на порт прослушивания WireGuard (51820), указанный в /etc/wireguard/wg0.conf.
Как указано выше, правила брандмауэра успешно обновлены ufw и будут включены автоматически при запуске системы.
Затем вам необходимо включить переадресацию IP , чтобы сервер WireGuard VPN мог ретранслировать трафик между подключенными одноранговыми узлами, а также маршрутизировать трафик в качестве шлюза по умолчанию. Откройте /etc/sysctl.conf и раскомментируйте следующую строку.
Если вы назначаете IPv6-адреса одноранговым узлам WireGuard, раскомментируйте следующую строку.
Обновить обновлено sysctl.confс помощью:
Автозапуск службы WireGuard VPN
Если вы используете WireGuard VPN на удаленном экземпляре VPS , вы можете включить автоматический запуск WireGuard при загрузке VPS.
К счастью, WireGuard уже интегрирован с systemd в Ubuntu 20.04. Таким образом, вы можете управлять службой WireGuard с помощью команды systemctl (вместо запуска wg-quick вручную).
Если вы уже запустили WireGuard вручную wg-quick, сначала вам нужно остановить его перед использованием systemctl:
Затем вы можете легко запускать и останавливать WireGuard с помощью systemctl:
Обратите внимание, что wg0 в команде должно быть указано имя вашего виртуального интерфейса WireGuard.
Чтобы включить автоматический запуск WireGuard при загрузке:
Вы можете отслеживать статус WireGuard с помощью:
Теперь ваш сервер WireGuard VPN готов к использованию!
Резюме
В этом руководстве я описываю, как настроить WireGuard VPN в среде Ubuntu Server 20.04. Как видите, установка WireGuard на стороне сервера чрезвычайно проста, в основном из-за того, что WireGuard (как модуль ядра, так и инструменты пользовательского уровня) уже был принят в основных дистрибутивах Linux. В разработке находятся различные интерфейсы пользовательского интерфейса для WireGuard, а последняя версия (v1.16) NetworkManager также начала предоставлять встроенную поддержку WireGuard.
В этой статье мы обсудим, как настроить WireGuard VPN на Ubuntu 20.04, который будет действовать как VPN-сервер. Мы также покажем вам, как настроить WireGuard в качестве клиента. Клиентский трафик будет маршрутизироваться через сервер Ubuntu 20.04.
Эту настройку можно использовать в качестве защиты от атак «Человек посередине», анонимного просмотра веб-страниц, обхода контента с ограничением по географическому признаку или предоставления вашим коллегам, которые работают из дома, безопасного подключения к сети компании.
Подготовка
Чтобы следовать этому руководству, вам понадобится сервер Ubuntu 20.04 с доступом root или sudo .
Настройка сервера WireGuard
Мы начнем с установки WireGuard на машину Ubuntu и настроим его для работы в качестве сервера. Мы также настроим систему для маршрутизации клиентского трафика через нее.
Установите WireGuard на Ubuntu 20.04
WireGuard доступен из репозиториев Ubuntu по умолчанию. Чтобы установить его, выполните следующие команды:
Это установит модуль и инструменты WireGuard.
Настройка WireGuard
В wg и wg-quick инструмент командной строки позволяют настроить и управлять интерфейсами WireGuard.
Каждое устройство в сети WireGuard VPN должно иметь закрытый и открытый ключ. Выполните следующую команду, чтобы сгенерировать пару ключей:
Файлы будут созданы в каталоге /etc/wireguard . Вы можете просматривать содержимое файлов с помощью cat или less . Закрытый ключ никогда не должен передаваться кому-либо и всегда должен храниться в безопасности.
Wireguard также поддерживает предварительный общий ключ, который добавляет дополнительный уровень криптографии с симметричным ключом. Этот ключ не является обязательным и должен быть уникальным для каждой пары одноранговых узлов.
Следующим шагом является настройка туннельного устройства, которое будет маршрутизировать трафик VPN.
Устройство можно настроить либо из командной строки с помощью команд ip и wg , либо путем создания файла конфигурации с помощью текстового редактора.
Создайте новый файл с именем wg0.conf и добавьте следующее содержимое:
Интерфейс можно назвать как угодно, однако рекомендуется использовать что-то вроде include wg0 или wgvpn0 . Настройки в разделе интерфейса имеют следующее значение:
Не забудьте заменить ens3 после -A POSTROUTING чтобы оно соответствовало имени вашего общедоступного сетевого интерфейса. Вы можете легко найти интерфейс с помощью:
wg0.conf и privatekey не должны быть доступны для чтения обычным пользователям. Используйте chmod чтобы установить разрешения на 600 :
После этого wg0 интерфейс wg0 , используя атрибуты, указанные в файле конфигурации:
Команда выдаст следующий результат:
Чтобы проверить состояние и конфигурацию интерфейса, введите:
Вы также можете запустить ip a show wg0 чтобы проверить состояние интерфейса:
WireGuard также можно управлять с помощью Systemd.
Чтобы запустить интерфейс WireGuard во время загрузки, выполните следующую команду:
Сеть сервера и настройка брандмауэра
Для работы NAT необходимо включить переадресацию IP. Откройте /etc/sysctl.conf и добавьте или раскомментируйте следующую строку:
Сохраните файл и примените изменения:
Если вы используете UFW для управления брандмауэром, вам необходимо открыть UDP-трафик на порт 51820 :
Вот и все. Одноранговый узел Ubuntu, который будет действовать как сервер, настроен.
Настройка клиентов Linux и macOS
После установки выполните следующие действия, чтобы настроить клиентское устройство.
Процесс настройки клиента Linux и macOS практически такой же, как и для сервера. Сначала сгенерируйте открытый и закрытый ключи:
Создайте файл wg0.conf и добавьте следующее содержимое:
Настройки в разделе интерфейса имеют то же значение, что и при настройке сервера:
Одноранговый раздел содержит следующие поля:
Если вам нужно настроить дополнительных клиентов, просто повторите те же шаги, используя другой частный IP-адрес.
Настройка клиентов Windows
Загрузите и установите пакет Windows msi с веб-сайта WireGuard .
После установки откройте приложение WireGuard и нажмите «Добавить туннель» -> «Добавить пустой туннель…», как показано на изображении ниже:
Пара публичных ключей создается автоматически и отображается на экране.
Введите имя туннеля и отредактируйте конфигурацию следующим образом:
В разделе интерфейса добавьте новую строку для определения адреса туннеля клиента.
В одноранговом разделе добавьте следующие поля:
После этого нажмите кнопку «Сохранить».
Добавить однорангового клиента к серверу
Обязательно измените CLIENT_PUBLIC_KEY на открытый ключ, сгенерированный на клиентском компьютере ( sudo cat /etc/wireguard/publickey ), и настройте IP-адрес клиента, если он отличается. Пользователи Windows могут скопировать открытый ключ из приложения WireGuard.
После этого вернитесь на клиентский компьютер и откройте интерфейс туннелирования.
Клиенты Linux и macOS
Выполните следующую команду, чтобы открыть интерфейс:
Теперь вы должны быть подключены к серверу Ubuntu, и трафик с вашей клиентской машины должен проходить через него. Проверить соединение можно с помощью:
Вы также можете открыть свой браузер, ввести «what is my ip», и вы должны увидеть IP-адрес своего сервера Ubuntu.
Чтобы остановить туннелирование, wg0 интерфейс wg0 :
Клиенты Windows
Если вы установили WireGuard в Windows, нажмите кнопку «Активировать». После подключения одноранговых узлов статус туннеля изменится на Активный:
Выводы
Мы показали вам, как установить WireGuard на машину с Ubuntu 20.04 и настроить его как VPN-сервер. Эта настройка позволяет вам просматривать веб-страницы анонимно, сохраняя конфиденциальность ваших данных о трафике.
Если вы столкнулись с какой-либо проблемой, не стесняйтесь оставлять комментарий.
WireGuard — это новый, современный VPN сервис с открытым исходным кодом, который позиционирует себя как замену других VPN решений. Проблема прочих VPN решений в том, что их тяжело правильно настроить и дорого обслуживать. Преимущества WireGuard — простота использования, современная криптография, компактный читаемый код и высокая производительность.
Нам потребуется решить следующие задачи:
Установка WireGuard
В Ubuntu 20.04 получить WireGuard можно из официальных репозиториев. В более старых дистрибутивах или для получения самой свежей версии следует использовать PPA:
Устанавливаем пакет wireguard на сервере и на клиентах:
Создаем ключи сервера
Создаем приватный и публичный ключ сервера. Ключ — это просто строка, которую мы будем указывать в файлах конфигурации. Эти строки сейчас записываем в файлы, чтобы потом их оттуда взять, но сами файлы ключей нам не нужны.
Команда wg genkey создает приватный ключ, а команда wg pubkey — публичный ключ. Обе команды выводят сформированные ключи на экран. Для формирования публичного ключа нужен приватный ключ. А мы просто эти ключи записываем в файлы server-private.key и server-public.key .
Эти две команды можно заменить одной — создаем приватный ключ, записываем его в файл и передаем дальше по конвейеру — для создания публичного ключа, который тоже записываем в файл.
Создаем ключи клиентов
Создаем ключи для первого клиента
Создаем ключи для второго клиента
Файл конфигурации сервера
Cоздаем файл конфигурации сервера, сразу в директории /etc/wireguard/ :
С точки зрения сервера AllowedIPs — это ip-адреса, которые клиенту разрешено использовать в качестве ip-адреса источника. Если клиент отправляет пакет с ip-адресом источника, которого нет в списке AllowedIPs сервера, то пакет будет просто отброшен. С другой стороны, AllowedIPs говорит серверу, какому клиенту отправлять пакеты с тем или иным ip-адресом назначения, и каким публичным ключом их шифровать.
Запуск службы сервера
Теперь все готово к запуску службы сервера, для этого можно использовать команду wg-quick или systemctl :
Добавим службу в автозагрузку
Файлы конфигурации клиентов
Cоздаем файл конфигурации первого клиента. Создавать будем на сервере, а потом с компьютера клиента скопироуем готовый файл. Можно создавать файл конфигурации клиента прямо на клиенте, но на сервере удобнее — все ключи под рукой.
Cоздаем файл конфигурации второго клиента:
Запуск службы клиента
С компьютера первого клиента копируем файл конфигурации с сервера:
Теперь все готово к запуску службы:
Добавим службу в автозагрузку:
Для второго клиента все будет аналогично, так что нет смысла повторять.
Проверяем, как все работает
Выполняем ping сервера с первого клиента:
Выполняем ping сервера со второго клиента:
Связь между клиентами
Сейчас клиенты отправляют в туннель только пакеты с ip-адресом назначения 10.8.0.1/32 . И принимают из туннеля только пакеты с ip-адресом источника 10.8.0.1/32 . Давайте это изменим:
А на сервере разрешим пересылку пакетов между интерфейсами. Чтобы пакеты, приходящие на виртуальный интерфейс wg0 могли с этого же интерфейса уходить.
Директивы PreUp , PostUp , PreDown , PostDown — это команды, которые будут выполнены до/после up/down интерфейса. Чаще всего используются для настройки пользовательских параметров DNS или правил брандмауэра. Специальная строка %i преобразуется в имя интерфейса wg0 , wg1 , wg2 и т.д. Каждая директива может быть указана несколько раз, в этом случае они выполняются по порядку.После запуска сервера можно посмотреть правила netfilter для цепочки FORWARD таблицы filter :
После остановки сервера мы все возвращаем к значениям по умолчанию — форвардинг пакетов запрещен, политика по умолчанию для цепочки FORWARD — ACCEPT , правило пересылки пакетов удалено:
Весь трафик через сервер
1. Настройка клиентов
Поскольку теперь весь трафик клиенты направляют в туннель, требуется указать DNS-серверы, которые им следует использовать. А чтобы wireguard мог изменить сетевые настройки клиентов, нужно установить пакет resolvconf или openresolv .
Зачем нужен пакет resolvconf можно прочитать здесь. Без resolvconf клиент при запуске будет выдавать ошибку «resolvconf: command not found».
2. Настройка сервера
Клиенты будут отправлять весь трафик в туннель, но что с ним делать — сервер не знает. Так что редактируем файл конфигурации сервера
Сразу после запуска службы мы выполянем команды: разрешаем форвардинг пакетов между интерфейсами, разрешаем клиентам общаться между собой, разрешаем клиентам выходить в интернет и добавляем правило SNAT для интерфейса ens3 , чтобы все клиенты использовали единственный ip-адрес 123.123.123.123 . При остановке службы — действие всех этих команд отменяется.
3. Проверяем ip-адрес клиента
Все готово, перезапускаем службы сервера и клиентов, потом на любом клиенте открываем браузер и смотрим ip-адрес:
Cryptokey Routing
В основе WireGuard лежит концепция под названием Cryptokey Routining, которая работает путем связывания открытых ключей со списком ip-адресов, которые разрешены внутри туннеля. Каждый сетевой интерфейс имеет закрытый ключ и список одноранговых узлов. У каждого однорангового узла есть открытый ключ. Открытые ключи используются одноранговыми узлами для аутентификации друг друга.
Например, серверный компьютер может иметь такую конфигурацию:
А клиентский компьютер может иметь более простую конфигурацию:
Получение пакетов на стороне сервера. Cервер будет принимать пакеты от клиента, если ip-адрес источника соответствует списку разрешенных ip-адресов для этого клиента. Когда сервер получил пакет от узла gN65BkIK… , после расшифровки и аутентификации, если ip-адрес источника — 10.10.10.230 , то он принимается, в противном случае — отбрасывается.
Получение пакетов на стороне клиента. У клиента есть только один узел, откуда можно получать пакеты — это сервер. Сервер может отправлять пакеты клиенту с любым ip-адресом источника (об этом говорит 0.0.0.0/0 ). При получении пакета от узла HIgo9xNz… , если он правильно расшифровывается и аутентифицируется (с любым ip-адресом источника), пакет принимается, в противном случае — отбрасывается.
Существует много разных программ предоставляющих vpn соединение клиент-сервер, как платные многофункциональные с разными возможностями, так и бесплатные. Но что если стоит задача реализовать комплекс функций, таких как:
- подключение клиента автоматически при загрузке ОС
- автоматически восстанавливать соединение при переключении между WiFi точками
- VPN клиент должен быть виден из офисной сети
- кросплатформенность vpn клиента и ПО для удаленного управления
- минимальное участие пользователя в настройках vpn клиента
- доступ клиента к хостам и подсетям ограничивается правилами ACL
- настройка клиентов и ACL из одного удобного GUI
- отказоустойчивость VPN серверов
- логирование (минимум Layer 3)
- передавать логи в поисковую систему (например ELK стек)
Наблюдая за повседневными тяжбами тех. поддержки удаленного администрирования клиентов, уже давно зрела мысль сделать сотрудников работающих удаленно и внутреннюю инфраструктуру как одно целое и легко управляемое. В условиях, когда все больше сотрудников переходят на удаленную работу, это все больше становится актуально.
Основная задача была сделать дополнительную внутреннюю подсеть без NAT и посредников, чтобы vpn клиент видел внутреннюю подсеть и из внутренней подсети можно было видеть vpn клиента на прямую и чтобы администратор подключенный к одному vpn серверу видел и мог подключатся к vpn клиенту подключенному к другому vpn серверу.
Присматривался и тестировал ПО с которым можно было построить такой монолит. Нужно было что-то, что имеет минимум настроек и параметров с возможностью быстро восстановить работоспособность. После долгих поисков, для реализации задачи пришел к определенному набору ПО.
За основу, где будет развернут vpn сервер была выбрана ОС Ubuntu 18.04.5 LTS.
Для vpn сервера был выбран WireGuard, всем характеристикам он соответствует. Он легковесный, имеет минимум настроек. Клиентская часть запускается при старте ОС, сама поднимает канал и кросплатформенная. Работает через udp протокол. При шифровании канала потеря скорости всего в районе 20%. Каждый клиент получает свой собственный ip адрес, что позволяет управлять доступом каждого клиента через iptables .
В качестве firewall был выбран iptables и его управление через ПО Shorewall. Даже первоначальные настройки Shorewall не вызвали никаких затруднений и в работе он легок для восприятия.
Удаленное управление пользователями в ОС Windows было осуществлено через TightVNC, msi файл которой можно пересобрать по своему усмотрению. Серверная часть ПО не прожорливая, служба не падает, передает только jpeg скриншоты и управление клавиатурой/мышкой. Защищена паролем на подключение и администрирование. Для других ОС есть разные реализации серверной части VNC.
Управление настройками, добавление настроек/клиентов было реализовано через развернутый в инфраструктуре GitLab и CI Pipelines. Все редактирование/создание файлов можно осуществлять через веб интерфейс не используя команду git которую не до конца могут понимать коллеги из поддержки. К тому-же через веб интерфейс визуально будет понятнее.
Сбор логов был реализован через Fluentd и/или Filebeat и все отправлялось в Elasticsearch.
С небольшой вводной закончил, далее будет расписано как все собрать с небольшими пояснениями. Все ссылки будут в конце статьи.
Установка ПО для различных ОС есть на официальном сайте.
Генерируем публичный и приватный ключи.
Все ключи лежат /etc/wireguard/
Создаем файл wg0.conf
Собираем конфигурационный файл
Во многих мануалах еще добавляют 2 строчки:
Последние строчки PostUp и PostDown верны если вы хотите клиента спрятать за NAT . В таком случае все клиенты при подключении будут иметь ip адрес внутреннего сетевого интерфейса сервера, но нам это не нужно, поэтому мы их не добавляем.
Перед включением интерфейса wg0 , разрешим серверу пересылать пакеты вперед.
Возможно после этих настроек сервер нужно будет перезагрузить, если не будет пинговаться ip wireguard.
В iptables сбросим все цепочки правил и пропустим весь трафик
Проверяем, запустим службу
Добавляем wg на запуск при загрузке
Сделаем копию файла wg0.conf в этой же папке /etc/wireguard/
Важно чтобы в копии были настройки именно [Interface] .
Создадим несколько папок где нибудь в /opt
Скопируем wg0.conf в /opt/git/wg и сделаем ссылку на файл
Для чего последние действия нужны? Скопировав настройки интерфейса в файл wg0.sempl мы вынесли приватный ключ сервера в отдельный файл, при написании CI в .gitlab-ci.yml мы будем это учитывать. Перенесли конфиг в папку /opt/git/wg и сделали ссылку для того, чтобы в последствии собирать целый конфигурационный файл в папке отличной от /etc/wireguard . Сам конфигурационный файл будет собираться из 2 частей, часть с настройками [Interface] и часть с [Peer] клиентов, которые будут добавляться из gitlab.
Настраиваем пограничный маршрутизатор пропускать входящие подключения по порту udp: 5505 на наш сервер. Так-же не забываем указать статический маршрут подсети 192.168.30.0/24 на внутренний сетевой интерфейс нашего сервера. При поднятии интерфейса wg0.conf адрес 192.168.30.1 должен пинговаться с любого хоста в нашей внутренней подсети, если не пингуется советую на этом моменте остановится и решить этот вопрос. Проверьте правила фаервола на маршрутизаторе. Чтобы подсеть 192.168.30.0/24 заработала через ipsec достаточно эту подсеть добавить во 2 фазу политики локальных, а с другой стороны удаленных адресов.
Что мы должны передавать клиенту после всех настроек? Создадим шаблон
Если в AllowedIPs указать 0.0.0.0/0 , то мы завернем интернет трафик клиента через VPN. Можно указывать диапазон внутренних подсетей.
Дополнительно протестируем видимость vpn клиентов из внутренней сети. Возьмем тестовый ноутбук и установим Wireguard клиента, там же создадим новое подключение и скопируем публичный ключ клиента.
На сервере выключаем интерфейс wg0
Создадим peer в файле конфигурации wg0.conf
Тестовому клиенту передаем конфигурацию подключения к серверу
Полная конфигурация wireguard у клиента должна выглядеть так
Сохраняем настройки у клиента и на сервере и запускаем интерфейс wg0
Подключаемся клиентом и пробуем запустить ping на внутренние сервера. Заходим на любой внутренний сервер и запускаем ping 192.168.30.2 к нашему тестовому vpn клиенту, ping от сервера к клиенту должен проходить. Пробуем с внутреннего сервера подключится каким-нибудь ПО для удаленного управления к нашему vpn клиенту, все должно работать и наш тестовый vpn клиент должен быть виден. Если из внутренней сети не получается увидеть vpn клиент, то еще раз проверяем настройки, перезагружаем сервер и проверяем маршруты на шлюзах.
На данный момент никаких клиентов и никаких подключений снаружи нам не нужно, поэтому созданного клиента удаляем из конфигурации wg0.conf .
Вступление есть, продолжаем.
После установки нужно добавить параметры в файл shorewall.conf и создать несколько файлов с переменными и дополнительными параметрами. Большой мануал есть на официальном сайте.
Начнем по порядку, изменим некоторые параметры shorewall.conf
Если в файл логи не будут записываться, добавьте прав на файл/папку. Не забудьте настроить ротацию лога.
Продолжаем настройку shorewall и создадим несколько файлов.
Создаем файл interfaces , в нем запишем переменные для наших интерфейсов и опции
Создадим файл с переменными подсетей и хостов и запишем все наши подсети и важные сервера в сети
Здесь нет ограничений на переменные, мы расписали все внутренние подсети, добавили контроллер домена, free ipa, внутренние DNS, подсети VPN, и административные ip адреса, добавили группу протоколов.
Добавим этот файл в общие настройки
Напишем политику и правила которые будут работать по умолчанию.
В данном примере логируются все соединения. Переменная $FW обозначает сам фаервол, т.е. любое соединение от любого интерфейса направленного на wg будет сброшено. Эти правила применяются последними.
Создадим файл и сделаем описания типа переменных
Самый большой файл получается с сервисами, создадим его и заполним
Расписываем все порты всех наших внутренних сервисов. Какие порты и какой протокол сервисом используются можно найти на официальном сейте каждого из сервисов.
Напишем правила по умолчанию для всех наших подсетей включая и подсети vpn сбрасывающих все соединения
Остался практически самый последний и самый главный файл с описанием всех правил и всех включений с определенным порядком, т.к. Shorewall поддерживает включение множества файлов из папки, для начала сделаем 2 папки в которых мы будем заполнять файлы для клиентов vpn с доступом ко внутренней сети/хостам и с доступом в интернет (да, будем выпускать пользователей в интернет через vpn )
Создаем 2 папки
Разрешим доступ к интернету
Разрешим доступ к некоторым хостам из сети (так же можно комбинировать правила)
После последнего правила не обязательно писать правило DROP , мы все соединения, которые будут сбрасываться реализуем в файле rules .
Итак, добавляем файл rules и вносим правила
- разрешаем соединение сервисов к клиенту и от клиента
- разрешаем/запрещаем соединения к сетям/хостам
- запрещаем доступ ко всем внутренним подсетям и подсетям vpn
- разрешаем доступ в интернет (при наличии файла с правилом)
Применяем правила фаервола
Зачем пропускать интернет-трафик через WireGuard сервер?
Допустим у нас веб-сервер на определенную локацию пропускает только определенный диапазон ip внешних адресов в этот диапазон допустим входит и внешний ip адрес офиса/облака, а т.к. трафик идет через WG сервер и на прямую через пограничный маршрутизатор который выпускает в интернет, то клиент при выходе в интернет будет получать внешний ip офиса/облака и не обязательно заворачивать весь интернет трафик через WG, достаточно просто указать внешний ip адрес пограничного веб-сервера/балансировщика. Для этого у клиента в AllowedIPs необходимо прописать внешний ip (например — AllowedIPs = 10.15.1.0/24, 10.17.1.0/24, 4.3.2.1 ) на который мы хотим выпускать трафик через WG и в rules_internet.d в shorewall добавить правило для клиентского ip .
Во всей этой легкости написания правил доступа клиентов во внутреннюю сеть есть одно "но", shorewall сбрасывает цепочку правил и применяет новые только если увидит в корневой папке /etc/shorewall/ изменения хотя-бы в одном файле, т.е. изменения в папке rules_internet.d/rules_networks.d не изменят правил iptables . Мы учтем это когда будем собирать все в gitlab.
На этом этапе можно создать тестового пользователя и тестовое подключение через Wireguard, разрешить все правилами Shorewall и пингануть с любого хоста внутренней сети vpn клиента. Пинги должны проходить и к клиенту должен быть доступ по всем портам. Если vpn клиент не виден из внутренней сети, значит не добавили правила маршрутизации или есть ограничения фаервола как на vpn сервере, так и на маршрутизаторе. Все vpn клиенты должны быть доступны с административных ip адресов, которые мы указывали в переменной ADM_IP и ADM_IP_VPN .
Предлагаю на этом не останавливаться и продолжить, осталось немного :)
Допустим у нас уже есть selfhosted gitlab для внутреннего использования, если нет, то его не так сложно развернуть через тот-же docker-compose .
Для начала создадим новую группу и новый проект, создадим репозиторий vpn-01 и создадим следующую структуру
Переносим настройки, описанные ранее во все файлы в папке shorewall на gitlab. В README.MD можно вести учет пользователей, написать мануал для суппорта.
Файлы networks.mgmt , params.mgmt и services.mgmt копируем в репозиторий для того, чтобы не редактировать/дополнять правила или переменные на сервере, а производить все опирации с GUI gitlab.
В файле wg0.conf будут записи только клиентов. Добавляем несколько клиентов
При применении правил эти файлы будут прочитанны последовательно и правила будут применяться для конкретных wireguard клиентов.
Всё, настройки shorewall перенесли и добавили 2 клиентов. Далее настраиваем gitlab-runner , Deploy Token с правами read_repository и заполняем .gitlab-ci.yml .
Устанавливаем gitlab-runner на vpn сервере
на сайте в настройках репозитория берем token Settings -> CI/CD -> Runners и регистрируем
Создадим deploy token , заходим в настройки репозитория Settings -> Repository -> Deploy Tokens создаем с правами read_repository
На vpn сервере добавим права для gitlab-runner и добавим в sudo
Добавим побольше прав для папки /opt/git/
Переходим в репозиторий и открываем файл .gitlab-ci.yml на редактирование и вставляем следующие строчки
Запускаем скрипт с последовательными командами:
Запускаем CI/CD -> Pipelines, смотрим последний Commit и запускаем.
Не забываем выдать права кому на Merge Requests, а кому на Pull Requests.
На этом этапе мы уже полностью реализовали задуманное, но нужно идти до конца)
Допустим по счастливой случайности так оказалось, что в нашей сети есть не только GitLab, но и Elasticsearch с Kibana. Реализуем пересылку и хранение логов в Elasticsearch.
Для начала на vpn сервере исправим значение на открытие файлов
После этого нужно будет перезагрузится
Устанавливаем на vpn сервер Fluentd
Добавим строчки в /etc/td-agent/td-agent.conf или сделаем в отдельном файле (тогда нужно будет включить файл в основной конфигурации)
По сути наш лог относится к syslog , поэтому мы его просматриваем и разбираем как syslog
Смотрим в кибану на результат
Только перед этим не забываем добавить новые шаблоны индексов.
С Filebeat все еще проще. Устанавливаем на сервер.
Включаем модуль iptables
Изменяем настройки в самом модуле
И в файле /etc/filebeat/filebeat.yml добавляем наш Elasticsearch сервер
На последок хотел затронуть тему оптимизации Elasticsearch или как заставить Elasticsearch прожевать 7000 шард на одной ноде и не поперхнуться при характеристиках сервера RAM — 10 Gb и vCPU — 6.
На эту тему есть много материала и везде пишут одинаково, в файле /etc/security/limits.conf выставляем лимиты, добавляем в /etc/elasticsearch/jvm.options значение -Xms чуть больше половины RAM.
И допустим в лимитах у нас стоит значение
и подкручен конфиг /etc/elasticsearch/elasticsearch.yml
Но у нас все равно выскакивает индекс с ошибкой
Тут дело в том, что у службы свои лимиты и находятся они в /etc/systemd/system/elasticsearch.service.d/elasticsearch.conf или /etc/systemd/system/multi-user.target.wants/elasticsearch.service и здесь как раз накручиваем значения
Перезапускаем службу/сервер и смотрим как 7000 шард расфасуются за несколько десятков минут.
Вот в принципе и все чем я хотел с вами поделиться, задача поставлена весь процесс написан, и вы можете спросить так в чем отказоустойчивость? А она в том, что вас никто не ограничивает в выборе места разворачивания сервера и количества серверов, можно сделать несколько независимых точек входа на разные сервера и каждый будет со своей конфигурацией, что бы это было отказоустойчивым делайте пользователям сразу как минимум 2 конфигурации и все.
Читайте также: