Dous túneles OpenVPN nun só host Linux: de quen é a ruta?

Dous perfís conectados, e un deles transporta en silencio tráfico destinado ao outro. Un host Linux pode executar ambos clientes OpenVPN á vez sen dificultade. O que non pode facer é decidir por vostede que proceso pode reclamar que prefixo. Esa decisión debe tomarse antes de que suba o segundo túnel, non despois de que un recurso deixe de responder.

Empece polo traballo que debe facer a segunda ligazón

Unha oficina accesible por un perfil e un laboratorio accesible por outro necesitan ambos túneles arriba e que ningún o reclame todo. Unha soa aplicación testana que debe saír polo segundo perfil necesita unha regra de política en lugar dunha segunda ruta predeterminada. Unha ligazón de reserva só necesita un túnel funcionando á vez, así que a de reposto non debería arrincar coa máquina.

Son tres configuracións diferentes, e confúndense porque as tres comezan igual: un segundo perfil e unha conexión correcta. Escriba primeiro a disposición prevista e logo configure cara a ela. Unha frase de intención aforra unha hora de capturas de paquetes.

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

O primeiro comando lista as instancias que se están executando, incluídas as iniciadas a man fóra do xestor. O segundo imprime a reclamación de ruta predeterminada actual, que é o estado que terá que explicar máis adiante.

Os pools superpostos rompen antes que o encamiñamento

Dous servidores asignarán alegremente enderezos do mesmo 10.8.0.0/24. O cliente pasa a ter dúas interfaces dentro dun mesmo prefixo sen nada que diga que destino pertence a cal, e o comportamento resultante parece unha falla de encamiñamento pero en realidade é unha falla de numeración. Renumerar un pool custa unha edición de configuración; cada solución de encamiñamento posterior custa unha fin de semana. Revise o pool antes de engadirlle unha ruta.

Mire tamén a LAN local. Unha LAN doméstica numerada 192.168.1.0/24 que un túnel tamén expón produce a mesma ambigüidade, e o síntoma é un nome de host que se resolve mentres a conexión nunca se completa. Iso parece unha falla de resolución de nomes ata que imprime as rutas.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

Compare ambas saídas coas dúas configuracións de servidor antes de tocar o cliente. Se os prefixos se superpón, detéñase e renumere, porque ningunha cantidade de reinicios os separará.

Dea a cada perfil a súa propia unidade e a cada prefixo un dono

Cada perfil recibe o seu propio nome de instancia e o seu propio ficheiro de configuración, así que a instancia chamada office carga office.conf mentres a chamada lab carga lab.conf. Confirme esa asignación a través do xestor de servizos en lugar de confiar nun listado de directorio, xa que un drop-in pode cambiar que ficheiro se carga. Equivocar a asignación significa que está axustando o perfil que non se executa.

Logo decida quen instala as rutas. Cando os servidores empuxan conxuntos incompatibles, ou rexeita o empuxón e lista os prefixos vostede mesmo, ou deixa que un perfil conserve a predeterminada e dirixe o outro con regras de política. Dous procesos que instalan ambos unha predeterminada acaban cun gañador silencioso e sen rexistro escrito da decisión.

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

O primeiro mostra a unidade con calquera anulación que cambie os seus argumentos. O segundo mostra se o perfil acepta as rutas empuxadas, que é o interruptor que decide todo o demais.

As marcas manteñen as respostas na interface da que chegaron

Cando cada túnel serve fontes distintas, unha resposta pode saír pola ligazón equivocada e a conexión morre tras o primeiro paquete. O patrón que aguanta é marcar os paquetes entrantes pola interface de entrada, restaurar esa marca na resposta e dar a cada marca unha táboa coa súa propia porta de enlace predeterminada.

O filtrado laxo de ruta inversa normalmente ten que relaxarse para as interfaces afectadas, porque unha resposta chega lexitimamente por unha ligazón que a táboa principal nunca escollería. Manteña as marcas estreitas para que nunca capturen o tráfico cifrado dos propios túneles, o que enviaría o túnel a través de si mesmo.

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

Lea as regras existentes antes de engadir outra. As prioridades duplicadas e as táboas esquecidas son a razón habitual de que unha política de marcas pareza non ter efecto ningún.

Demostre o illamento detendo unha ligazón

Con ambos túneles arriba, rexistre o enderezo de cada interface, a ruta a un host detrás de cada túnel e o camiño que toma un destino non relacionado. Pregunte ao kernel pola busca en lugar de ler unha soa táboa, porque unha táboa nunca mostra a decisión final.

Despois deteña unha instancia e observe como a súa interface e as súas rutas desaparecen mentres a outra segue. Unha ruptura na supervivente significa que as dúas aínda comparten un nome de dispositivo, unha ruta ou unha regra de firewall que ninguén separou.

Devolva o perfil detido e repita as mesmas comprobacións. Cando un túnel só sobrevive ao primeiro arranque tras un reinicio, está vendo un defecto de ciclo de vida e non un deseño de encamiñamento.