Dous clientes OpenVPN nunha soa pasarela Linux: divida a política

Dous demos de OpenVPN poden informar ambos dun túnel correcto mentres a pasarela envía cada cliente polo mesmo. Nada no apretón de mans decide que túnel usa un cliente; decídeo o núcleo, paquete a paquete, percorrendo as regras de política e despois a táboa que cada regra nomea. Visto así, a configuración deixa de tratar de opcións de OpenVPN e convértese nunha matriz de enrutamento con dous propietarios.

O núcleo decide, non o demo

Un paquete reenviado chega á interface LAN e o código de enrutamento avalía a lista de regras por orde de prioridade. A primeira regra cuxo selector coincide nomea unha táboa, e as rutas desa táboa elixen o dispositivo de saída. Se a táboa non ten ningunha ruta coincidente, a busca continúa cara á seguinte regra, e ese é o detalle que fai que unha configuración a medias falle en silencio en lugar de ruidosamente.

O proceso do túnel non ten nada que dicir nese percorrido. Crea unha interface e pode instalar rutas, pero se o paquete dun cliente concreto entra nesa interface depende por completo da táboa á que se enviou. Por iso dous túneles con rutas importadas idénticas compiten, e o último que escribe gaña para todos. É a razón pola que unha configuración pode verse equilibrada nos ficheiros e aínda así enviar todos os clientes por un só demo.

Dea a cada instancia o seu propio conxunto de recursos

Empece polos nomes, porque os nomes reutilizados son a forma en que as dúas instancias acaban compartindo estado por accidente. Asigne dispositivos de túnel distintos, ficheiros de configuración distintos, credenciais distintas e unidades de servizo distintas. Anote o punto final exterior e o enderezo do túnel de cada instancia na mesma táboa que a matriz de política, para que un cambio posterior teña un só lugar onde mirar.

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull mantén as rutas que empurra un servidor fóra da táboa local, que é xusto o que quere cando as táboas de política deben ser explícitas. Se un servidor determinado empurra tamén unha opción redirect-gateway, e se a súa versión de cliente admite a forma con filtro, convén comprobalo no manual en lugar de supoñelo.

Escriba a matriz: orixe, táboa, dispositivo

Para cada grupo de clientes, engada unha regra que seleccione unha táboa por enderezo de orixe e despois poña o camiño desexado nesa táboa:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

A táboa necesita as rutas de destino que o grupo debería ter, máis as excepcións locais ou de xestión que manteñan a pasarela utilizábel. Unha táboa que só contén unha ruta predeterminada é unha política de túnel completo para ese grupo, o que pode ser exactamente o correcto, pero debería ser unha decisión e non unha omisión.

O transporte do propio túnel non está nun grupo de clientes

Os paquetes cifrados de cada demo orixínanse na propia pasarela, dirixidos ao par exterior. Unha regra que só coincide cun prefixo de orixe de cliente deixa tranquilos eses paquetes, e por iso as regras limitadas á orixe son máis seguras que as que coinciden con todo. Unha regra sen selector pode capturar o transporte do propio túnel e devolvelo por un túnel, e entón a conexión falla dun xeito que parece un problema do provedor.

Manteña a sesión de xestión local e o camiño da capa inferior explicitamente fóra das táboas de política. Anote esas excepcións xunto á matriz; forman parte do deseño, non son unha solución provisional que haxa que redescubrir durante un incidente.

Escoller un camiño non o permite

O permiso de reenvío é unha segunda decisión tomada máis adiante no camiño. Unha regra de devasas que acepta paquetes que saen polo segundo túnel non fai que o código de enrutamento o elixa, e unha táboa correcta non concede permiso para reenviar. Ambas as dúas cousas deben existir, e unha proba que só demostra unha enganaralle sobre a outra. Cando un grupo funciona e o outro non, comprobe eses dous pasos por separado en lugar de reescribir as táboas.

A tradución de orixe é unha terceira decisión, e debería acoutarse ao grupo de orixe e ao dispositivo de túnel que realmente o transporta. Engada unha cadea dedicada para as dúas instancias en lugar de baleirar a cadea postrouting, porque servizos non relacionados poden ter entradas alí e un baleirado elimínaas en silencio.

Que ocorre cando cae un túnel

Decida o comportamento ante fallos de antemán. Cando unha táboa de túnel perde a súa ruta, a busca cae á seguinte regra e o tráfico do grupo continúa polo outro túnel ou polo enlace ascendente normal sen ningún erro. Se iso non é aceptábel, engada unha regra de terminación cun número de prioridade máis baixo que devolva un resultado inalcanzábel para esa orixe, para que a perda sexa visíbel en lugar de quedar absorbida.

Enhvíe unha petición nova desde cada grupo de orixe e anote catro feitos: a táboa seleccionada, o dispositivo de saída, a orixe traducida e se a resposta volveu polo mesmo camiño. Logo baixe un túnel e repita. Dous dispositivos TUN nunha lista de interfaces demostran que ambos os demos arrincaron; non din nada sobre cal usou un cliente concreto. A segunda execución, cun túnel menos, é a que mostra se a súa regra de reserva fai o que pretendía.