Manteña as rutas privadas e descarte a redirección: túnel dividido de OpenVPN
Un túnel só para redes privadas necesita dúas regras: os prefixos privados pasan por el e a navegación normal conserva a súa ruta local. Eliminar unha ruta predeterminada non é unha política.
O túnel levanta, a aplicación carga e entón todo o demais no portátil comeza a comportarse de forma estraña. Esa é a forma habitual dunha política só privada implementada borrando unha liña. Quitar unha ruta predeterminada empurrada si cambia cara a onde vai o tráfico, pero non di cara a onde debería ir o tráfico no seu lugar, e non toca en absoluto a resolución de nomes. Unha política necesita dúas metades positivas antes de poder probarse.
Borrar a redirección é só a metade do cambio
Unha redirección de túnel completo e unha política só privada difiren no que afirman sobre o mundo. A redirección reclama cada destino, mentres que a política privada reclama unha lista e deixa o resto en paz. Borrar a reclamación sen escribir a lista produce un cliente que non alcanza nada fóra da LAN, o que parece un fallo de enrutamento máis ca un oco de política. Escriba a lista antes de quitar a reclamación, e a orde deses dous pasos deixa de importar.
Ambas as metades son requisitos, non valores predeterminados. Os prefixos privados teñen que entrar no túnel, e os destinos normais teñen que conservar a ruta que tiñan antes da conexión.
Se unha organización esixe o túnel completo, nada disto se aplica. O deseño só privado pertence a despregamentos nos que o enrutamento dividido está aprobado.
pull-filter é unha coincidencia, non un interruptor
A directiva pull-filter elimina as opcións empurradas cuxos nomes coinciden cun prefixo, e iso é todo o que fai. Ignorar a redirección deixa cada outra opción empurrada no seu sitio, que adoita ser o que un quere: as rutas, os axustes de DNS e o valor de porta de enlace de ruta seguen chegando. Tampouco pode eliminar unha directiva escrita no perfil local, porque o filtrado se aplica ao que empurra o servidor.
Resista a tentación de ignorar todas as opcións que comezan por route. Ese patrón tamén descarta as rutas privadas que necesita a conexión, e pode tirar información de porta de enlace da que depende o túnel.
route-nopull é unha decisión máis ampla do que parece. Impide que o cliente acepte as rutas empurradas e as opcións tipo DHCP como grupo, o que é unha política distinta de filtrar unha soa opción.
Escriba a lista de rutas desde a aplicación cara a fóra
Empece polo que o usuario abre en realidade e logo engada as pezas de apoio. Unha aplicación en 10.60.20.15 implica a súa subrede 10.60.0.0/16, e un nome privado implica o resolutor que o responde. Por tanto, un usuario que pediu unha soa aplicación necesita dous destinos e unha decisión de DNS. Todo o que queda máis alá desa lista está fóra de alcance por construción, e iso é o que mantén a política revisable.
Nun servidor que colabora, iso convértese en dúas rutas empurradas, e ningunha das dúas é unha redirección. Conserve a topoloxía do túnel e os valores de porta de enlace de ruta que subministra o servizo existente.
Cando só algúns usuarios necesitan esta política, aplíquea por cliente ou por grupo. Cambiar o enrutamento de todos para arranxar o requisito dun só equipo é a forma en que un túnel dividido se converte nunha interrupción.
| Destination | Intended path |
|---|---|
10.60.0.0/16 | Tunnel, for the approved application services |
10.61.0.53/32 | Tunnel, to reach the internal resolver |
corp.example queries | Internal resolver, selected per namespace |
| Everything else | Local path and local resolver |
Faga que o DNS siga o mesmo camiño
Unha ruta cara ao resolutor non é unha política de resolutor. Nun cliente systemd-resolved o resultado semántico é un dominio de enrutamento para o espazo de nomes privado que apunta ao resolutor interno, e iso é o que fai que só eses nomes o usen. Un cliente de Windows necesita en cambio o seu propio mecanismo de política de espazos de nomes. Unha liña de servidor DNS no perfil non instala ningunha das dúas cousas por si soa.
Comprobe o que seleccionou o sistema operativo en lugar do que pediu o perfil. En Linux, resolvectl status mostra o dominio e o servidor por ligazón; en Windows, a táboa de políticas de espazos de nomes é a evidencia equivalente.
Manteña o resolutor accesible a través do túnel, ou a política apuntará a un enderezo que non se pode consultar. Un enderezo de resolutor ao que o túnel non chega converte unha política que funciona nun tempo de espera esgotado.
Verifique ambas as metades nunha reconexión
Volve conectar o cliente tras o cambio e inspeccione a ruta efectiva cara a un enderezo privado e cara a un público. Despois resolva un nome privado e un nome público e confirme que cada un usou o resolutor previsto. Que un sitio web público cargue só demostra a segunda metade, e esa é a metade que adoita funcionar por casualidade.
Rexiste a política terminada nunha frase: estes prefixos e nomes usan esta conexión, todo o demais segue a ruta local. Despois gárdea no perfil en lugar de reparar os axustes do adaptador tras cada inicio de sesión.