Безопасная настройка VPN WireGuard для системных администраторов

Сеть технического обслуживания вместо общедоступных портов администрирования

Общедоступные административные порты увеличивают уязвимость сервера: попытки входа по SSH, ошибки в настройках административных интерфейсов и случайно открытые службы мониторинга становятся доступными непосредственно из посторонних сетей. Доступ через WireGuard снижает эту уязвимость, поскольку в первую очередь доступным должен оставаться только один определённый UDP-порт для зашифрованного туннеля. Однако WireGuard не маскирует трафик под HTTPS и не поддерживает транспортный режим TCP.

Оптимальной моделью для администрирования VPN, как правило, является сеть типа «звезда»: сервер обслуживает интерфейс wg0 и получает, например, внутренний адрес 10.77.0.1. Ноутбук уполномоченного пользователя подключается как отдельный узел и использует, например, адрес 10.77.0.10. SSH, внутренняя веб-консоль или конечные точки мониторинга принимают запросы через туннельную сеть, а не через публичный адрес сервера.

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

Das Сеть технического обслуживания является исключительно сетевым ограничением. Оно не определяет, какая учетная запись Linux может войти в систему, какие команды эта учетная запись может выполнять или обновлена ли операционная система. В дополнение к этому вам понадобятся SSH-ключи и личные учётные записи, надлежащим образом ограниченные права sudo, правила брандмауэра, обновления безопасности, ведение журналов и надлежащим образом организованный аварийный доступ. Таким образом, сбой в одном из уровней защиты не станет единственным фактором, определяющим доступ.

Правильное распределение ключей, пиров и разрешенных IP-адресов

Каждый узел WireGuard имеет собственную пару ключей. Закрытый ключ хранится исключительно на соответствующем сервере, ноутбуке или устройстве управления; на удаленном узле хранится только открытый ключ, полученный на его основе. Дополнительный прешаред-ключ (PresharedKey) дополняет криптографию с открытыми ключами дополнительным симметричным ключом. Он представляет собой дополнительный уровень защиты, но не заменяет ни секретные ключи, ни надлежащее управление ключами.

Положи один Один пир на каждое устройство , а не общий узел для всей команды. Это позволяет целенаправленно удалить утраченную рабочую станцию или устройство поставщика услуг, которое больше не требуется. Ключи WireGuard обеспечивают доступ к сети технического обслуживания. Отдельно от этого SSH-ключи аутентифицируют человека или устройство перед SSH-сервисом; поэтому отзыв ключей необходимо планировать на обоих уровнях.

Особое значение имеют Разрешенные IP-адреса на сервере. В WireGuard они образуют таблицу маршрутизации криптоключей: для исходящих пакетов они определяют подходящего пира на основе адреса назначения. Для входящих, уже аутентифицированных пакетов они одновременно ограничивают внутренние адреса источника, которые может использовать данный пир. Таким образом, этот параметр представляет собой нечто большее, чем просто указание маршрута.

Если ноутбуку администратора присвоен адрес 10.77.0.10, то на сервере для именно этого узла должен находиться AllowedIPs = 10.77.0.10/32. Присвоение /32 связывает один туннельный адрес с этим пиром. Если бы вы присваивали каждому административному пиру по 10.77.0.0/24, это присвоение стало бы неясным, а конфигурация — излишне обширной. Кроме того, убедитесь, что выбранная сеть VPN не конфликтует ни с локальными сетями, ни с контейнерными сетями, ни с домашними сетями.

Планирование границ сети и модели доступа

Перед установкой спланируйте адресную сетку VPN. Выберите частный диапазон, который не пересекается ни с существующими локальными сетями, ни с облачными сетями, ни с сетями Docker или Kubernetes, ни с часто используемыми домашними сетями. Определите, какие системы должны быть доступны через туннель: только сервер-шлюз, отдельная сеть администрирования или отдельные службы. На основе этого позже будут сформированы маршруты клиентов, правила брандмауэра и, при необходимости, обратные маршруты.

