Quen debería ser dono das rutas e do DNS cando se conecta openfortivpn?

Catro etapas apílanse unhas sobre outras nunha sesión de openfortivpn que funciona. O cliente autentícase na pasarela e inicia unha conexión TLS, logo executa PPP dentro desa conexión, despois recibe un enderezo e información DNS, e finalmente aplica rutas de host e axustes do resolutor. Cada etapa pode estar viva mentres a seguinte non o está, e por iso “conectado” é unha palabra tan esvaradía nos fíos de soporte.

A decisión que elimina a maior parte da confusión é quen é dono da última etapa. Ou o cliente VPN aplica el mesmo os cambios no host, ou os fai outro compoñente, e mesturar ambos a medias é como as rutas e os ficheiros do resolutor acaban describindo sesións distintas.

Catro etapas que parecen unha soa conexión

A primeira etapa é a admisión. un dominio de autenticación con nome ou un código dun só uso, e recibe os parámetros que precisa para continuar. Cando o cliente imprime que está conectado á pasarela, iso significa que o transporte TLS está activo. Non significa que PPP negociase, e desde logo non significa que unha aplicación interna sexa accesible.

A segunda etapa é a ligazón PPP. O cliente inicia un proceso PPP contra o dispositivo de túnel, e os dous lados negocian opcións de ligazón e enderezos. Só despois diso o host sabe que enderezos locais e remotos usa a sesión, e só entón unha ruta cara ao túnel pode ter sentido.

A terceira etapa é aplicar esa información ao host, e aquí é onde importa a propiedade. O cliente pode engadir as rutas e reescribir a configuración do resolutor, ou se lle pode indicar que se retire e deixe ambas as cousas ao que xestione a rede nesa máquina. O README do proxecto descríbeas como responsabilidades separadas en lugar dun só comportamento automático.

Quen edita a táboa de encamiñamento

Por defecto, o cliente é o propietario. Engade unha ruta cara á pasarela pola interface física, unha ruta para o par do túnel e rutas para as redes que a sesión pode usar, e despois elimínaas cando o proceso sae. Ese defecto é cómodo nun portátil cun só xestor de rede e sen outro software VPN.

Escolla a cesión só cando algo máis sexa realmente dono do encamiñamento. Unha integración do xestor de rede, un espazo de nomes de rede de contedor ou un axente de encamiñamento de todo o sitio poden saber xa como instalar e limpar os mesmos prefixos. Pasar a opción no-routes entón evita que dous escritores pelexen pola mesma táboa, que é unha carreira que se manifesta como perda intermitente dunha subrede en lugar dun fallo limpo.

O solapamento é a segunda razón para ceder. Se as rutas empurradas inclúen un prefixo que a rede local xa usa, o cliente non pode resolver o conflito por vostede. Alguén ten que decidir se ese prefixo é alcanzable polo túnel, pola ligazón física ou por unha ruta máis específica, e esa decisión pertence a quen sexa dono da topoloxía.

A limpeza é a terceira. Un cliente que falla antes de retirar as súas rutas deixa un burato negro que sobrevive á sesión, e a seguinte conexión pode engadir un duplicado por riba. Quen é dono do encamiñamento tamén o é de verificar que as entradas antigas desapareceron. Faga desa comprobación parte do camiño de inicio, non un paso de limpeza opcional.

Quen é dono do DNS e do ficheiro do resolutor

O DNS é a mesma decisión con bordos máis afiados. O cliente pode aceptar os servidores DNS que informa a pasarela ou o par PPP e escribilos na configuración do resolutor do host. Nunha máquina sinxela iso é exactamente o que quere, porque os nomes internos entón só se resolven mentres o túnel está activo.

Nun host Linux moderno o resolutor pode estar xestionado por un stub local, e reescribir o ficheiro do resolutor ás costas dese stub produce unha configuración que parece correcta e compórtase de forma inconsistente. Se o host xa executa un xestor de resolutor, déixeo ser dono do DNS e aliménteo cos servidores do túnel a través da súa interface compatible. A opción no-dns do cliente é a elección correcta aí, non unha solución alternativa.

O DNS dividido é unha cuestión aparte de quen escribe o ficheiro. Enviar cada consulta polo túnel é simple e lento; enviar só zonas internas por el require configuración por dominio que a maioría dos clientes simples non ofrecen. Decida que comportamento necesita o host antes de activar os cambios do resolutor do cliente. Unha elección equivocada aquí parece unha caída de resolución de nomes mesmo cando o túnel está ben.

Privilexios, dispoñibilidade e a cesión

Crear o dispositivo de túnel e editar rutas de host ou o estado do resolutor require autoridade de rede elevada. O erro común é concluír que, por tanto, todo debe executarse como root, incluído o navegador ou a aplicación que usa o túnel. Manteña pequena a parte privilexiada: o cliente e o seu ficheiro de configuración, propiedade dun administrador, mentres as aplicacións de usuario conservan a súa conta normal.

A dispoñibilidade debe definirse por consumidor. Un supervisor pode considerar o servizo iniciado cando o proceso do cliente se executa e o dispositivo de túnel existe. Un traballo de copia de seguridade debería considerar a VPN utilizable só cando o seu punto de almacenamento responde polo túnel. Son comprobacións distintas, e usar a máis feble para o propósito máis forte produce traballos que comezan demasiado pronto e fallan de forma intermitente. Escriba a definición elixida, porque un supervisor e un traballo que non coinciden sobre a dispoñibilidade son un tícket de soporte esperando a ocorrer.

Probe o contrato con catro observacións: a fase de pasarela complétase, PPP asigna enderezos, a ruta prevista está presente e unha petición a un host interno ten éxito. Despois deteña o cliente e confirme que cada unha desas cousas se eliminou ou restaurou. Se o host aínda resolve nomes internos ou aínda mantén unha ruta despois de pecharse o túnel, a cesión de propiedade está incompleta.