Encamiñar os clientes de OpenVPN a través de Cloudflare? Comprobe primeiro o rol
Un cliente de dispositivo non é un enrutador. Confirme que o rol de Cloudflare reenvía os paquetes doutros hosts e manteña o túnel propio do servidor na súa ruta antiga.
Ten un servidor OpenVPN en funcionamento e un host que tamén executa o software de dispositivo de Cloudflare, e o seguinte paso obvio parece dirixir o tráfico dos clientes cara a el. Dúas conexións en funcionamento nunha máquina non suman unha pasarela de tránsito. O que falta é un rol documentado para reenviar paquetes que pertencen a outra persoa, e unha política que clasifique eses paquetes cando chegan.
Antes de calquera regra veñen catro preguntas: que tráfico entra, a onde vai despois, como atopan o camiño de volta as respostas e que fai o deseño cando falla ese segundo camiño. As dúas primeiras son preguntas de capacidade.
Dous servizos nun mesmo host non son un camiño de tránsito
Un cliente de dispositivo está feito para xestionar o tráfico que se orixina na máquina onde se executa. Intercepta a resolución de nomes, ou o tráfico de aplicacións seleccionado, e envíao polo seu propio túnel, e a súa política está escrita para o usuario dese dispositivo e os procesos dese dispositivo. Un paquete reenviado desde un cliente OpenVPN non é saída local, así que as mesmas regras non o clasifican. Iso non é un detalle de configuración que se poida tapar cunha regra máis ampla, porque decide se o software ve o paquete sequera.
Por iso a pregunta de deseño é unha pregunta de capacidade. Ou o produto instalado ten un rol documentado que reenvía tráfico para outras redes, ou a función de tránsito pertence a outro lugar por completo.
Que rol de Cloudflare pode reenviar
O cliente de dispositivo de Cloudflare ofrece modos que difiren en alcance: só resolución de nomes, tráfico do dispositivo e ás veces ambos. Ningún deses modos converte o host nun enrutador para un rango privado que chega por outro túnel. O rol de enrutamento dedicado é un produto aparte co seu propio conector, rexistro e modelo de rede.
| 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 |
Comprobe o rol instalado antes de deseñar rutas ao seu redor. Lea que interface crea o conector, se anuncia prefixos concretos ou unha ruta predeterminada, e se a política local se aplica aos paquetes reenviados igual que aos locais. Se só se xestiona tráfico local, o servidor OpenVPN non pode ser o punto de tránsito por moito que se escriba a regra de tradución.
Aquí tamén hai que formular con precisión o requisito de saída pública. Unha saída proporcionada por Cloudflare para o tráfico de clientes reenviado é un caso de uso concreto, e hai que confirmalo contra o servizo que realmente ten.
Manteña o túnel exterior independente da nova ruta
No momento en que engade unha ruta predeterminada cara á nova interface, o tráfico saínte propio do servidor comeza a competir por ela, e iso inclúe as respostas aos clientes OpenVPN e a súa sesión SSH á máquina. O síntoma habitual é un túnel que se establece e logo morre, ou un administrador bloqueado fóra mentres parece que o cambio funcionou. Compare ip route get para o punto final antes e despois, e use enrutamento por políticas ou unha ruta ao host para manter o transporte propio do servidor onde estaba. Executa esa comparación desde a propia máquina, porque a visión do servidor sobre a súa propia ruta é a que importa.
Unha excepción para o enderezo público do servidor non abonda por si soa, porque o camiño de volta de cada administrador remoto é un fluxo distinto. Decida cales deses fluxos deben sobrevivir ao cambio e logo verifique cada un en lugar de supoñer que o primeiro cobre o resto.
Limite o reenvío e a tradución a un só fluxo
Os paquetes recibidos seguen o camiño de reenvío, non o de saída local, así que a regra que importa vive no hook forward. Onde a interface seguinte necesita tradución, limite a orixe ao grupo de clientes, o destino ao permitido e a saída a esa única interface. Unha regra masquerade ligada só a unha interface non escolle ningunha ruta por si mesma e non permite reenviar máis aló de ningún outro filtro.
Decida o comportamento de peche ante fallos de antemán e logo próbeo. Detén o camiño seguinte e confirme que os clientes perden a saída prevista en lugar de volver en silencio á ligazón ascendente habitual, porque ese é o resultado que ninguén nota ata que o tráfico sae pola porta equivocada. Repita a comprobación para a resolución de nomes e para IPv6, porque un conxunto de regras só para v4 deixa un camiño v6 aberto.
Anote as catro respostas coas que quedou e a observación que demostra cada unha. Un camiño de tránsito que pode describir é un que pode defender na próxima revisión de incidentes.