Для каждого устройства зафиксируйте ответственного пользователя, открытый ключ WireGuard, фиксированный IP-адрес туннеля, цель предоставления доступа и порядок отзыва доступа. Группы должны формироваться с учетом конкретных задач, таких как эксплуатация, управление базой данных или внешняя поддержка, а не на основе общего правила „VPN разрешает всё“. Кроме того, обеспечьте наличие независимого аварийного доступа, например, через консоль провайдера. Проверяйте его перед внесением изменений в брандмауэр, SSH или маршрутизацию, чтобы ошибочное правило не привело к блокировке доступа.

Die Брандмауэр является основной сетевой границей: она разрешает использование UDP-порта WireGuard на публичном интерфейсе, но принимает SSH-соединения исключительно через входной интерфейс wg0 или фактически используемый интерфейс WireGuard. Дополнительная проверка сети-источника VPN может еще больше сузить действие правила, однако не должна заменять привязку к интерфейсу. Таким образом, брандмауэр не принимает пакеты, поступающие на публичный интерфейс, исключительно на основании заявленного адреса-источника VPN. WireGuard связывает аутентифицированные внутренние адреса с узлами-партнерами; это правило применяется к пакетам, принятым через туннельный интерфейс.

На уровне SSH к этому добавляются ключи вместо входа с помощью пароля, личные учетные записи и, по возможности, ограниченные правила использования sudo. OpenSSH может работать с AllowUsers Дополнительно привязать учетные записи к исходным адресам или сетям CIDR. Этот второй барьер дополняет тот, который установлен в wg0 связанное правило брандмауэра, но не заменяет его.

Публичные веб-приложения по-прежнему требуют отдельной защиты канала передачи данных с помощью протокола HTTPS и соответствующих сертификатов. Руководство по обеспечению безопасности веб-сайта с помощью TLS Этот уровень предназначен для обработки запросов, поступающих через браузер. WireGuard, в свою очередь, защищает доступ к частной административной сети; он не заменяет ни протокол TLS для общедоступных сервисов, ни процедуры входа в систему, проверки прав доступа и технического обслуживания.

Создание базовой структуры с помощью wg-quick без ловушек маршрутизации

Для отдельного сервера обслуживания достаточно простой схемы «точка-точка»: сервер обеспечивает работу wg0 с адресом туннеля 10.77.0.1/24, административный ноутбук постоянно получает 10.77.0.10/32. Общедоступный сервер принимает только UDP-соединения для WireGuard. Приведенные ниже файлы представляют собой пример конфигурации для wg-quick; в них намеренно не используются реальные ключи.

На сервере узел сопоставляет открытый ключ ноутбука именно с его адресом туннеля. Закрытый ключ сервера хранится исключительно в локальном файле. Сохраните конфигурацию, например, в /etc/wireguard/wg0.conf и ограничьте доступ на чтение контекстом администрирования, поскольку в нём содержится секретный ключ. Открытые ключи, напротив, предназначены для соответствующего контрагента.

[Interface]
Address = 10.77.0.1/24
ListenPort = <UDP_PORT>
PrivateKey = <SERVER_PRIVATE_KEY>

[Peer]
# Administrations-Laptop Person A
PublicKey = <ADMIN_A_PUBLIC_KEY>
AllowedIPs = 10.77.0.10/32

На ноутбуке указано Endpoint на публичный адрес сервера и выбранный порт UDP. Для чистого обслуживания сервера в качестве клиентского Разрешенные IP-адреса как правило, только 10.77.0.1/32 необходимо. Таким образом, в туннель направляется исключительно трафик, предназначенный для VPN-адреса сервера; интернет-трафик ноутбука продолжает проходить по обычному маршруту.

[Interface]
Address = 10.77.0.10/32
PrivateKey = <ADMIN_A_PRIVATE_KEY>

