Onde vai a ruta en OpenVPN: no cliente ou no servidor?
Unha ruta simple na configuración do servidor cambia o servidor, non o cliente. Escolla o ficheiro do cliente, un push global ou un push por cliente, e comprobe que chegou.
Engade route 10.60.0.0 255.255.255.0 á configuración do servidor, reinicia, volve conectar un portátil, e a subrede segue sendo inalcanzable desde ese portátil. A liña aceptouse, o servizo arrincou limpo e nada no rexistro parece incorrecto. O que ocorreu é que a ruta se instalou na máquina que editou: a pasarela agora cre que pode alcanzar ese prefixo, mentres que ao cliente nunca se lle dixo nada. A localización é toda a cuestión, e hai catro lugares onde a mesma liña pode vivir.
Os catro lugares e quen recibe cada un
Unha ruta pode engadirse coa configuración propia do cliente, ofrecerse a todos os clientes mediante un push global, ofrecerse a un só cliente mediante un ficheiro específico de cliente, ou escribirse no propio contexto de encamiñamento do servidor.
Eses catro casos usan unha sintaxe case idéntica e producen resultados completamente distintos. Os tres primeiros afectan ao que un cliente envía ao túnel; o cuarto afecta a como chega o servidor a unha rede, o que é útil cando o propio servidor necesita un camiño e prexudicial cando se confunde cunha distribución.
Decida cal dos catro quere antes de escribir a liña e despois confirme o destinatario.
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
Por que a ruta simple no servidor sorprende a xente
A configuración do servidor é onde os administradores miran primeiro, e unha directiva de ruta alí lese como unha afirmación sobre a rede VPN. Non o é. OpenVPN trátaa como unha instalación local de ruta na máquina onde se executa o daemon, que é exactamente o mesmo tipo de cambio que faría con ip route e despois esquecería.
A distribución esixe que a ruta se envíe mediante push, e o push esixe que o cliente a extraia. Un cliente iniciado coas opcións extraídas desactivadas ignora a oferta por completo. Comprobe ambos os extremos dese aperto de mans antes de reescribir o ficheiro do servidor, porque o rexistro do servidor non se queixará: pola súa parte, a oferta enviouse. Unha ruta aceptada tamén entra en vigor só na próxima conexión, nunca na sesión na que xa está.
Cando vexa as dúas operacións como separadas, o fallo deixa de ser misterioso: o servidor alcanza o prefixo, o cliente non, e ambas as afirmacións son certas á vez.
Ficheiros por cliente e a identidade coa que coinciden
Un ficheiro específico de cliente nomease segundo a identidade que o servidor autenticou, que por defecto é o nome común do certificado. Un nome de conexión amigable nun cliente de escritorio non é ese valor, e unha discrepancia produce un ficheiro que nunca se le.
Comprobe o directorio que o servidor usa realmente e despois confirme que o nome do ficheiro coincide exactamente coa identidade autenticada, incluídas as maiúsculas e minúsculas.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Dentro dese ficheiro a ruta aínda debe enviarse mediante push, porque o contexto por cliente é un conxunto de opcións aplicadas á sesión dese cliente, non unha táboa de encamiñamento local. Unha ruta simple alí ten o mesmo problema que unha ruta simple no ficheiro global.
O ficheiro propio do cliente e a ferramenta que o xestiona
Unha ruta colocada na configuración do cliente instálase cando ese cliente se conecta e elimínase cando se desconecta, que é o ciclo de vida correcto para un destino estático.
Se un xestor de rede é dono do perfil, pode importar esas opcións unha vez e despois conservar a súa propia copia. Editar despois o ficheiro descargado non cambia nada, o que é unha causa habitual de "a ruta está aí pero non se aplica".
Comprobe o perfil activo en lugar do ficheiro que descargou, e comprobe a configuración importada que mostra o xestor. Despois conéctese e pregunte ao sistema que camiño usa un enderezo concreto, en lugar de supor que gañou o túnel porque a ruta existía nun ficheiro de texto.
Verifique no cliente e despois comprobe o camiño de volta
Pregunte á táboa de encamiñamento propia do cliente polo destino, non á do servidor. Unha consulta para un só host dentro do prefixo abonda para mostrar a interface e o seguinte salto que se usarán.
ip route get 10.60.0.10Se a consulta apunta ao túnel, a distribución funcionou e o problema restante está noutro lugar. Se apunta á pasarela predeterminada, a ruta non se instalou, foi filtrada por unha opción do lado do cliente ou pertence a un perfil que o cliente non usa.
Supoña que a distribución funcionou e aínda así nada responde: entón comprobe o reenvío na pasarela, a ruta de volta do outro lado e calquera devasa entre eles. Unha ruta escolle un camiño, non concede acceso.