Per què el proxy de Cloudflare no pot transportar OpenVPN amb un sol nom

Una sola màquina executa el lloc web i el servidor OpenVPN, i la temptació és apuntar-hi un sol nom d'amfitrió i deixar que el núvol taronja ordeni el trànsit. El proxy ordena HTTP i HTTPS. No ordena una sessió OpenVPN, sigui quin sigui el port que faci servir aquesta sessió. Dos noms, un de directe i un amb proxy, no costen res i eliminen tota la classe de confusió.

Dos noms, dos transports

Dona al lloc web un registre amb proxy perquè el seu trànsit HTTP i HTTPS passi per Cloudflare. Dona a la VPN un registre només DNS que resolgui directament a l'entrada pública de la VPN, i deixa que el client faci servir el port UDP o TCP per al qual està configurat.

Tots dos noms poden acabar a la mateixa màquina d'origen. La diferència és què passa entre el client i aquesta màquina, i aquesta diferència és el sentit de la separació.

La referència de ports de xarxa de Cloudflare llista quins ports accepta el proxy web ordinari. Aquesta llista tracta d'HTTP i HTTPS en aquests ports, no de protocols arbitraris que casualment comparteixen un número.

El port no és el protocol

Moure OpenVPN a TCP 443 no el converteix en HTTPS. El proxy encara espera una petició HTTP al començament de la connexió, i un client OpenVPN hi envia un missatge de control binari. La connexió falla d'una manera que sembla un bloqueig de xarxa perquè res d'útil arriba a cap registre.

Si el requisit és de debò posar un producte de Cloudflare al camí de dades de la VPN, avalueu-ne un que documenti el suport del protocol que necessiteu. No assumiu que el núvol taronja és un túnel TCP o UDP general, perquè és un proxy invers per a trànsit web amb una feina concreta.

Un registre només DNS és la resposta avorrida que funciona, i és la primera a què cal recórrer.

Una màquina encara necessita dos oients

Els noms separats no permeten que dos processos lliguin la mateixa adreça, port i transport alhora. Si el servidor web ja té el TCP 443 a totes les adreces, una instància d'OpenVPN no el pot prendre també sense un acord deliberat.

Lliga l'oient de la VPN a un port diferent, o a una adreça diferent, o posa al davant un multiplexor documentat i accepta el cost operatiu que comporta. Cadascuna d'aquestes tries ha de ser visible a les regles del tallafoc, perquè un oient que ningú no ha documentat és el que es passa per alt durant un incident. Escriu l'enllaç triat al mateix runbook que descriu el túnel. Així la persona següent no el redescobreix a les dues de la matinada.

Els certificats segueixen la connexió que protegeixen

La connexió TLS del navegador a Cloudflare i la connexió de Cloudflare al teu origen són dues relacions separades amb dos certificats separats. El navegador veu un certificat de vora. L'origen presenta el seu propi certificat a Cloudflare, i un certificat Cloudflare Origin CA està pensat exactament per a aquesta segona relació.

Aquest certificat d'origen és de confiança per a Cloudflare en mode Full (strict) i no és un certificat de navegador de confiança general. Si algú visita directament el nom d'amfitrió només DNS i rep un avís, és la conseqüència esperada d'un camí de confiança canviat, no la prova que el xifratge s'hagi aturat.

Per tant, un lloc web visitat directament necessita una cadena de certificats en què confiïn els seus navegadors. Això pot conviure amb un lloc amb proxy l'origen del qual no s'ha de visitar de cap manera.

OpenVPN porta la seva pròpia identitat de servidor i autenticació de client, amb la seva pròpia autoritat de certificació i la seva pròpia protecció del canal de control. Un cadenat al lloc web no proveeix res d'això, i els dos processos de proveïment han de romandre separats.

L'exposició segueix el nom

Un registre VPN només DNS publica l'adreça a què apunta. Si aquesta adreça també és l'origen web, l'origen no queda amagat, i descriure'l com a amagat perquè l'altre nom té proxy és un error que dura fins que algú el cerca.

Decideix quines peticions web poden arribar directament a l'origen i aplica-ho a l'origen, i després permet l'oient de la VPN segons les seves condicions. Les pàgines de gestió, les baixades de perfils i l'oient de dades poden tenir tres requisits d'exposició diferents fins i tot quan un sol paquet proveeix els tres.

Mantén els enllaços generats al nom web públic i a l'esquema HTTPS, i mantén els perfils de client al nom de la VPN amb el protocol i el port reals. Cap dels dos serveis no hauria de dependre de canviar el paràmetre de proxy de l'altre durant el funcionament normal.

Ordre de treball: nom amb proxy per al lloc, nom només DNS per a la VPN, oients distints, certificat per relació, i després una prova que demostri que cada nom només arriba al servei que ha d'arribar.