Dous clientes OpenVPN nun mesmo host Linux: quen é o dono da ruta?

Ambos os perfís informan de que están conectados e un deles transporta en silencio tráfico destinado ao outro. Dous clientes nun mesmo host é unha disposición admitida; dous clientes sen dono para cada prefixo non o é. O traballo trata menos de levantar o segundo túnel e máis de decidir que proceso pode reclamar que ruta. Percorra a orde de abaixo e a configuración despréndese das respostas.

Comece preguntando para que serve o segundo túnel

Tres situacións vense idénticas na liña de estado e necesitan deseños distintos. Unha división por destinos envía un prefixo polo perfil de oficina e outro polo de laboratorio, sen que ningún reclame unha ruta por defecto. Unha división por aplicación adoita manter un túnel completo e dirixir tráfico concreto con regras de política. A conmutación por erro mantén exactamente un túnel activo á vez, o que significa que o segundo non debe arrincar automaticamente.

Escriba o caso antes de abrir calquera ficheiro de configuración, porque esa resposta decide todo o que vén despois.

A disposición rota máis común son dous túneles completos que ambos empuxaron unha ruta por defecto, onde gaña o que se conectou último e o primeiro segue finxindo. Ese estado parece intencionado desde a liña de estado e desperdicia un día da táboa de rutas. Nomear o caso primeiro volve imposible, non só improbable.

Mire os pools antes que as rutas

Dous servidores poden repartir facilmente enderezos dunha soa rangada privada e, cando o fan, o cliente acaba con dúas interfaces dentro dun mesmo prefixo. Ningún destino pode entón atribuírse a unha interface por enderezo, porque ambos parecen igual de correctos. Renumere un pool en lugar de inventar unha regra para romper o empate.

Revise tamén a rede local, porque unha LAN doméstica ou de oficina que se solape cunha rangada de túnel crea a mesma ambigüidade desde o outro lado. Compare os enderezos do host con ambas as configuracións de servidor antes de culpar o cliente. Un cambio de pool nun servidor de laboratorio é unha corrección de cinco minutos, mentres que un rodeo de encamiñamento por política para un prefixo solapado é un imposto permanente para todo o que lea a configuración despois. Decida cal dos dous quere antes de escoller onde intervir.

Dúas familias de enderezos significan dúas roldas desta comprobación. Os pools IPv6 chocan tan silenciosamente como os IPv4.

Dea a cada perfil un dono

Unha instancia por perfil, un ficheiro de configuración por instancia e un nome que identifique o par. No empaquetado ao estilo Debian, o nome despois do signo @ selecciona o ficheiro, por iso dous perfís que comparten un nome de instancia nunca poden funcionar ambos. Confirme a correspondencia desde a unidade instalada e non desde un titorial.

systemctl cat [email protected]
ip -4 addr show

Logo decida quen instala as rutas, que é unha cuestión de política e non de sintaxe.

Cando os dous servidores empuxen conxuntos incompatibles, ou ben engada route-nopull e enumere só os prefixos que cada perfil necesita, ou ben deixe que un conserve a súa ruta por defecto e dirixa o resto cunha regra de política. Dous procesos que ambos instalan unha ruta por defecto acaban cun só gañador e ninguén pode dicir por que. En canto os dous túneles levan tráfico de fontes distintas, unha resposta pode saír polo equivocado, e o patrón que aguanta é unha marca de conexión restaurada nas respostas e dirixida á súa propia táboa. Limite as marcas para que os paquetes cifrados propios dos túneles nunca coincidan con elas.

Verifique por túnel e logo deteña un

Cando ambos estean arriba, tome tres lecturas: o enderezo de cada dispositivo de túnel, a ruta a un host que viva detrás de cada un e o camiño que tomaría un destino fóra de ambos. Unha listaxe de rutas corrente deixa de describir a consulta final en canto entran regras en xogo, así que pregunte ao núcleo que elixiría de verdade. Logo deteña unha instancia e observe que desaparece. Se deter a primeira perturba a segunda, algo segue compartido entre elas: unha ruta, un nome de dispositivo ou unha regra de cortafuegos que ninguén separou.

ip rule show
ip route get 203.0.113.9

Volva levantar o perfil detido e repita as mesmas comprobacións, porque un túnel que funciona unha vez tras un reinicio e nunca máis é un erro de ciclo de vida disfrazado de encamiñamento.

Anote nas notas de despregamento que perfil posúe que prefixo, xunto ás rangadas de pools. Dous túneles son unha disposición deliberada, e o seguinte lector necesita ver o límite antes de tocar calquera perfil. Sen esa nota, o límite volve descubrilo quen estea de garda cando o prefixo compartido por fin se rompa.