Чому проксі Cloudflare не може нести OpenVPN на одному імені

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

Два імені, два транспорти

Дайте сайту запис через проксі, щоб його трафік HTTP і HTTPS ішов через Cloudflare. Дайте VPN запис лише з DNS, який розв'язується прямо на публічний вхід VPN, і дозвольте клієнту використовувати порт UDP або TCP, для якого він налаштований.

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

Довідник мережевих портів Cloudflare перелічує, які порти приймає звичайний вебпроксі. Цей список про HTTP і HTTPS на цих портах, а не про довільні протоколи, яким випадково дістався один номер.

Порт — не протокол

Перенесення OpenVPN на TCP 443 не перетворює його на HTTPS. Проксі досі чекає HTTP-запит на початку з'єднання, а клієнт OpenVPN натомість надсилає бінарне керівне повідомлення. З'єднання падає так, що це виглядає як мережеве блокування, бо нічого корисного не доходить до журналу.

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

Запис лише з DNS — нудна відповідь, яка працює, і саме до неї варто звернутися першою.

Одній машині все ще потрібні два слухачі

Роздільні імена не дозволяють двом процесам одночасно зайняти ту саму адресу, порт і транспорт. Якщо вебсервер уже тримає TCP 443 на всіх адресах, екземпляр OpenVPN не може взяти його теж без навмисної домовленості.

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

Сертифікати йдуть за з'єднанням, яке захищають

TLS-з'єднання браузера з Cloudflare і з'єднання Cloudflare з вашим джерелом — це два окремі відношення з двома окремими сертифікатами. Браузер бачить сертифікат краю. Джерело пред'являє Cloudflare свій власний сертифікат, і сертифікат Cloudflare Origin CA призначений саме для другого відношення.

Цьому сертифікату джерела Cloudflare довіряє в режимі Full (strict), і це не загальноприйнятий довірений сертифікат браузера. Якщо хтось заходить прямо на ім'я хоста лише з DNS і отримує попередження, це очікуваний наслідок зміненого шляху довіри, а не доказ того, що шифрування припинилося.

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

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

Експозиція йде за іменем

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

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

Тримайте згенеровані посилання на публічному вебімені та схемі HTTPS, а клієнтські профілі — на імені VPN із справжнім протоколом і портом. Жоден із сервісів не повинен залежати від перемикання проксі-налаштування іншого під час звичайної роботи.

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