¿Quiere usar Linux en el trabajo, pero una VPN corporativa no? Entonces este artículo puede ayudar, aunque esto no es exacto. Quiero advertir de antemano que entiendo mal los problemas de la administración de la red, por lo que es posible que haya hecho todo mal. Por otro lado, es posible que pueda escribir el manual de manera que sea comprensible para la gente común, por lo que le aconsejo que lo pruebe.
El artículo tiene mucha información adicional, pero sin este conocimiento no podría resolver los problemas que tuve repentinamente con la configuración de vpn. Creo que cualquiera que intente aplicar este manual tendrá problemas que yo no tuve, y espero que esta información adicional me ayude a resolver estos problemas.
La mayoría de los comandos utilizados en el manual deben ejecutarse a través de sudo, que se elimina por brevedad. Tener en cuenta.
La mayoría de las direcciones IP se ofuscaron severamente, por lo que si ve una dirección como 435.435.435.435, debería haber alguna IP normal específica para su caso.
Tengo Ubuntu 18.04, pero creo que con algunos cambios la guía se puede aplicar a otras distribuciones. Sin embargo, en este texto, Linux == Ubuntu.
Cisco connect
Aquellos que están sentados en Windows o MacOS pueden conectarse a nuestra VPN corporativa a través de Cisco Connect, que necesita especificar la dirección de la puerta de enlace e ingresar una contraseña cada vez que se conecta, que consta de una parte fija y un código generado por Google Authenticator.
En el caso de Linux, no fue posible obtener Cisco Connect, pero resultó en Google la recomendación de usar openconnect, hecho específicamente para reemplazar Cisco Connect.
Openconnect
En teoría, en ubunt hay una interfaz gráfica especial para openconnect, pero no funcionó para mí. Quizás sea lo mejor.
En ubunt openconnect se instala desde el administrador de paquetes.
apt install openconnect
Inmediatamente después de la instalación, puede intentar conectarse a la VPN
openconnect --user poxvuibr vpn.evilcorp.com
vpn.evilcorp.com es la dirección VPN ficticia \
poxvuibr - nombre de usuario ficticio
openconnect le pedirá que ingrese una contraseña, que, según recuerdo, consiste en una parte fija y un código de Google Authenticator, y luego intenta conectarse a vpn. Si resultó, felicidades, puedes saltarte el medio de forma segura, lo cual es muy doloroso y llegar al punto sobre la conexión abierta en el fondo. Si no funciona, puede continuar. Aunque si resultó al conectarse, por ejemplo, desde un Wi-Fi de invitado en el trabajo, es posible alegrarse y temprano, debe intentar repetir el procedimiento desde su casa.
Certificado
Con alta probabilidad, nada comenzará, y el escape de conexión abierta se verá más o menos así:
POST https://vpn.evilcorp.com/ Connected to 777.777.777.777:443 SSL negotiation with vpn.evilcorp.com Server certificate verify failed: signer not found Certificate from VPN server "vpn.evilcorp.com" failed verification. Reason: signer not found To trust this server in future, perhaps add this to your command line: --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 Enter 'yes' to accept, 'no' to abort; anything else to view: fgets (stdin): Operation now in progress
Por un lado, esto es desagradable, porque no había conexión con la VPN, pero por otro lado, en principio, es comprensible cómo solucionar este problema.
Luego, el servidor nos envió un certificado, según el cual se puede determinar que la conexión se realiza con el servidor de la corporación nativa, y no con el estafador malicioso, y este certificado es desconocido para el sistema. Y entonces ella no puede verificar si el servidor real es o no. Y así, por si acaso, deja de funcionar.
Para que Openconnect todavía se conecte al servidor, debe indicarle explícitamente qué certificado debe provenir del servidor VPN utilizando la clave --servercert
Y puede averiguar qué certificado nos envió el servidor directamente desde qué conexión abierta imprimió. Aquí de esta pieza:
To trust this server in future, perhaps add this to your command line: --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 Enter 'yes' to accept, 'no' to abort; anything else to view: fgets (stdin): Operation now in progress
Con este comando puedes intentar conectarte nuevamente
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com
Tal vez esté funcionando ahora, entonces puedes ir al final. Pero Ubunta personalmente me mostró un higo de esta forma
POST https://vpn.evilcorp.com/ Connected to 777.777.777.777:443 SSL negotiation with vpn.evilcorp.com Server certificate verify failed: signer not found Connected to HTTPS on vpn.evilcorp.com XML POST enabled Please enter your username and password. POST https://vpn.evilcorp.com/ Got CONNECT response: HTTP/1.1 200 OK CSTP connected. DPD 300, Keepalive 30 Set up DTLS failed; using SSL instead Connected as 192.168.333.222, using SSL NOSSSSSHHHHHHHDDDDD 3 NOSSSSSHHHHHHHDDDDD 3 RTNETLINK answers: File exists /etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf
/etc/resolv.conf
# Generated by NetworkManager search gst.evilcorpguest.com nameserver 127.0.0.53
/run/resolvconf/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. nameserver 192.168.430.534 nameserver 127.0.0.53 search evilcorp.com gst.publicevilcorp.com
habr.com se resolverá, pero no será posible ingresar allí. Las direcciones como jira.evilcorp.com no se resuelven en absoluto.
Lo que sucedió aquí no está claro para mí. Pero el experimento muestra que si agrega la línea a /etc/resolv.conf
nameserver 192.168.430.534
entonces las direcciones dentro de la VPN se resolverán mágicamente y será posible revisarlas, es decir, lo que DNS busca para resolver direcciones se ve en /etc/resolv.conf, y no en otro lugar.
Que hay una conexión a la VPN y funciona, puede asegurarse sin cambios en /etc/resolv.conf, para esto es suficiente ingresar en el navegador no el nombre simbólico del recurso de vpn, sino su dirección IP
El resultado son dos problemas.
- en la conexión a VPN su dns no se recoge
- todo el tráfico pasa por vpn, lo que no le permite ir a Internet
Lo que haré ahora te lo diré, pero primero un poco de automatización.
Entrada automática de la parte fija de la contraseña.
En el momento actual, lo más probable es que ya haya ingresado la contraseña al menos cinco veces y este procedimiento ya lo ha cansado bastante. En primer lugar, porque la contraseña es larga, y en segundo lugar, porque al ingresar, debe mantenerla dentro de un período de tiempo fijo
La solución final al problema no se incluyó en el artículo, pero se puede hacer para que la parte fija de la contraseña no tenga que ingresarse muchas veces.
Suponga que la parte fija de la contraseña es fixedPassword y parte de Google Authenticator 567 987. La contraseña completa de openconnect se puede pasar a través de la entrada estándar utilizando el argumento --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdin
Ahora puede volver constantemente al último comando ingresado y cambiar solo una parte de Google Authenticator allí.
La VPN corporativa no permite el acceso a Internet.
En general, no es muy inconveniente cuando para ir a un centro debe usar una computadora separada. La falta de la capacidad de copiar y pegar con stackoverfow generalmente puede paralizar el trabajo, por lo que hay que hacer algo.
Es necesario organizarse de alguna manera, de modo que cuando necesite ir al recurso desde la red interna, Linux vaya a vpn, y cuando necesite ir al concentrador, vaya a Internet.
openconnect después de iniciar y establecer una conexión con vpn, ejecuta un script especial, que se encuentra en / usr / share / vpnc-scripts / vpnc-script. Algunas variables se transfieren al script de entrada, y realiza la configuración vpn. Desafortunadamente, no pude descubrir cómo dividir los flujos de tráfico entre la VPN corporativa y el resto de Internet utilizando un script nativo.
Aparentemente especialmente para personas como yo, se desarrolló la utilidad vpn-slice, que le permite dirigir el tráfico a través de dos canales sin bailar con una pandereta. Bueno, es decir, tienes que bailar, pero no es necesario un chamán.
Dividir el tráfico con vpn-slice
En primer lugar, tendrá que instalar vpn-slice, deberá resolverlo usted mismo. Si hay preguntas en los comentarios, escribiré una publicación separada sobre esto. Pero este es un programa de Python regular, por lo que no debería haber dificultades. Lo configuré usando virtualenv.
Y luego necesita usar la utilidad, usando la tecla --script que indica openconnect que en lugar del script estándar necesita usar vpn-slice
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin \ --script "./bin/vpn-slice 192.168.430.0/24 " vpn.evilcorp.com
En --script, se pasa una línea con el comando a llamar en lugar del script. ./bin/vpn-slice: ruta al archivo ejecutable vpn-slice 192.168.430.0/24: máscara de direcciones que se visitarán en vpn. Aquí, quiero decir que si la dirección comienza con 192.168.430, entonces el recurso con esta dirección debe buscarse dentro de vpn
Ahora la situación debería ser casi normal. Casi. Ahora puede iniciar sesión en el concentrador y puede iniciar sesión en el recurso corporativo interno por ip, pero no puede iniciar sesión en el recurso corporativo interno por nombre simbólico. Si registra la correspondencia del nombre simbólico y la dirección en los hosts, todo debería funcionar. Y trabajar hasta que cambie la ip. Linux ahora puede ir a Internet o a la red corporativa, dependiendo de la ip. Pero el DNS no corporativo todavía se usa para determinar la dirección.
El problema aún puede manifestarse de esta forma: todo está bien en el trabajo y en el hogar puede acceder a los recursos corporativos internos solo por ip. Esto se debe a que cuando está conectado al Wi-Fi corporativo, también se usa el DNS corporativo, y en él se resuelven las direcciones simbólicas de la VPN, aunque todavía es imposible acceder a dicha dirección sin usar una VPN.
Modificación automática del archivo de hosts.
Si pregunta cortésmente vpn-slice, luego de elevar la VPN, puede ir a su DNS, encontrar las direcciones IP de los recursos necesarios allí por sus nombres simbólicos e ingresarlos en los hosts. Una vez que se apaga la VPN, estas direcciones se eliminarán de los hosts. Para hacer esto, pase nombres simbólicos a vpn-slice como argumentos. Ahí tienes.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin --script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com
Ahora todo debería funcionar tanto en la oficina como en la playa.
Busque direcciones de todos los subdominios en el DNS que le dio la VPN
Si hay pocas direcciones dentro de la red, entonces el enfoque de modificar automáticamente el archivo de hosts está funcionando bastante bien. Pero si hay muchos recursos en la red, deberá agregar constantemente líneas como zoidberg.test.evilcorp.com al script zoidberg, este es el nombre de uno de los bancos de pruebas.
Pero ahora que tenemos una pequeña comprensión de por qué esta necesidad puede ser eliminada.
Si, después de subir la VPN, mira en / etc / hosts, puedes ver, aquí hay una línea
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREADO
Sí, y se agregó una nueva línea a resolv.conf. En resumen, vpn-slice de alguna manera determinó dónde se encuentra el servidor dns para vpn.
Ahora debemos asegurarnos de que para averiguar la dirección IP del nombre de dominio que termina en evilcorp.com, Linux fue a dns corporativos, y si se necesita algo más, entonces a los valores predeterminados.
Busqué en Google durante mucho tiempo y descubrí que dicha funcionalidad está fuera de la caja. Esto se refiere a la capacidad de usar el servidor local dns dnsmasq para resolver nombres.
Es decir, puede hacer que Linux siempre vaya al servidor DNS local para obtener direcciones IP, que a su vez, dependiendo del nombre de dominio, buscarán IP en el servidor DNS externo correspondiente.
Para administrar todo lo relacionado con las redes y las conexiones de red, Ubunt usa NetworkManager, y la interfaz gráfica para seleccionar, por ejemplo, una conexión Wi-Fi está al frente.
Tendremos que subir en su configuración.
- Crear archivo en /etc/NetworkManager/dnsmasq.d/evilcorp
dirección = /. evilcorp.com/192.168.430.534
Presta atención al punto antes de evilcorp. Indica a dnsmasq que todos los subdominios de evilcorp.com deben buscarse en el dns corporativo.
- Indique a NetworkManager que use dnsmasq para resolver nombres
La configuración del administrador de red se encuentra en /etc/NetworkManager/NetworkManager.conf Debe agregar allí:
[principal]
dns = dnsmasq
- Reiniciar NetworkManager
service network-manager restart
Ahora, después de conectarse a una VPN usando un montón de openconnect y vpn-slice, ip se detectará normalmente incluso si no agrega direcciones simbólicas a los argumentos de vpnslice.
Cómo pasar por VPN para separar servicios
Después de que se conectó a vpn, estuve muy contento durante dos días, y luego resultó que si se conecta a VPN no desde la red de la oficina, el correo no funciona. Un síntoma familiar, ¿no?
Nuestro correo está en mail.publicevilcorp.com, lo que significa que no está incluido en la regla en dnsmasq y la dirección del servidor de correo se busca a través del DNS público.
Bueno, la oficina todavía usa el DNS en el que se encuentra esta dirección. Es decir, eso pensé. De hecho, después de agregar una línea a dnsmasq
dirección = / mail.publicevilcorp.com / 192.168.430.534
La situación no ha cambiado. ip se mantuvo igual. Tuve que ir a trabajar.
Y solo entonces, cuando profundicé en la situación y resolví un poco el problema, una persona inteligente me dijo cómo resolverlo. Era necesario conectarse al servidor de correo no solo así, sino a través de VPN
Utilizo vpn-slice para pasar por la VPN a direcciones que comienzan con 192.168.430. Y en el servidor de correo, no solo la dirección simbólica no es un subdominio de evilcorp, también tiene una dirección IP que no comienza con 192.168.430. Y, por supuesto, no deja salir a nadie de la red general.
Para que Linux pase por la VPN y el servidor de correo, debe agregarlo a vpn-slice. Supongamos que la dirección del remitente es 555.555.555.555
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin --script "./bin/vpn-slice 555.555.555.555 192.168.430.0/24" vpn.evilcorp.com
Script para generar una VPN con un argumento
Todo esto, por supuesto, no es muy conveniente. Sí, puede guardar el texto en un archivo y copiarlo y pegarlo en la consola, en lugar de escribir con las manos, pero aún no es lo suficientemente agradable. Para facilitar el proceso, puede ajustar el comando en un script que se ubicará en PATH. Y luego solo necesita ingresar el código obtenido de Google Authenticator
#!/bin/sh echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin \ --script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com
Si pones el script en connect ~ evilcorp ~ puedes escribir en la consola
connect_evil_corp 567987
Pero ahora, de todos modos, por alguna razón, debe mantener abierta la consola en la que OpenConnect se ejecuta
Lanzamiento de Openconnect en segundo plano
Afortunadamente, los autores de openconnect se encargaron de nosotros y agregaron una clave especial: el fondo del programa, lo que hace que el programa funcione en segundo plano después del lanzamiento. Si lo ejecuta de esta manera, luego del inicio puede cerrar la consola
#!/bin/sh echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 \ --user poxvuibr \ --passwd-on-stdin \ --background \ --script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com
Ahora no está claro a dónde van los registros. Los registros generalmente no son realmente necesarios para nosotros, pero nunca se sabe. openconnect puede redirigirlos a syslog, donde se mantendrán intactos. necesita agregar la tecla --syslog al comando
#!/bin/sh echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 \ --user poxvuibr \ --passwd-on-stdin \ --background \ --syslog \ --script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com \
Entonces, resulta que openconnect funciona en algún lugar en segundo plano y no molesta a nadie, pero no está claro cómo detenerlo. Es decir, puede, por supuesto, filtrar el escape ps con un grep y buscar un proceso en cuyo nombre se encuentre openconnect, pero de alguna manera es triste. Gracias a los autores que pensaron en esto. Openconnect tiene la clave --pid-file, con la que puede indicar a openconnect que escriba su ID de proceso en un archivo.
#!/bin/sh echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 \ --user poxvuibr \ --passwd-on-stdin \ --background \ --syslog \ --script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com \ --pid-file ~/vpn-pid
Ahora siempre puedes clavar el proceso con el comando
kill $(cat ~/vpn-pid)
Si no hay ningún proceso, kill jurará, pero no arrojará un error. Si no hay ningún archivo, tampoco sucederá nada malo, por lo que puede eliminar el proceso de forma segura en la primera línea del script.
kill $(cat ~/vpn-pid) #!/bin/sh echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 \ --user poxvuibr \ --passwd-on-stdin \ --background \ --syslog \ --script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com \ --pid-file ~/vpn-pid
Ahora puede encender la computadora, abrir la consola y ejecutar el comando, pasándole el código de Google Authenticator. La consola puede ser clavada.
Sin vpn-slice. En lugar de un epílogo
Fue muy difícil entender cómo vivir sin vpn-slice. Tuve que leer mucho y googlear. Afortunadamente, cuando pasé tanto tiempo con el problema, los manuales técnicos e incluso el hombre abierto leyeron como novelas emocionantes.
Como resultado, descubrí que vpn-slice, como el script nativo, modifica la tabla de enrutamiento para separar las redes.
Tabla de enrutamiento
En términos simples, dicha tabla en la primera columna de la cual contiene dónde debe comenzar la dirección a la que quiere ir Linux, y en la segunda a través de qué adaptador de red ir a esta dirección. De hecho, hay más columnas, pero esto no cambia la esencia.
Para ver la tabla de enrutamiento, debe ejecutar el comando ip route
default via 192.168.1.1 dev wlp3s0 proto dhcp metric 600 192.168.430.0/24 dev tun0 scope link 192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.534 metric 600 192.168.430.534 dev tun0 scope link
Aquí, cada línea es responsable de dónde ir para enviar un mensaje a alguna dirección. La primera es una descripción de dónde debe comenzar la dirección. Para comprender cómo determinar que 192.168.0.0/16 significa que la dirección debe comenzar con 192.168, debe buscar en Google cuál es la máscara de la dirección IP. Después de dev es el nombre del adaptador al que se debe enviar el mensaje.
Para VPN, Linux creó un adaptador virtual: tun0. Para que el tráfico de todas las direcciones que comienzan con 192.168 lo atraviesen, la línea responde
192.168.0.0/16 dev tun0 scope link
También puede ver el estado actual de la tabla de enrutamiento utilizando el comando route -n (las direcciones IP son anónimamente talentosas) Este comando produce resultados en una forma diferente y en general está en desuso, pero su escape a menudo se encuentra en los manuales en línea y necesita poder leerlo.
La dirección IP de la ruta debe comenzar por la combinación de las columnas Destino y Genmask. Se tienen en cuenta aquellas partes de la dirección IP a las que corresponden los números 255 en Genmask, y aquellas en las que 0 no lo es. Es decir, la combinación de Destination 192.168.0.0 y Genmask 255.255.255.0 significa que si la dirección comienza con 192.168.0, entonces una solicitud irá por esta ruta. Y si el Destino es 192.168.0.0 pero Genmask es 255.255.0.0, las solicitudes a direcciones que comiencen con 192.168 irán por esta ruta
Para averiguar qué hace realmente vpn-slice, decidí mirar el estado de las tablas antes y después
Antes de encender la VPN, era así
route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0 222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0 333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0
Después de llamar a openconnect sin vpn-slice se volvió tan
route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0 0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0 222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0 333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0 192.168.430.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 192.168.430.534 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
Y después de llamar a openconnect en combinación con vpn-slice como este
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0 222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0 333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0 192.168.430.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 192.168.430.534 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
Se puede ver que si no usa vpn-slice, openconnect escribe explícitamente que debe pasar por vpn a todas las direcciones, excepto que se indique por separado.
Aquí:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0
Cerca de allí, inmediatamente se indicó otra ruta que debería usarse si la dirección por la que Linux intenta pasar no coincide con ninguna máscara de la tabla.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0
Ya se ha escrito aquí que, en este caso, debe pasar por el adaptador Wi-Fi estándar.
Creo que la ruta para la VPN se usa porque es la primera en la tabla de enrutamiento.
Y, en teoría, si elimina esta ruta predeterminada de la tabla de enrutamiento, junto con dnsmasq openconnect debería garantizar un funcionamiento normal.
Lo intenté
route del default
Y funcionó.
Enrutamiento de solicitudes a un servidor de correo sin vpn-slice
Pero también tengo un servidor de correo con la dirección 555.555.555.555, que también debe pasar por vpn. La ruta a ella también debe agregarse a mano.
ip route add 555.555.555.555 via dev tun0
Y ahora todas las reglas. Entonces puede prescindir de vpn-slice, pero ya necesita saber bien lo que está haciendo. Ahora estoy pensando en agregar la eliminación de la ruta predeterminada y agregar la ruta para el correo después de conectarme a vpn a la última línea del script nativo openconnect, solo para reducir el número de partes móviles en mi bicicleta.
Probablemente, alguien con el fin de comprender cómo configurar una VPN tendría suficiente de este epílogo. Pero mientras intentaba entender qué y cómo hacerlo, leí muchos de esos manuales que funcionan para el autor, pero por alguna razón no funcionan para mí y decidí agregar aquí todas las piezas que encontré. Estaría muy feliz con algo así.