Encaminar els clients d'OpenVPN a través de Cloudflare? Comproveu primer el rol
Un client de dispositiu no és un encaminador. Confirmeu que el rol de Cloudflare reenvia els paquets d'altres hosts i manteniu el túnel propi del servidor a la seva ruta antiga.
Teniu un servidor OpenVPN que funciona i un amfitrió que també executa el programari de dispositiu de Cloudflare, i el següent pas òbvi sembla dirigir el trànsit dels clients cap a ell. Dues connexions que funcionen en una màquina no sumen una passarel·la de trànsit. El que falta és un rol documentat per reenviar paquets que pertanyen a una altra persona, i una política que classifiqui aquests paquets quan arriben.
Abans de qualsevol regla hi ha quatre preguntes: quin trànsit entra, on va després, com troben el camí de tornada les respostes i què fa el disseny quan falla aquest segon camí. Les dues primeres són preguntes de capacitat.
Dos serveis en un sol amfitrió no són un camí de trànsit
Un client de dispositiu està fet per gestionar el trànsit que s'origina a la màquina on s'executa. Intercepta la resolució de noms, o trànsit d'aplicacions seleccionat, i l'envia pel seu propi túnel, i la seva política està escrita per a l'usuari d'aquest dispositiu i els processos d'aquest dispositiu. Un paquet reenviat des d'un client OpenVPN no és sortida local, així que les mateixes regles no el classifiquen. Això no és un detall de configuració que pugueu tapar amb una regla més àmplia, perquè decideix si el programari veu el paquet o no.
Per això la pregunta de disseny és una pregunta de capacitat. O el producte instal·lat té un rol documentat que reenvia trànsit per a altres xarxes, o la funció de trànsit pertany a un altre lloc completament.
Quin rol de Cloudflare pot reenviar
El client de dispositiu de Cloudflare ofereix modes que difereixen en abast: només resolució de noms, trànsit del dispositiu i de vegades tots dos. Cap d'aquests modes converteix l'amfitrió en un encaminador per a un rang privat que arriba per un altre túnel. El rol d'encaminament dedicat és un producte separat amb el seu propi connector, registre i model de xarxa.
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
Comproveu el rol instal·lat abans de dissenyar rutes al seu voltant. Llegiu quina interfície crea el connector, si anuncia prefixos concrets o una ruta per defecte, i si la política local s'aplica tant als paquets reenviats com als locals. Si només es gestiona el trànsit local, el servidor OpenVPN no pot ser el punt de trànsit per molt que s'escrigui la regla de traducció.
Aquí també cal formular amb precisió el requisit de sortida pública. Una sortida proporcionada per Cloudflare per al trànsit de clients reenviat és un cas d'ús concret, i cal confirmar-lo contra el servei que realment teniu.
Manteniu el túnel exterior independent de la nova ruta
En el moment que afegiu una ruta per defecte cap a la nova interfície, el trànsit sortint propi del servidor comença a competir-hi, i això inclou les respostes als clients OpenVPN i la vostra sessió SSH a la màquina. El símptoma habitual és un túnel que s'estableix i després mor, o un administrador bloquejat fora mentre sembla que el canvi ha funcionat. Compareu ip route get per al punt final abans i després, i feu servir encaminament per política o una ruta a l'amfitrió per mantenir el transport propi del servidor on era. Feu aquesta comparació des de la mateixa màquina, perquè la visió del servidor sobre la seva pròpia ruta és la que importa.
Una excepció per a l'adreça pública del servidor no n'hi ha prou per si sola, perquè el camí de tornada de cada administrador remot és un flux diferent. Decidiu quins d'aquests fluxos han de sobreviure al canvi i després verifiqueu-ne cadascun en lloc de suposar que el primer cobreix la resta.
Limiteu el reenviament i la traducció a un sol flux
Els paquets rebuts segueixen el camí de reenviament, no el de sortida local, així que la regla que importa viu al hook forward. On la interfície següent necessita traducció, limiteu l'origen al pool de clients, la destinació al que es permet i la sortida a aquesta única interfície. Una regla masquerade lligada només a una interfície no tria cap ruta per si sola i no permet reenviar més enllà de cap altre filtre.
Decidiu el comportament de tancament per defecte amb antelació i després proveu-lo. Atureu el camí següent i confirmeu que els clients perden la sortida prevista en lloc de tornar en silenci a l'enllaç ascendent habitual, perquè és el resultat que ningú nota fins que el trànsit surt per la porta equivocada. Repetiu la comprovació per a la resolució de noms i per a IPv6, perquè un conjunt de regles només per a v4 deixa un camí v6 obert.
Anoteu les quatre respostes amb què us heu quedat i l'observació que demostra cadascuna. Un camí de trànsit que podeu descriure és un que podeu defensar a la propera revisió d'incidents.