Dous scripts que pelexan pola mesma ruta é a forma habitual dun problema de VPN Linux que se arquiva como un erro de enrutamento. Un compoñente crea o dispositivo de túnel, outro engade unha ruta predeterminada, un terceiro reescribe a configuración do resolvedor e un cuarto recarga as regras do cortalumes. Calquera deles pode desfacer o traballo doutro, e o gañador é simplemente quen se executou ao final. A pregunta que paga a pena responder non é que paquete instalar, senón que compoñente ten autoridade sobre cada peza de estado.

Escriba ese mapa unha vez, e a maioría dos fallos de reconexión deixan de ser misteriosos. Catro obxectos importan: o dispositivo e os seus enderezos, as rutas e as regras de política, a configuración de DNS e o cortalumes.

O dispositivo e os seus enderezos

Un dispositivo de túnel créao ou ben un xestor que coñece o perfil, ou ben un demo que alguén iniciou a man. Ambos os arranxos funcionan por si sós; mesturalos non. Se NetworkManager posúe o perfil, deixe que tamén posúa o dispositivo, e non inicie un OpenVPN sen xestionar contra o mesmo nome de túnel.

Anote quen elimina o dispositivo cando remata a sesión. Un dispositivo que sobrevive á súa sesión é a fonte máis común de enderezos obsoletos e da confusión que os segue.

Rutas e regras de política

É nas rutas onde os conflitos de propiedade fan dano visible. Un xestor de conexións instala unha ruta predeterminada para o túnel máis unha ruta máis específica para a rede remota; despois un script escrito a man engade a súa propia ruta predeterminada cunha métrica distinta e gaña ou perde en silencio segundo o momento. Decida que entradas dependen da conexión, cales son política permanente e que compoñente as refresca tras unha reconexión. Despois manteña os outros compoñentes fóra desa táboa.

As regras de política merecen a mesma claridade, porque unha regra que apunta a unha táboa que ninguén enche produce un burato negro que parece exactamente un túnel morto. Se existe unha regra para forzar o tráfico a algún sitio, a táboa que selecciona debe ser mantida polo mesmo propietario.

O DNS sempre é un propietario aparte

Un demo resolvedor execútase como o seu propio proceso baixo a súa propia identidade, así que non herda por accidente as decisións de enrutamento do túnel. Cando a VPN empuxa servidores DNS, algo debe traducilo a unha configuración por enlace que o resolvedor respecte, e algo debe retirala despois.

O mito aquí é que escribir un servidor de nomes no perfil cambia onde van as consultas. Cambia o que se lle di ao resolvedor, non que socket usa o resolvedor augas arriba. Probe cunha consulta máis unha busca de ruta en lugar de confiar no ficheiro.

O estado do cortalumes, e quen o restaura

As regras do cortalumes son o obxecto que máis se sobrescribe nun host de VPN. Un xestor pode engadir regras NAT ou de reenvío por conexión, mentres un servizo de cortalumes no arranque recarga un conxunto de regras gardado e bórraas. Escolla unha soa autoridade para a política e faga que a outra sexa consumidora dela, ou acepte que un reinicio cambia o comportamento en silencio. As excepcións ligadas á conexión pertencen a un ficheiro que carga o mesmo propietario, non a un comando iptables escrito durante a resolución de problemas.

Se as regras deben sobrevivir a unha reconexión, dígao explicitamente. Se non deben, dígao tamén, porque o seguinte enxeñeiro asumirá a resposta máis cómoda.

Ciclo de vida: arranque, reconexión, desmontaxe

Dea un propietario a cada un deses tres momentos. No arranque, decida que prepara os requisitos previos e en que orde. Nun reinicio suave, lembre que o dispositivo pode sobrevivir mentres que o estado da sesión non, así que debe executarse un validador en lugar dun creador. No desmontaxe, retire só o que creou esta conexión, porque restablecer todas as rutas ou baleirar todo o cortalumes non é o mesmo que retirar un só túnel.

Para a observación, ip monitor link address route mostra os cambios do núcleo a medida que ocorren, pero informa de eventos en lugar de intención: unha ruta eliminada non di nada sobre que proceso a eliminou. Combine-o co mapa de propiedade, e un apagado confuso convértese nunha breve lista de candidatos.

As exclusións tamén teñen un custo. Marcar toda unha clase de dispositivos como non xestionada para escapar dun conflito entrega ese estado a ninguén, o que é unha decisión e non unha corrección.

Artigos relacionados