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