OpenVPN segue a empurrar rutas antigas? Comproba o que cargou

Engades unha ruta, reinicias o servizo, reconéctaste e a táboa do cliente queda exactamente como antes. Poden ser certas dúas cousas distintas: que o servidor nunca cargase a túa modificación ou que o cliente nunca instalase o que recibiu. Non teñen nada en común agás o síntoma, así que o primeiro paso é saber cal dos dous tes.

A comparación de abaixo vai do proceso cara a fóra, porque o proceso é a única autoridade sobre que ficheiro está en vigor.

O ficheiro que editaches e o ficheiro que le o proceso

Comeza pola unit e a liña de ordes que produciu. Nun host con systemd, systemctl cat openvpn@server imprime a liña ExecStart, e unha unit de instancia adoita derivar a súa ruta de configuración do nome da instancia, así que un daemon iniciado como openvpn@office le un ficheiro distinto do iniciado como openvpn@server. Compara iso co argv do proceso en marcha. Unha ferramenta de xestión de configuración engade outra forma de perder o cambio: pode escribir un ficheiro correcto nun lugar que a unit nunca menciona, e entón un despregamento verde parece non ter feito nada.

As marcas de tempo resolven iso rápido: se o ficheiro é máis novo que a hora de inicio do proceso, o proceso non puido lelo. O firmware do router engade un terceiro caso, porque moitos modelos gardan a configuración na flash e reconstrúena durante o arranque, o que converte editar un ficheiro no disco na capa equivocada por completo.

Que empurra o servidor e que instala o cliente

Unha ruta empurrada ten que sobrevivir a dous filtros. No servidor debe estar na configuración cargada, non nun bloque comentado nin nun ficheiro específico de cliente cuxo nome non coincida. No cliente, pull debe estar activado e ningún pull-filter pode estar descartando a opción. Conéctate con verbosity 4 e le as opcións empurradas que informa o cliente: se a ruta aparece nesa lista, o servidor fixo o seu traballo e é o cliente quen escolle non instalala.

Os ficheiros específicos de cliente son unha fonte frecuente de confusión. Un ficheiro nomeado segundo o common name do certificado empurra opcións só a ese cliente, e unha diferenza dun carácter detén o envío en silencio, sen erro en ningún dos dous lados. O servidor rexistra o common name que viu ao conectar, así que compara ese valor co nome do ficheiro, non co que cres que se chama o cliente.

O prefixo empurrado e a ruta de volta son problemas distintos

Un cliente que ignora a propósito redirect-gateway para conservar a súa ruta local a internet crea unha segunda lagoa, sen relación. As sondas do servidor chegan ao enderezo do túnel e as respostas nunca chegan, porque unha resposta dirixida ao IP do túnel do servidor enróutase pola pasarela predeterminada normal do cliente. A ruta de subrede empurrada non ten a culpa aquí; o que falta é unha ruta que devolva o tráfico da rede do túnel do servidor polo dispositivo de túnel.

Engadir esa ruta no cliente corrixe as respostas ás sondas que orixina o servidor. Non substitúe a ruta de subrede empurrada, e o contrario tamén é certo, porque as dúas describen direccións de viaxe opostas.

Compara as táboas nos dous extremos

Despois de calquera cambio, reconéctate e le a táboa do cliente para o prefixo empurrado e para o dispositivo de túnel. Despois proba en ambos os sentidos: do cliente a un host da subrede empurrada, e dese host de volta ao cliente. Unha ruta que existe pero non transporta tráfico significa unha de tres cousas: o outro extremo non reenvía, unha devasa está a descartar o fluxo, ou a resposta non ten camiño de volta.

Mantén tres identificadores xuntos: a ruta de configuración, o nome da unit ou da instancia e a identidade do cliente coa que probaches.

Eses tres converten a próxima incidencia nunha comprobación de cinco minutos en lugar doutra investigación, e son o que necesita un compañeiro cando o túnel pasa a ser problema doutra persoa.

Un problema de rutas que sobrevive a un reinicio a miúdo non é un problema de encamiñamento en absoluto; o fallo está por riba da táboa que non deixas de ler.