Почему прокси 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, раздельные слушатели, сертификат на каждое отношение, затем один тест, доказывающий, что каждое имя достигает только той службы, которой должно.