Чаму проксі 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, асобныя слухачы, сертыфікат на кожныя ўзаемаадносіны, затым адзін тэст, які даказвае, што кожнае імя дасягае толькі таго сэрвісу, які павінна.