Estoy intentando que algunos clientes Ubuntu 20.04 funcionen para conectarse a un nuevo servidor OpenVPN proporcionado por nuestro nuevo proveedor de servidores.
El objetivo es enrutar solo cierto tráfico hacia el túnel (las rutas correspondientes son impulsadas por el servidor OpenVPN) y hacer que los clientes utilicen también el servidor DNS impulsado por el servidor OpenVPN.
Esto funciona con clientes de Windows 10 y OpenVPN GUI 2.5 listo para usar. Funciona también usando openvpn(2.4.7) desde una terminal como esta: sudo openvpn --config config.ovpny el siguiente archivo de configuración del cliente config.ovpn:
dev tun
tun-ipv6
persist-tun
persist-key
cipher AES-128-GCM
ncp-ciphers AES-128-GCM
auth SHA256
tls-client
client
resolv-retry infinite
remote <ipadressOfProvider> <port> udp4
verify-x509-name "<name>" name
auth-user-pass
remote-cert-tls server
compress
# The following is added only in the config for Ubuntu 20.04
dhcp-option DOMAIN <domainToResolveWithRemoteSiteDNS>
script-security 2
up /etc/openvpn/update-systemd-resolved
up-restart
down /etc/openvpn/update-systemd-resolved
down-pre
Los problemas comienzan al usar network-manager-openvpn(1.8.12) y el archivo de configuración anterior. La conexión se establece y el servidor DNS enviado se actualiza correctamente en systemd-resolved (incluso sin los scripts adicionales upen downla configuración openvpn).
Sin embargo,todoel tráfico se dirige a la tun0interfaz, incluso el tráfico público. El resultado es que yopoderacceder a recursos en el sitio remoto incluso utilizando nombres de dominio internos, peroNo puede accederInternet porque la subred OpenVPN no tiene acceso directo a Internet.
Cambiando la opciónUtilice esta conexión sólo para recursos en su reden la configuración openvpn del administrador de red (que corresponde con la opción ipv4.neverdefaultmostrada a través de nmcli c show config) resuelve el problema de enrutamiento: ahora, solo el tráfico relacionado con las rutas enviadas se dirige al túnel. Sin embargo, también evita que el servidor DNS enviado se aplique a archivos /run/systemd/resolve/resolv.conf.
Hasta ahora no he encontrado una opción para aceptar el DNS enviadoyenrutar solo el tráfico que concierne a las rutas enviadas simultáneamente con el administrador de red.
Algunas observaciones quizás interesantes hasta ahora:
1. Rutas
Network Manager ipv4.neverdefault=nocrea una segunda puerta de enlace predeterminada con una métrica más baja además de las rutas enviadas:
$ ip route
default via 10.*.*.* dev tun0 proto static metric 50
default via 192.168.***.** dev wlp3s0 proto dhcp metric 600
10.*.*.*/24 dev tun0 proto kernel scope link src 10.*.*.* metric 50
158.***.**.** via 192.168.***.** dev wlp3s0 proto static metric 600
169.254.0.0/16 dev wlp3s0 scope link metric 1000
172.**.***.*/24 via 10.*.*.* dev tun0 proto static metric 50
192.168.*.*/24 via 10.*.*.* dev tun0 proto static metric 50
192.168.*.*/24 via 10.*.*.* dev tun0 proto static metric 50
192.168.***.*/24 dev wlp3s0 proto kernel scope link src 192.168.***.*** metric 600
192.168.***.** dev wlp3s0 proto static scope link metric 600
Network Manager ipv4.neverdefault=yesno crea una segunda puerta de enlace predeterminada además de las rutas enviadas (igual que arriba, sin la primera línea).
openvpnen la terminal no crea una puerta de enlace secundaria predeterminada además de las rutas enviadas:
default via 192.168.***.** dev wlp3s0 proto dhcp metric 600
10.*.*.*/24 dev tun0 proto kernel scope link src 10.*.*.*
169.254.0.0/16 dev wlp3s0 scope link metric 1000
172.**.***.*/24 via 10.*.*.* dev tun0
192.168.*.*/24 via 10.*.*.* dev tun0
192.168.*.*/24 via 10.*.*.* dev tun0
192.168.***.*/24 dev wlp3s0 proto kernel scope link src 192.168.***.*** metric 600
2. servidor DNS
Network Manager con ipv4.neverdefault=nosobrescribe /run/systemd/resolve/resolv.conf:
nameserver 172.**.***.**
Network Manager con ipv4.neverdefault=yesno:
nameserver 192.168.***.**
nameserver ****:***:****:****::**
openvpnen la terminalagregael servidor DNS a los existentes y agrega el nombre de dominio servido por el servidor DNS remoto como se define en config.ovpn:
nameserver 192.168.***.**
nameserver ****:***:****:****::**
nameserver 172.**.***.***
search <domainToResolveWithRemoteSiteDNS>
Si tiene alguna idea de qué opciones podrían cambiarse en el administrador de red para procesar config.ovpncomo lo hace el cliente de terminal openvpn, estaré encantado de escuchar su opinión.
gracias valentin
Respuesta1
Después de un poco de "investigación" adicional (principalmente prueba y error), pude conectarme exitosamente al sitio remoto a través del administrador de red mientras solo enrutaba el tráfico de las rutas enviadas.yusando el servidor DNS empujado.
Configurar la conexión VPN en el administrador de red
neverdefault(como ya se explicó en OP):nmcli c modify <connectionname> ipv4.never-default yesConfigurar la conexión
dns-searcha los dominios internos del sitio remoto:nmcli c modify <connectionname> ipv4.dns-search <domainname>
Esta opción hace que el administrador de red agregue de alguna manera el servidor DNS run/systemd/resolve/resolv.confnuevamente (agrega, no sobrescribe), a pesar de ipv4.never-defaultestar activo.
Alternativamente, <domainname>se puede reemplazar con ~.lo que provocará una sobrescritura run/systemd/resolve/resolv.confy, por lo tanto, hará que el servidor DNS enviado sea el único que responda a todas las solicitudes de DNS.
Respuesta2
¡Gracias @Valentin!
¡Tu solución es acertada!
En mi caso, usando el cliente Ubuntu 20.04 conectándose al servidor 20.04 y usando las opciones openvpn de gnome-network-manager, no fue necesario configurar dns-search, solo la opción nunca predeterminada.
Para permitir la conectividad de carpeta/red (samba), también tuve que editar la opción "interfaces" en la directiva "Redes" del archivo smb.conf en mi servidor de la siguiente manera
interfaces = 127.0.0.0/8 eth0
interfaces = 127.0.0.0/8 enp2s0
interfaces = X.X.X.X/XX enp2s0
Donde se agregó la última línea donde XXXX/XX es la notación CIDR del rango de direcciones IP que será asignada por el mismo servidor openvpn.