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

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

Вирішіть, що слухає на якій адресі та транспорті

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

Окремі адреси або другий порт роблять володіння видимим у перехопленні пакетів, і це цінніше за елегантність. Деякі реалізації VPN підтримують спільне використання порту з веб-сервером, але механізм специфічний: демон перевіряє перші байти й пересилає трафік, який не є його протоколом. Загальний зворотний проксі HTTP цього не робить, і переписування заголовків не змусить його зрозуміти рукостискання зашифрованого тунелю. Прочитайте нотатки щодо розгортання протоколу, наприклад документацію слухача OpenVPN, і дотримуйтеся порядку, який вона описує.

Вирішіть, яка ідентичність належить якій службі

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

Тримайте два сховища незалежними й запишіть, який орган видає кожне. Коли одне оновлюється, інше не повинно потребувати змін, а якщо потребує, то зв'язування — це те, що треба виправити.

Вирішіть, де живе адміністрування

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

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

Переглядайте ці правила за таблицею слухачів щоразу, коли додається служба. Огляд дешевий, і він ловить правило, яке хтось додав о другій годині ночі.

Вирішіть, що робити, коли двоє конкурують

Ділити хост означає ділити процесор, пам'ять, файлові дескриптори й пропускну здатність, і спірний ресурс не завжди очевидний. Завантажений сайт може заповнити таблицю з'єднань, вичерпати робочі слоти або так натиснути на чергу диска, що журналювання VPN зупиниться. Дивіться на споживання за службами, а не на суми хоста, бо середнє приховує, який процес голодує. Якщо одне навантаження регулярно заважає іншому, ізолюйте їх, замість того щоб налаштовувати навколо симптому.

Ізоляцією може бути контейнер, ліміт cgroup, окрема черга або другий хост, і правильний вибір залежить від того, який ресурс конкурує. Зміна порту тут нічого не виправляє, а більший екземпляр нічого не виправить, якщо лімітом є одна насичена черга. Вирішуйте вимірюванням: назвіть ресурс, навантажте його, потім виберіть найменшу ізоляцію, яка прибирає конкуренцію.

Перевірте ззовні, потім ще раз після перезапуску

Тестуйте з пристрою, який не перебуває в мережі самого хоста: завантажте сайт, підніміть тунель і дійдіть до ресурсу, який його потребує. Потім перезапустіть кожну службу окремо й повторіть інший тест, бо перезапуск — це момент, коли порядок спільного слухача втрачає свою послідовність. Якщо VPN стартує раніше за веб-сервер, який володіє спільним портом, механізм спільного використання може так і не приєднатися, а симптом — тунель, який працював учора. Зробіть залежність явною в порядку юнітів.

Потім підтвердьте межі: сайт відповідає на своєму порту, VPN відповідає на своєму, а адміністративний інтерфейс відповідає лише зі шляху керування. Запишіть результат поруч із таблицею слухачів із датою. Хост, який проходить усі три перевірки після перезапуску, — це хост, який можна передати комусь іншому без брифінгу.