[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = <SERVER_PUBLIC_ADDRESS>:<UDP_PORT>
AllowedIPs = 10.77.0.1/32
PersistentKeepalive = <ONLY_IF_NEEDED>

Указание 0.0.0.0/0 На клиенте, напротив, маршрут по умолчанию IPv4 через туннель означает: один Полный туннель. wg-quick определяет маршруты на основе списка AllowedIPs и обрабатывает маршруты по умолчанию с использованием дополнительной логики политики маршрутизации. Это возможно в случае специально спланированного доступа, однако, помимо прочего, приводит к изменению внешнего трафика и может выявить проблемы с DNS или доступностью.

В данном примере рассматривается исключительно IPv4. Если сервер имеет публичный доступ к IPv6, TCP-порт 22 должен быть явно заблокирован в IPv6-брандмауэре или служба SSH должна быть соответствующим образом привязана. Закрытый доступ по IPv4 не защищает от того, что прослушиватель IPv6 по-прежнему будет доступен из внешней сети. Планируйте адреса туннелей IPv6 и префиксы на стороне клиента отдельно; ::/0 в этом случае речь шла бы о маршруте по умолчанию для IPv6, а не о нейтральном дополнении конфигурации IPv4.

Сначала активируйте туннель, проверьте соединение с адресом VPN и войдите в систему через SSH в рамках второго сеанса. Только после того, как этот способ начнёт надежно работать и будет доступен независимый консольный или аварийный доступ, следует удалить публичный доступ по SSH. При этом проверьте как IPv4, так и, при необходимости, IPv6. Частные ключи не должны попадать ни в тикеты, ни в протоколы чата, ни в системы управления версиями.

Сравнение моделей маршрутизации и правил брандмауэра

Брандмауэр обеспечивает соблюдение требуемой модели доступа. На общедоступном интерфейсе он должен принимать заданный UDP-порт WireGuard; при этом TCP-порт 22 не должен оставаться открытым в качестве общего административного доступа. Вместо этого SSH разрешается только для пакетов, входной интерфейс которых wg0 или, соответственно, используемый интерфейс WireGuard. Дополнительная проверка сети-источника может ещё больше сузить допустимый диапазон VPN, однако правила, основанные исключительно на адресе источника, являются недостаточными.

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

Обязательно учитывайте публичную IPv6-связь. Если удалить только разрешение IPv4 для TCP 22, SSH по IPv6 может оставаться доступным из Интернета. Поэтому заблокируйте этот порт также в правилах IPv6 или настройте службу SSH таким образом, чтобы она не прослушивала публичный IPv6-адрес. Правила IPv4 и IPv6 необходимо проверять отдельно.

В случае брандмауэра с управлением состояниями недостаточно просто теоретически рассмотреть только нужный путь туда. Ответные пакеты разрешенного соединения также должны доходить до клиента; при доступе за шлюзом к этому добавляется обратный путь из целевой сети. Общий допуск всей подсети VPN ко всем службам превращает сеть технического обслуживания в ненужно широкую внутреннюю сеть доступа.

Для обслуживания отдельного сервера наиболее удобна первая модель. Маршрут клиента к 10.77.0.1/32 — этого достаточно, и брандмауэр сможет пропускать SSH только для пакетов, поступающих через интерфейс WireGuard. Порт UDP, конечно, останется видимым извне, но без соответствующего ключа-партнера это не даст возможности получить административный доступ.

Вторая модель требует четкого разделения: в этом случае VPN-сервер выступает не только в качестве конечной точки, но и в качестве маршрутизатора. Брандмауэр должен разрешать, например, SSH-соединения с определёнными серверами администрирования и HTTPS-соединения с внутренней консолью, причём в каждом случае ограничивая их входным интерфейсом WireGuard, конкретными целевыми сетями и портами. Не следует открывать порты баз данных для всего VPN только потому, что пользователи уже подключены.

В случае «полного туннеля» VPN-сервер также выступает в качестве шлюза для подключения к ресурсам в Интернете. Для этого он должен передавать пакеты IPv4 между wg0 и перенаправить его по восходящему каналу; кроме того, для ответов требуется обратный канал связи с сетью VPN. Во многих конфигурациях серверов для этого используется специальное правило Source-NAT на восходящем канале, если сеть вышестоящего уровня не знает маршрута к префиксу VPN. Тщательно планируйте эти правила и ограничивайте их применение только предусмотренной туннельной сетью.

«Full Tunnel» — это не требование безопасности WireGuard, а решение по маршрутизации, принимаемое на стороне клиента. Поскольку wg-quick Поскольку маршруты по умолчанию из списка AllowedIPs обрабатываются особым образом, этот параметр следует использовать только при наличии запланированного преобразования имен, достаточной пропускной способности шлюза и соответствующих правил исходящего трафика. Для обычной Администрирование VPN она, как правило, формулируется шире, чем это необходимо. В случае IPv6 этот же вопрос планирования рассматривается отдельно: ::/0 направляет весь трафик IPv6 через туннель.

Обеспечить целенаправленный доступ к внутренним сетям

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

В качестве первого технического условия необходимо, чтобы шлюз имел право пересылать пакеты IPv4. Параметр ядра net.ipv4.ip_forward активирует это поведение. Не следует рассматривать это как безобидную однострочную команду: согласно документации ядра, изменение ip_forward Остальные параметры конфигурации IPv4 будут сброшены до значений по умолчанию для хоста или маршрутизатора. Поэтому необходимо проверить действующие сетевые и безопасности требования до и после внесения изменений.

Во-вторых, брандмауэру требуются явные Правила транзита в обоих направлениях. Правило не должно просто ограничивать весь транспортный поток от wg0 не допускать в локальную сеть. Вместо этого ограничьте доступ исходной сетью VPN, предусмотренными адресами назначения и необходимыми протоколами, например, TCP 22 для серверов администрирования и TCP 443 для консоли. Базы данных, за исключением обоснованных случаев, остаются за пределами этого разрешения.

В-третьих, целевая сеть нуждается в обратном пути к сети VPN, например, в маршруте для 10.77.0.0/24 через внутренний адрес шлюза. Без этого обратного маршрута прямой трафик может проходить нормально, тогда как ответы не дойдут до администратора. Если маршрутизация в целевой сети невозможна, технической альтернативой может стать Source NAT на шлюзе; однако он скрывает исходный адрес VPN-клиента, что затрудняет ведение журналов на стороне назначения и применение более точных правил.

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

Безопасное управление эксплуатацией и внедрением изменений

Сеть обслуживания остается управляемой только в том случае, если каждому устройству присваивается собственный пир, собственная пара ключей и фиксированный IP-адрес туннеля. Поэтому опись оборудования должна содержать как минимум адрес туннеля, название устройства, ответственное лицо, назначение, дату выдачи и дату проверки. Привязка адреса 10.77.0.10/32 к конкретному ноутбуку администратора позволяет отслеживать доступ и предотвращает использование одной и той же VPN-идентичности несколькими устройствами.

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

В случае утери ноутбука или ухода из компании внешнего сотрудника удали соответствующий узел из конфигурации сервера. Это заблокирует его доступ к административной сети без необходимости смены ключей других администраторов. Отлучение от сообщества однако это не то же самое, что отзыв ключа SSH: ключ WireGuard регулирует маршрут передачи данных, а ключ SSH — вход в целевую учетную запись.

После удаления узла WireGuard не может обмениваться через этот узел дальнейшими пакетами в рамках существующего SSH-соединения; в результате соединение зависает или прерывается после сбоя либо по истечении времени ожидания. Однако удаление узла не приводит к автоматическому отзыву уже выполненного входа в SSH на уровне приложения и не завершает ранее запущенные процессы. Поэтому при расследовании инцидента дополнительно проверьте авторизации SSH, запущенные процессы, учетные записи и, при необходимости, права sudo.

Для целенаправленных изменений можно wg syncconf сравнить существующую конфигурацию WireGuard с указанием конкретных различий; согласно руководству, это должно меньше влиять на сеансы связи между узлами, чем setconf. Тем не менее, это не заменяет процедуру утверждения, двойную проверку или окно технического обслуживания. Перед каждым изменением сохраняй рабочую конфигурацию и записывай, как её восстановить.

Диагностика: от установления соединения до доступа по SSH

В случае сбоя следует строго разделять транспортный уровень, маршрутизацию и приложение. Начните с общедоступного UDP-порта и процедуры установления соединения, прежде чем изменять настройки SSH. Команда wg show отображает для настроенных пиров, в частности, AllowedIPs, время последнего рукопожатия и счетчик передач. Отсутствующие или неизменённые значения указывают на проблему, возникшую до самого подключения по SSH.

Если установлено соединение, проверь на клиенте и сервере фактически установленный адрес туннеля и маршрут к пункту назначения. Для чистого управления шлюзом клиент должен иметь доступ к адресу назначения 10.77.0.1 через интерфейс WireGuard. В случае внутренних адресов назначения к этому добавляются счетчики брандмауэра, разрешённый обратный трафик и обратный маршрут сети назначения; успешное установление соединения не подтверждает выполнение этих условий.

Только после того, как маршрут сети будет настроен правильно, следует проверить работу службы SSH. Проверьте записи, относящиеся к авторизации и ограничению источников, в файле sshd_config, в частности, общие папки, такие как AllowUsers, а также проверь состояние служб и журналы с помощью инструментов твоей дистрибутива. Затем проверь учетную запись пользователя, записи в authorized_keys и правила sudo раздельно. Сама по себе документация по настройке не подтверждает ни успешный вход в систему, ни доступность службы.

Идентичные или пересекающиеся AllowedIPs — это не просто ошибка в документации. При отправке WireGuard сопоставляет адреса назначения с узлом на основе этих префиксов; при приеме они ограничивают внутренние адреса источника аутентифицированного узла. Поэтому дублирующиеся или противоречивые префиксы хостов не образуют однозначного, надёжно отслеживаемого Сопоставление одноранговых узлов. Не следует предполагать, какой конкретный результат даст инструмент администрирования при применении такой конфигурации. Вместо этого следует предотвращать конфликты уже на этапе инвентаризации и проверки конфигурации.

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

wg show
ip route

Выбор инструмента и определение пределов безопасности

Выбор способа администрирования зависит от существующей системы управления сервером, а не от какого-то мнимо универсального метода WireGuard. wg-quick подходит для несложных конфигураций: вспомогательный скрипт настраивает интерфейс, адреса и маршруты, выведенные из списка AllowedIPs. Для сложных сетей, напротив, в документации рекомендуется использовать более специализированные инструменты или осуществлять настройку напрямую с помощью wg и IP-инструментами.

Если хост уже управляет своей сетью декларативно с помощью systemd-networkd, файлы .netdev и .network являются подходящей альтернативой. systemd-networkd поддерживает настройки, специфичные для WireGuard, и может получать закрытые ключи из учетных данных; в качестве меры защиты для конфиденциального содержимого в документации рекомендуется использовать зашифрованные учетные данные или, как минимум, строгие права доступа к файлам. Это особенно подходит для серверов, развертываемых автоматически.

Прямые вызовы из wg и ip обеспечивают максимальный контроль над автоматизацией, маршрутизацией по правилам и специальными сценариями работы брандмауэра, но требуют четко организованной модели эксплуатации. Ни в коем случае не управляйте одним и тем же интерфейсом одновременно с помощью wg-quick, systemd-networkd и собственных скриптов. Наличие нескольких источников управления может привести к взаимной перезаписи маршрутов, адресов или настроек пиров и затруднить надёжный откат изменений.

Функция PersistentKeepalive имеет смысл только для узлов, которые находятся за NAT или брандмауэром с отслеживанием состояния, редко сами отправляют данные, но при этом должны оставаться доступными для входящего трафика. Если значение не указано, она отключена; в документации 25 секунд указаны лишь как возможный интервал, а не как общее значение по умолчанию. Мобильные клиенты часто получают преимущества от роуминга, поскольку WireGuard может обновлять конечную точку на основе правильно аутентифицированных пакетов.

Роуминг и жесткие ограничения на конечные точки — это вопрос баланса: брандмауэр, принимающий UDP-соединения только из известных сетей-источников, может ограничить площадь атаки, но при этом препятствует гибкому использованию в дороге. Кроме того, WireGuard обращает внимание на то, что активный злоумышленник может перенаправить внешний адрес источника и тем самым способствовать возникновению атаки типа «отказ в обслуживании» (DoS), не читая и не изменяя зашифрованное содержимое.

Туннель WireGuard не заменяет системы управления идентификацией, проверки прав доступа, обновлений, резервного копирования или ведения журналов. Он не маскирует свой трафик под HTTPS и не поддерживает режим TCP. Поэтому общедоступные веб-приложения по-прежнему нуждаются в отдельной защите с помощью TLS; требования и способы реализации описаны в этой статье Безопасная настройка HTTPS. Чётко разграничьте этот защитный слой и доступ к VPN для администрирования.