¿Quieres utilizar Linux en el trabajo, pero tu VPN corporativa no te lo permite? Entonces este artículo puede resultar útil, aunque no es seguro. Me gustaría advertirles de antemano que no entiendo bien los temas de administración de red, por lo que es posible que haya hecho todo mal. Por otro lado, es posible que pueda escribir una guía de tal manera que sea comprensible para la gente común, así que te aconsejo que la pruebes.
El artículo contiene mucha información innecesaria, pero sin este conocimiento no habría podido resolver los problemas que me aparecieron inesperadamente al configurar una VPN. Creo que cualquiera que intente utilizar esta guía tendrá problemas que yo no tuve y espero que esta información adicional le ayude a resolver estos problemas por sí solo.
La mayoría de los comandos utilizados en esta guía deben ejecutarse mediante sudo, que se ha eliminado por motivos de brevedad. Tenga en cuenta.
La mayoría de las direcciones IP se han ofuscado gravemente, por lo que si ve una dirección como 435.435.435.435, debe haber alguna IP normal allí, específica para su caso.
Tengo Ubuntu 18.04, pero creo que con cambios menores la guía se puede aplicar a otras distribuciones. Sin embargo, en este texto Linux == Ubuntu.
Cisco Connect
Quienes estén en Windows o MacOS pueden conectarse a nuestra VPN corporativa a través de Cisco Connect, para lo cual deben especificar la dirección de la puerta de enlace y, cada vez que se conectan, ingresar una contraseña que consta de una parte fija y un código generado por Google Authenticator.
En el caso de Linux, no pude ejecutar Cisco Connect, pero logré buscar en Google una recomendación para usar openconnect, creado específicamente para reemplazar Cisco Connect.
Conexión abierta
En teoría, Ubuntu tiene una interfaz gráfica especial para openconnect, pero a mí no me funcionó. Quizás sea para mejor.
En Ubuntu, openconnect se instala desde el administrador de paquetes.
apt install openconnectInmediatamente después de la instalación, puedes intentar conectarte a una VPN.
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com es la dirección de una VPN ficticia
poxvuibr - nombre de usuario ficticio
openconnect le pedirá que introduzca una contraseña que, permítame recordarle, consta de una parte fija y un código de Google Authenticator, y luego intentará conectarse a la VPN. Si funciona, felicidades, puedes saltarte con seguridad el punto medio, que es muy molesto, y pasar al punto sobre la ejecución de openconnect en segundo plano. Si no funciona, entonces puedes continuar. Aunque si funcionó al conectarse, por ejemplo, desde una red Wi-Fi para invitados en el trabajo, entonces puede que sea demasiado pronto para alegrarse, debería intentar repetir el procedimiento desde casa.
Certificado
Existe una alta probabilidad de que no se inicie nada y la salida de openconnect se verá 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 progressPor un lado, esto es desagradable, porque no había conexión a la VPN, pero por otro lado, cómo solucionar este problema está, en principio, claro.
Aquí el servidor nos envió un certificado mediante el cual podemos determinar que la conexión se está realizando al servidor de nuestra corporación nativa, y no a un estafador malvado, y el sistema desconoce este certificado. Y por lo tanto no puede comprobar si el servidor es real o no. Y así, por si acaso, deja de funcionar.
Para que openconnect se conecte al servidor, debe indicarle explícitamente qué certificado debe provenir del servidor VPN usando la clave —servercert
Y puede averiguar qué certificado nos envió el servidor directamente a partir de lo que imprimió openconnect. Esto es 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 progressCon este comando puedes intentar conectarte nuevamente.
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comQuizás ahora esté funcionando y luego puedas continuar hasta el final. Pero personalmente, Ubunta me mostró un higo en 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.comhabr.com lo resolverá, pero no podrás acceder allí. Direcciones como jira.evilcorp.com no se resuelven en absoluto.
Lo que pasó aquí no me queda claro. Pero el experimento muestra que si agrega la línea a /etc/resolv.conf
nameserver 192.168.430.534entonces las direcciones dentro de la VPN comenzarán a resolverse mágicamente y podrá recorrerlas, es decir, lo que DNS busca para resolver direcciones se ve específicamente en /etc/resolv.conf, y no en otro lugar.
Puedes verificar que hay una conexión a la VPN y que funciona sin realizar ningún cambio en /etc/resolv.conf; para hacer esto, simplemente ingresa en el navegador no el nombre simbólico del recurso de la VPN, sino su dirección IP.
Como resultado, hay dos problemas
- Al conectarse a una VPN, no se detecta su DNS
- todo el tráfico pasa a través de VPN, que no permite el acceso a Internet
Te diré qué hacer ahora, pero primero un poco de automatización.
Entrada automática de la parte fija de la contraseña.
A estas alturas, lo más probable es que ya hayas ingresado tu contraseña al menos cinco veces y este procedimiento ya te haya cansado. En primer lugar, porque la contraseña es larga, y en segundo lugar, porque al ingresar es necesario ajustarse a un período de tiempo fijo.
La solución final al problema no se incluyó en el artículo, pero puede asegurarse de que no sea necesario ingresar la parte fija de la contraseña muchas veces.
Supongamos que la parte fija de la contraseña es Contraseña fija y la parte de Google Authenticator es 567 987. La contraseña completa se puede pasar a openconnect mediante la entrada estándar utilizando el argumento --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinAhora puede volver constantemente al último comando ingresado y cambiar allí solo una parte de Google Authenticator.
Una VPN corporativa no te permite navegar por Internet.
En general, no es muy inconveniente cuando tienes que usar una computadora separada para ir a Habr. La imposibilidad de copiar y pegar desde stackoverfow generalmente puede paralizar el trabajo, por lo que es necesario hacer algo.
Necesitamos organizarlo de alguna manera para que cuando necesites acceder a un recurso desde la red interna, Linux vaya a la VPN, y cuando necesites ir a Habr, 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 pasan al script como entrada y éste configura la VPN. Desafortunadamente, no pude descubrir cómo dividir los flujos de tráfico entre una VPN corporativa y el resto de Internet usando un script nativo.
Aparentemente, la utilidad vpn-slice fue desarrollada especialmente para personas como yo, que le permite enviar tráfico a través de dos canales sin bailar con una pandereta. Bueno, es decir, tendrás que bailar, pero no hace falta ser chamán.
Separación de tráfico mediante vpn-slice
En primer lugar, tendrás que instalar vpn-slice, tendrás que resolverlo tú mismo. Si hay preguntas en los comentarios, escribiré una publicación separada sobre esto. Pero este es un programa Python normal, por lo que no debería haber ninguna dificultad. Lo instalé usando virtualenv.
Y luego se debe aplicar la utilidad, usando el interruptor -script, indicando a openconnect que en lugar del script estándar, debe 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 A --script se le pasa una cadena con un comando que debe llamarse en lugar del script. ./bin/vpn-slice - ruta al archivo ejecutable vpn-slice 192.168.430.0/24 - máscara de direcciones a las que ir en vpn. Aquí queremos decir que si la dirección comienza con 192.168.430, entonces el recurso con esta dirección debe buscarse dentro de la VPN.
La situación debería ser ahora casi normal. Casi. Ahora puede ir a Habr y puede ir al recurso intracorporativo por ip, pero no puede ir al recurso intracorporativo por nombre simbólico. Si especifica una coincidencia entre el nombre simbólico y la dirección en los hosts, todo debería funcionar. Y trabaje hasta que cambie la ip. Linux ahora puede acceder a Internet o a la intranet, según la IP. Pero todavía se utiliza DNS no corporativo para determinar la dirección.
El problema también puede manifestarse de esta forma: en el trabajo todo está bien, pero en casa solo se puede acceder a los recursos internos de la empresa a través de IP. Esto se debe a que cuando está conectado a una red Wi-Fi corporativa, también se utiliza el DNS corporativo y en él se resuelven las direcciones simbólicas de la VPN, a pesar de que todavía es imposible acceder a dicha dirección sin utilizar una VPN.
Modificación automática del archivo de hosts.
Si se le pregunta cortésmente a vpn-slice, luego de activar la VPN, puede ir a su DNS, encontrar allí las direcciones IP de los recursos necesarios por sus nombres simbólicos e ingresarlas en los hosts. Después de apagar la VPN, estas direcciones se eliminarán de los hosts. Para hacer esto, necesita pasar nombres simbólicos a vpn-slice como argumentos. Como esto.
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 las direcciones de todos los subdominios en el DNS proporcionado por la VPN
Si hay pocas direcciones dentro de la red, entonces el método de modificar automáticamente el archivo de hosts funciona bastante bien. Pero si hay muchos recursos en la red, entonces necesitarás agregar constantemente líneas como zoidberg.test.evilcorp.com al script. zoidberg es el nombre de uno de los bancos de pruebas.
Pero ahora que entendemos un poco por qué se puede eliminar esta necesidad.
Si, después de activar la VPN, buscas en /etc/hosts, puedes ver esta línea
192.168.430.534 dns0.tun0 # vpn-slice-tun0 CREADO AUTOMÁTICAMENTE
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 la VPN.
Ahora debemos asegurarnos de que para averiguar la dirección IP de un nombre de dominio que termina en evilcorp.com, Linux vaya al DNS corporativo y, si se necesita algo más, al predeterminado.
Busqué en Google durante bastante tiempo y descubrí que dicha funcionalidad está disponible en Ubuntu de forma inmediata. Esto significa la posibilidad de utilizar el servidor DNS local dnsmasq para resolver nombres.
Es decir, puedes asegurarte de que Linux siempre vaya al servidor DNS local en busca de direcciones IP, que a su vez, dependiendo del nombre de dominio, buscará la IP en el servidor DNS externo correspondiente.
Para gestionar todo lo relacionado con las redes y las conexiones de red, Ubuntu utiliza NetworkManager, y la interfaz gráfica para seleccionar, por ejemplo, conexiones Wi-Fi es sólo una interfaz.
Necesitaremos escalar en su configuración.
- Cree un archivo en /etc/NetworkManager/dnsmasq.d/evilcorp
dirección=/.evilcorp.com/192.168.430.534
Presta atención al punto frente a evilcorp. Le indica a dnsmasq que todos los subdominios de evilcorp.com deben buscarse en el dns corporativo.
- Dígale a NetworkManager que use dnsmasq para la resolución de 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 restartAhora, después de conectarse a una VPN usando openconnect y vpn-slice, la IP se determinará normalmente, incluso si no agrega direcciones simbólicas a los argumentos de vpnslice.
Cómo acceder a servicios individuales a través de VPN
Después de que logré conectarme a la VPN, estuve muy feliz durante dos días, y luego resultó que si me conecto a la VPN desde fuera de la red de la oficina, el correo no funciona. El síntoma me resulta familiar, ¿no?
Nuestro correo se encuentra en mail.publicevilcorp.com, lo que significa que no está bajo la regla dnsmasq y la dirección del servidor de correo se busca a través de DNS público.
Bueno, la oficina todavía usa DNS, que contiene esta dirección. Eso es lo que pense. De hecho, después de agregar la línea a dnsmasq
dirección=/mail.publicevilcorp.com/192.168.430.534
la situación no ha cambiado en absoluto. La IP siguió siendo la misma. Tuve que ir a trabajar.
Y sólo más tarde, cuando profundicé en la situación y entendí un poco el problema, una persona inteligente me dijo cómo solucionarlo. Era necesario conectarse al servidor de correo no así, sino a través de VPN.
Utilizo vpn-slice para pasar por la VPN a direcciones que comienzan con 192.168.430. Y el servidor de correo no sólo tiene una dirección simbólica que no es un subdominio de evilcorp, sino que tampoco tiene una dirección IP que comience con 192.168.430. Y por supuesto no permite que nadie de la red general se acerque a él.
Para que Linux pase a través de la VPN y al servidor de correo, también debe agregarlo a vpn-slice. Digamos 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 VPN con un argumento
Todo esto, por supuesto, no es muy conveniente. Sí, puedes guardar el texto en un archivo y copiarlo y pegarlo en la consola en lugar de escribirlo a mano, pero aún así no es muy agradable. Para facilitar el proceso, puede incluir el comando en un script que se ubicará en PATH. Y luego solo necesitarás ingresar el código recibido 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 simplemente escribir en la consola
connect_evil_corp 567987Pero ahora todavía tienes que mantener abierta la consola en la que se ejecuta openconnect por algún motivo.
Ejecutando openconnect en segundo plano
Afortunadamente, los autores de openconnect nos cuidaron y agregaron una clave especial al programa: background, que hace que el programa funcione en segundo plano después del lanzamiento. Si lo ejecuta así, puede cerrar la consola después del inicio.
#!/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 simplemente no está claro adónde van los registros. En general, no necesitamos registros, pero nunca se sabe. openconnect puede redirigirlos a syslog, donde se mantendrán seguros y protegidos. necesita agregar el modificador –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 Y entonces resulta que openconnect está funcionando en algún lugar en segundo plano y no molesta a nadie, pero no está claro cómo detenerlo. Es decir, puedes, por supuesto, filtrar la salida de ps usando grep y buscar un proceso cuyo nombre contenga openconnect, pero esto es algo tedioso. Gracias a los autores que también pensaron en esto. Openconnect tiene una clave -pid-file, con la que puede indicarle a openconnect que escriba su identificador 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-pidAhora siempre puedes matar un proceso con el comando
kill $(cat ~/vpn-pid)Si no hay ningún proceso, matar maldecirá, pero no arrojará un error. Si el archivo no está allí, tampoco sucederá nada malo, por lo que puede finalizar 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-pidAhora puedes encender tu computadora, abrir la consola y ejecutar el comando, pasándole el código de Google Authenticator. Luego se puede clavar la consola.
Sin segmento VPN. En lugar de un epílogo
Resultó muy difícil entender cómo vivir sin una VPN. Tuve que leer y buscar mucho en Google. Afortunadamente, después de pasar tanto tiempo con un problema, los manuales técnicos e incluso man openconnect se leen como novelas apasionantes.
Como resultado, descubrí que vpn-slice, al igual que el script nativo, modifica la tabla de enrutamiento para separar redes.
Tabla de ruteo
En pocas palabras, esta es una tabla en la primera columna que contiene con qué dirección debe comenzar Linux y en la segunda columna qué adaptador de red debe usar en esta dirección. De hecho, hay más ponentes, 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 debe 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 qué es una máscara de dirección IP. Después de dev está el nombre del adaptador al que se debe enviar el mensaje.
Para VPN, Linux creó un adaptador virtual: tun0. La línea garantiza que el tráfico de todas las direcciones que comienzan con 192.168 pase por ella.
192.168.0.0/16 dev tun0 scope link También puede ver el estado actual de la tabla de enrutamiento usando el comando ruta -n (Las direcciones IP se anonimizan inteligentemente) Este comando produce resultados en una forma diferente y generalmente está en desuso, pero su resultado a menudo se encuentra en manuales en Internet y es necesario poder leerlo.
Se puede entender dónde debe comenzar la dirección IP de una ruta a partir de la combinación de las columnas Destino y Genmask. Se tienen en cuenta aquellas partes de la dirección IP que corresponden a los números 255 en Genmask, pero no aquellas donde hay 0. Es decir, la combinación de Destino 192.168.0.0 y Genmask 255.255.255.0 significa que si la dirección comienza con 192.168.0, la solicitud irá por esta ruta. Y si el destino es 192.168.0.0 pero Genmask 255.255.0.0, las solicitudes a direcciones que comienzan con 192.168 seguirán esta ruta
Para descubrir qué hace realmente vpn-slice, decidí mirar los estados 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 wlp3s0Después de llamar a openconnect sin vpn-slice se volvió así
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 tun0Y 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 tun0Se puede ver que si no usa vpn-slice, openconnect escribe explícitamente que se debe acceder a todas las direcciones, excepto las indicadas específicamente, a través de vpn.
Aquí está:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Allí, al lado, se indica inmediatamente otra ruta, que se debe utilizar si la dirección por la que intenta pasar Linux 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 wlp3s0Ya está escrito aquí que en este caso es necesario utilizar un adaptador Wi-Fi estándar.
Creo que se utiliza la ruta VPN 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 defaultY todo funcionó.
Enrutar 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, al que también es necesario acceder a través de VPN. La ruta hacia él también debe agregarse manualmente.
ip route add 555.555.555.555 via dev tun0Y ahora todo está bien. Así que puedes prescindir de vpn-slice, pero necesitas saber bien lo que estás haciendo. Ahora estoy pensando en agregar a la última línea del script nativo de openconnect la eliminación de la ruta predeterminada y agregar una ruta para el correo después de conectarme a la VPN, solo para que haya menos partes móviles en mi bicicleta.
Probablemente, este epílogo sería suficiente para que alguien entienda cómo configurar una VPN. Pero mientras intentaba entender qué y cómo hacer, leí muchas guías que funcionan para el autor, pero que por alguna razón no funcionan para mí, y decidí agregar aquí todas las piezas que encontré. Estaría muy feliz con algo así.
Fuente: habr.com