Запуск VPN и сайта на одном хосте без конфликтов

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

Решите, что слушает на каком адресе и транспорте

Напишите таблицу с тремя столбцами, адрес, транспорт и порт, и одной строкой на каждый сервис, включая административный интерфейс. TCP 443 для сайта и UDP 443 для VPN не конфликт, даже если номера совпадают, потому что транспорт различается. Двум сервисам на одном адресе, транспорте и порте нужен порядок, который документирует реализация, а не тот, который вы придумываете во время сбоя. Эта таблица ещё и артефакт, который делает следующее изменение проверяемым.

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

Решите, какая идентичность принадлежит какому сервису

Сертификат браузера и учётные данные партнёра VPN — разные объекты с разными моделями доверия. Веб-сертификат проверяется публичным органом и называет имя хоста, тогда как учётные данные партнёра аутентифицируют устройство или пользователя перед концентратором и могут быть самоподписанными или выданными внутри. Использование одного вместо другого работает в узких случаях и редко стоит такой связки. Отключение проверки, чтобы подошёл общий сертификат, — не план разделения; оно убирает проверку, которая придавала учётным данным смысл.

Держите два хранилища независимыми и запишите, какой орган выдаёт каждое. Когда одно обновляется, другое не должно требовать изменений, а если требует, то связка — это то, что нужно исправить.

Решите, где живёт администрирование

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

Пишите узкие правила брандмауэра, по одному на слушателя, называя интерфейс или сервисную учётную запись там, где платформа это поддерживает. Широкие правила, открывающие хост потому, что сайту нужен 443, — это путь, которым административные интерфейсы попадают в индексы сканеров.

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

Решите, что делать, когда двое конкурируют

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

Изоляцией может быть контейнер, лимит cgroup, отдельная очередь или второй хост, и правильный выбор зависит от того, какой ресурс конкурирует. Смена порта здесь ничего не исправляет, а более крупный экземпляр ничего не исправит, если лимитом является одна насыщенная очередь. Решайте измерением: назовите ресурс, нагрузите его, затем выберите наименьшую изоляцию, которая убирает конкуренцию.

Проверьте снаружи, затем ещё раз после перезапуска

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

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