Rutas enviadas por OpenVPN non instaladas: tempos, permisos ou política

O servidor di que enviou a ruta, o cliente di que está conectado, e o destino segue sendo inalcanzable. Tres causas producen exactamente esa imaxe. A adición da ruta executouse antes de que existise o dispositivo, ao cliente faltábanlle permisos para cambiar a táboa, ou unha política indicoulle ao cliente ignorar as opcións enviadas.

Desde fóra parecen idénticas e necesitan correccións distintas. Lea o rexistro do cliente no punto onde se toma a decisión da ruta.

Demostre que a ruta está ausente, non só rota

Comece demostrando que a ruta está ausente en lugar de rota. En Linux, ip route show dev tun0 enumera o que o cliente instalou no dispositivo de túnel. En Windows, route print ou Get-NetRoute mostra o mesmo en forma de táboa.

Unha ruta que existe pero non reenvía tráfico é un problema distinto. Iso traslada a investigación ás regras de reenvío e cortalumes, non á instalación da ruta.

Tempos: a adición executouse antes de que existise o dispositivo

O cliente analiza o PUSH_REPLY do servidor despois de que a canle de control estea activa e de que configurase a interface. Só entón toca a táboa de encamiñamento, co mecanismo que proporcione a plataforma. Linux pasa por netlink; Windows usa unha API que necesita un token elevado. Un script ou un cliente que engade rutas en canto le a configuración pode executarse antes de que exista o dispositivo TUN/TAP, e o núcleo rexeita a adición.

A mesma carreira explica por que unha ruta escrita a man funciona mentres que a automática non: cando a escribe, a interface xa está activa.

route-delay existe para este caso, e route-up nomea un script que se executa despois de configurar a interface e as rutas. Poña as rutas que dependen do enderezo do túnel nese gancho en lugar de nunha etapa temperá.

Permisos: quen pode cambiar a táboa

Cambiar a táboa de encamiñamento de Windows necesita un token elevado. Unha GUI iniciada por un usuario estándar pode establecer o enderezo do adaptador a través do servizo e aínda así non poder engadir unha ruta. O rexistro mostra entón un erro do tipo acceso denegado en lugar dun envío ausente.

Iniciar a GUI como administrador, ou usar o cliente baseado en servizo, cambia ese resultado. Unha tarefa programada que inicia o cliente sen o token requirido non o fai.

Comprobe con que conta se executa realmente o cliente antes de cambiar nada. A versión e o modo de servizo deciden que causas son posibles, así que anote ambas xunto á saída da ruta.

Política: as rutas enviadas poden descartarse a propósito

route-nopull fai que o cliente ignore as rutas que envía o servidor, incluída unha ruta predeterminada enviada, mentres o enderezo do túnel segue aceptándose. As opcións de DNS e DHCP enviadas descártanse pola mesma directiva. Ese cliente non é defectuoso; espera liñas de ruta explícitas na súa propia configuración.

route-noexec é un control distinto: detén o cliente por completo de executar cambios de ruta. Unha topoloxía que o cliente non pode mapear pode producir un resultado similar, coa ruta rexistrada como rexeitada en lugar de engadida. Lea a liña do rexistro que informa da decisión en lugar de adiviñar cal das tres se aplica. Despois comprobe o perfil efectivo, porque un importador ou unha ferramenta de xestión pode engadir opcións que o usuario nunca editou.

Un perfil que parece limpo nun editor de texto pode seguir levando unha directiva engadida en tempo de execución.

Compare a lista de envío coa táboa

Tras conectar, poña a lista de envío do servidor xunto á táboa do cliente. En Linux iso é ip route show dev tun0; en Windows, route print ou Get-NetRoute. Se a ruta está ausente, corrixa primeiro a instalación. Se está presente e o tráfico falla, pase á política de reenvío e cortalumes.

Anote a versión do cliente, a conta coa que se executa e se está baseado en servizo. Esas tres realidades din á seguinte persoa que causas quedaron descartadas.