¿Quieres usar Linux en el trabajo, pero la VPN corporativa no lo permite? Entonces este artículo puede ayudar, aunque no es seguro. Quiero advertir de antemano que no tengo mucho conocimiento en la administración de redes, así que no se puede descartar que lo haya hecho todo incorrectamente. Por otro lado, es posible que pueda escribir una guía que sea comprensible para personas comunes, así que te aconsejo que lo intentes.
El artículo contiene mucha información innecesaria, pero sin este conocimiento no habría podido resolver problemas inesperados que surgieron al configurar la VPN. Creo que cualquiera que intente aplicar esta guía encontrará problemas que yo no tuve, y espero que esta información adicional ayude a resolver esos problemas de forma autónoma.
La mayoría de los comandos utilizados en la guía deben ejecutarse a través de sudo, que se ha omitido por brevedad. Tenlo en cuenta.
La mayoría de las direcciones IP han sido severamente ofuscadas, así que si ves una dirección como 435.435.435.435, debería haber alguna dirección IP normal, específica para tu caso.
Tengo Ubuntu 18.04, pero creo que con algunas modificaciones la guía se puede aplicar a otras distribuciones. Sin embargo, en este texto, linux == Ubuntu.
Cisco Connect
Aquellos que usan Windows o MacOS pueden conectarse a nuestra VPN corporativa a través de Cisco Connect, al que se le debe indicar la dirección del gateway y, en cada conexión, ingresar una contraseña compuesta por una parte fija y un código generado por Google Authenticator.
En el caso de Linux, no pude hacer funcionar Cisco Connect, pero encontré la recomendación de usar openconnect, diseñado específicamente para reemplazar Cisco Connect.
Openconnect
Teóricamente, en Ubuntu hay una interfaz gráfica especial para openconnect, pero no funcionó para mí. Quizás sea para mejor.
En Ubuntu, openconnect se instala desde el gestor de paquetes.
apt install openconnectJusto después de la instalación, puedes intentar conectarte a la VPN.
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com es la dirección de una VPN ficticia.
poxvuibr es un nombre de usuario ficticio.
openconnect le pedirá que ingrese una contraseña, que, como recordatorio, consta de una parte fija y un código de Google Authenticator, y luego intentará conectarse a la VPN. Si tuvo éxito, ¡felicitaciones! Puede saltarse la parte intermedia donde hay mucho dolor y pasar al punto sobre cómo funciona openconnect en segundo plano. Si no funcionó, aún se puede continuar. Aunque si tuvo éxito al conectarse, por ejemplo, desde una red Wi-Fi pública en el trabajo, puede ser prematuro celebrar, debería intentar repetir el procedimiento desde casa.
Certificado
Con alta probabilidad, nada se iniciará, y la salida de openconnect se verá algo así:
POST https://vpn.evilcorp.com/
Conectado a 777.777.777.777:443
Negociación SSL con vpn.evilcorp.com
La verificación del certificado del servidor falló: firmante no encontrado
El certificado del servidor VPN "vpn.evilcorp.com" falló la verificación.
Razón: firmante no encontrado
Para confiar en este servidor en el futuro, quizás añada esto a su línea de comandos:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Ingrese 'yes' para aceptar, 'no' para abortar; cualquier otra cosa para ver: fgets (stdin): Operación ahora en progresoPor un lado, esto es desagradable porque no se estableció la conexión VPN, pero por otro lado, cómo solucionar este problema es bastante claro.
Aquí el servidor nos envió un certificado, por el cual se puede determinar que la conexión se realiza precisamente al servidor de la corporación original y no a un malintencionado, pero este certificado es desconocido para el sistema. Por lo tanto, no puede verificar si el servidor es legítimo o no. Y por precaución, deja de funcionar.
Para que openconnect aún se conecte al servidor, es necesario decirle explícitamente qué certificado debe recibir del servidor VPN usando la clave —servercert
Y para saber qué certificado nos envió el servidor, podemos tomarlo directamente de lo que escribió openconnect. Aquí de este fragmento:
Para confiar en este servidor en el futuro, quizás añada esto a su línea de comandos:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Ingrese 'yes' para aceptar, 'no' para abortar; cualquier otra cosa para ver: fgets (stdin): Operación ahora en progresoCon este comando, se puede intentar conectarse de nuevo
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comEs posible que ahora funcione, así que se puede pasar al final. Pero personalmente, Ubuntu me mostró lo contrario en esta forma
POST https://vpn.evilcorp.com/
Conectado a 777.777.777.777:443
Negociación SSL con vpn.evilcorp.com
Fallo al verificar el certificado del servidor: firmante no encontrado
Conectado a HTTPS en vpn.evilcorp.com
XML POST habilitado
Por favor, introduce tu nombre de usuario y contraseña.
POST https://vpn.evilcorp.com/
Respuesta CONNECT recibida: HTTP/1.1 200 OK
CSTP conectado. DPD 300, Keepalive 30
Configuración de DTLS fallida; utilizando SSL en su lugar
Conectado como 192.168.333.222, utilizando SSL
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
RTNETLINK responde: El archivo existe
/etc/resolvconf/update.d/libc: Advertencia: /etc/resolv.conf no es un enlace simbólico a /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 se resolverá, pero no se podrá acceder a él. Direcciones como jira.evilcorp.com ni siquiera se resuelven.
No entiendo qué ha sucedido aquí. Pero el experimento muestra que si se añade la línea a /etc/resolv.conf
nameserver 192.168.430.534las direcciones dentro de la VPN comenzarán a resolverse mágicamente y se podrá acceder a ellas, es decir, lo que busca cómo resolver direcciones DNS, se verifica precisamente en /etc/resolv.conf, y no en otro lugar.
Se puede comprobar que la conexión a la VPN está activa y funciona sin necesidad de hacer modificaciones en /etc/resolv.conf, para esto basta con introducir en el navegador no el nombre simbólico del recurso de la VPN, sino su dirección IP.
Al final resulta que hay dos problemas
- al conectarse a la VPN no se capta su DNS
- todo el tráfico pasa a través de la VPN, que no permite acceder a Internet
Qué hacer, ahora lo explicaré, pero primero un poco de automatización.
Entrada automática de la parte fija de la contraseña
Para este momento probablemente ya has introducido la contraseña al menos cinco veces y este procedimiento ya te ha cansado. Primero, porque la contraseña es larga, y segundo, porque al introducirla hay que hacerlo dentro de un período de tiempo fijo.
La solución definitiva al problema no se incluyó en el artículo, pero se puede hacer que la parte fija de la contraseña no tenga que introducirse muchas veces.
Supongamos que la parte fija de la contraseña es fixedPassword, y la parte de Google Authenticator 567 987. La contraseña completa se puede pasar a openconnect a través de la entrada estándar con el argumento --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinAhora se puede volver constantemente al último comando ingresado y cambiar solo la parte de Google Authenticator.
La VPN corporativa no permite acceder a Internet.
No es muy conveniente que para acceder a habr sea necesario usar un ordenador separado. La falta de posibilidad de copiar y pegar de stackoverflow puede paralizar el trabajo, así que hay que hacer algo.
Es necesario organizar de alguna manera para que, cuando se necesite acceder a un recurso desde la red interna, Linux use VPN, y cuando se necesite acceder a Habr, lo haga a través de Internet.
Openconnect, después de iniciar y establecer la conexión con la VPN, ejecuta un script especial que se encuentra en /usr/share/vpnc-scripts/vpnc-script. Se le pasan algunas variables al script, y este configura la VPN. Desafortunadamente, no pude entender cómo separar los flujos de tráfico entre la VPN corporativa y el resto de Internet usando el script nativo.
Aparentemente, se desarrolló la herramienta vpn-slice especialmente para personas como yo, que permite dirigir el tráfico por dos canales sin complicaciones adicionales. Bueno, es decir, habrá que hacer algunas maniobras, pero no es necesario ser un chamán.
Separación de tráfico con vpn-slice
Primero, tendrás que instalar vpn-slice, con lo que deberás resolver esto por tu cuenta. Si hay preguntas en los comentarios, escribiré un post separado al respecto. Pero es un programa común en Python, así que no debería haber dificultades. Yo lo instalé usando virtualenv.
Y luego hay que aplicar la herramienta con la opción --script, indicando openconnect, que en lugar del script estándar, se 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 En --script se pasa la cadena con el comando que se debe ejecutar en lugar del script. . /bin/vpn-slice es la ruta al archivo ejecutable vpn-slice 192.168.430.0/24 es la máscara de direcciones por las que se debe usar la VPN. Se entiende que si la dirección comienza con 192.168.430, entonces el recurso con esta dirección se debe buscar dentro de la VPN.
Ahora la situación debería estar casi normal. Casi. Ahora se puede acceder a Habr y también se puede acceder al recurso interno por IP, pero no se puede acceder al recurso interno por nombre simbólico. Si se escribe la correspondencia entre el nombre simbólico y la dirección en hosts, todo debería funcionar. Y funcionará hasta que la IP cambie. Linux ahora puede acceder a Internet o a la red corporativa dependiendo de la IP. Pero para determinar la dirección, todavía se utiliza el DNS no corporativo.
El problema también puede manifestarse de esta manera: en el trabajo todo está bien, pero en casa solo se puede acceder a los recursos internos mediante IP. Esto se debe a que cuando estás conectado al Wi-Fi corporativo, también se utiliza DNS corporativo, y allí se resuelven las direcciones simbólicas desde VPN, a pesar de que todavía no se puede acceder a esa dirección sin usar VPN.
Modificación automática del archivo hosts
Si le pides amablemente a vpn-slice, puede después de levantar VPN acceder a su DNS, encontrar las direcciones IP de los recursos necesarios por sus nombres simbólicos y anotarlas en hosts. Después de apagar VPN, esas direcciones se eliminarán de hosts. Para esto, hay que pasar los nombres simbólicos a vpn-slice como argumentos. Así es.
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.
Buscar direcciones de todos los subdominios en DNS proporcionada por VPN
Si hay pocas direcciones dentro de la red, el enfoque de modificar automáticamente el archivo hosts es bastante operativo. Pero si hay muchos recursos en la red, tendrás que estar añadiendo constantemente al script líneas como zoidberg.test.evilcorp.com donde Zoidberg es uno de los entornos de prueba.
Pero ahora, cuando entendemos un poco mejor la situación, este requisito se puede eliminar.
Si después de levantar VPN miras en \/etc\/hosts, puedes ver una línea como esta:
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
Además, se añadió una nueva línea en resolv.conf. En resumen, vpn-slice de alguna manera determinó dónde está el servidor DNS para VPN.
Ahora tiene que hacerse que para conocer la dirección IP de un nombre de dominio que termina en evilcorp.com, Linux consulte primero el DNS corporativo, y si necesita algo diferente, que consulte el predeterminado.
He estado buscando mucho tiempo y descubrí que esa funcionalidad está disponible en Ubuntu por defecto. Se refiere a la posibilidad de usar para la resolución de nombres el servidor DNS local dnsmasq.
Es decir, se puede configurar para que Linux siempre consulte las direcciones IP en el servidor DNS local, que a su vez, dependiendo del nombre de dominio, buscará la IP en el servidor DNS externo correspondiente.
Para administrar todo lo relacionado con redes y conexiones de red en Ubuntu, se utiliza NetworkManager, y la interfaz gráfica para seleccionar, por ejemplo, la conexión WiFi, es simplemente un frontend para él.
Necesitaremos explorar su configuración.
- Crear un archivo en /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Nota que hay un punto antes de evilcorp. Esto le indica a dnsmasq que todos los subdominios de evilcorp.com deben buscarse en el DNS corporativo.
- Decirle a NetworkManager que para la resolución de nombres debe usar dnsmasq.
La configuración de network-manager se encuentra en /etc/NetworkManager/NetworkManager.conf. Necesitamos añadir allí:
[main]
dns=dnsmasq
- Reiniciar NetworkManager.
service network-manager restartAhora, después de conectarse a VPN usando la combinación de openconnect y vpn-slice, la IP se identificará correctamente, incluso si no se agregan direcciones simbólicas en los argumentos a vpnslice.
Cómo acceder a servicios específicos a través de VPN.
Después de conectarme a la VPN, estuve muy contento durante un par de días, pero luego descubrí que si me conecto a la VPN fuera de la red de la oficina, el correo no funciona. El síntoma es familiar, ¿verdad?
Nuestro correo está en mail.publicevilcorp.com, lo que significa que no se encuentra bajo la regla en dnsmasq y la dirección del servidor de correo se busca a través del DNS público.
Pero en la oficina todavía se utiliza un DNS que tiene esa dirección. Eso pensé. En la práctica, después de añadir a dnsmasq la línea
address=/mail.publicevilcorp.com/192.168.430.534
la situación no cambió en absoluto. La IP permaneció igual. Tuve que ir a trabajar.
Y ya después, cuando profundicé en la situación y entendí un poco el problema, una persona inteligente me sugirió cómo solucionarlo. Debía conectarme al servidor de correo no simplemente, sino a través de VPN.
Uso vpn-slice para acceder a direcciones a través de VPN que comienzan con 192.168.430. Pero el servidor de correo no solo tiene una dirección simbólica que no es un subdominio de evilcorp, su dirección IP tampoco comienza con 192.168.430. Y desde la red general, por supuesto, no deja entrar a nadie.
Para que Linux acceda a través de VPN y al servidor de correo, es necesario añadirlo a vpn-slice también. Supongamos que la dirección del correo 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 levantar VPN con un argumento.
Todo esto, por supuesto, no es muy conveniente. Sí, se puede guardar el texto en un archivo y copiar y pegar en la consola, en lugar de escribirlo a mano, pero aún así no es muy agradable. Para facilitar el proceso, se puede envolver el comando en un script que se ubicará en el PATH. Y entonces solo será necesario introducir 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 colocas el script en connect~evilcorp~, podrás escribir simplemente en la consola.
connect_evil_corp 567987Pero ahora aún tendrás que mantener la consola donde se está ejecutando openconnect abierta por alguna razón.
Ejecutar openconnect en segundo plano.
Afortunadamente, los autores de openconnect pensaron en nosotros y agregaron una opción especial al programa: —background, que hace que el programa funcione en segundo plano después de ser iniciado. Si lo ejecutas así, podrás cerrar la consola después del lanzamiento.
#!/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 solo queda la duda de a dónde van los logs. En general, no necesitamos mucho los logs, pero por si acaso. openconnect puede redirigirlos a syslog, donde estarán guardados de manera íntegra. Necesitamos agregar a la orden la opción —syslog.
#!/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 así, resulta que openconnect está funcionando en segundo plano y no molesta a nadie, pero no está claro cómo detenerlo. Se puede filtrar la salida de ps con grep y buscar el proceso cuyo nombre contenga openconnect, pero eso es algo tedioso. Gracias a los autores que pensaron en esto también. En openconnect hay una opción —pid-file, que permite instruir a openconnect para que escriba el identificador de su 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 se puede terminar el proceso con el comando.
kill $(cat ~/vpn-pid)Si no hay proceso, kill lanzará un mensaje de error, pero no arrojará una excepción. Si el archivo no existe, tampoco sucederá nada grave, así que se puede matar el proceso en la primera línea del script sin preocupaciones.
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 se puede encender la computadora, abrir la consola y ejecutar el comando, pasándole el código de Google Authenticator. Luego se puede terminar la consola.
Sin vpn-slice. En lugar de epílogo.
Entender cómo vivir sin vpn-slice resultó ser muy difícil. Tuve que leer mucho y buscar en Google. Afortunadamente, después de pasar tanto tiempo con el problema, los manuales técnicos e incluso man openconnect se leen como novelas apasionantes.
Al final, descubrí que vpn-slice, al igual que el script original, modifica la tabla de enrutamiento para dividir redes.
Tabla de enrutamiento
Simplificando, se trata de una tabla en cuya primera columna está lo que debe comenzar la dirección que desea utilizar Linux, y en la segunda, a través de qué adaptador de red debe pasar esta dirección. En realidad hay más columnas, pero eso 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 indica hacia dónde debe ir para enviar un mensaje a una dirección específica. Primero viene la descripción de cómo debe comenzar la dirección. Para entender cómo determinar que 192.168.0.0/16 significa que la dirección debe comenzar con 192.168, se debe investigar qué es una máscara de dirección IP. Después de dev está el nombre del adaptador por el cual debe enviarse el mensaje.
Para VPN, Linux creó un adaptador virtual: tun0. La línea que asegura que el tráfico para todas las direcciones que comienzan con 192.168 pase por él es
192.168.0.0/16 dev tun0 scope link También se puede ver el estado actual de la tabla de enrutamiento con el comando ruta -n (las direcciones IP han sido talentosamente anonimizadas) Este comando produce resultados en otro formato y está obsoleto, pero su salida a menudo aparece en manuales en línea y es necesario saber leerla.
De qué debe comenzar la dirección IP para la ruta se puede entender a partir de la combinación de las columnas Destination y Genmask. Las partes de la dirección IP para las que en Genmask corresponden a los números 255 se tienen en cuenta, mientras que aquellas donde está 0, no. Por lo tanto, la combinación Destination 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 Destination es 192.168.0.0 pero Genmask es 255.255.0.0, entonces por esta ruta irán las solicitudes a las direcciones que comienzan con 192.168.
Para entender realmente lo que hace vpn-slice, decidí observar el estado de las tablas antes y después.
Antes de activar la VPN, era así
route -n
Tabla de enrutamiento IP del kernel
Destino Gateway Genmask Flags Métrica Ref Uso Interfaz
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 ejecutar openconnect sin vpn-slice, quedó así
ruta -n
Tabla de enrutamiento del núcleo IP
Destino Puerta de enlace Máscara de red Flags Métricas Ref Uso Interfaz
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 así
Tabla de enrutamiento del núcleo IP
Destino Puerta de enlace Máscara de red Flags Métricas Ref Uso Interfaz
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 tun0Es evidente que si no se usa vpn-slice, openconnect indica explícitamente que para todas las direcciones, excepto las que se indican por separado, se debe ir a través de vpn.
Aquí:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Allí se indica otra ruta que debe usarse si la dirección a la que intenta acceder 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 wlp3s0Aquí ya está escrito que en tal caso se debe ir a través del adaptador WiFi estándar.
Supongo que la ruta para el VPN se utiliza porque es la primera en la tabla de enrutamiento.
Y teóricamente, si se elimina esta ruta predeterminada de la tabla de enrutamiento, openconnect debería garantizar un funcionamiento normal en combinación con dnsmasq.
He probado
ruta del defaultY todo funcionó.
Enrutamiento de solicitudes al servidor de correo sin vpn-slice
Pero tengo otro servidor de correo con la dirección 555.555.555.555, al que también hay que acceder a través de vpn. La ruta hacia él también debe ser añadida manualmente.
ip route add 555.555.555.555 via dev tun0Y ahora todo está bien. Así que se puede prescindir de vpn-slice, pero hay que saber bien lo que se está haciendo. Estoy pensando en agregar en la última línea del script original de openconnect la eliminación de la ruta predeterminada y la adición de la ruta para el servidor de correo después de conectarme a vpn, solo para que las partes móviles de mi bicicleta sean menos.
Quizás a alguien le bastaría con este epílogo para entender cómo configurar una VPN. Pero yo, mientras trataba de comprender qué hacer, leí bastante sobre guías que funcionan para el autor, pero que, por alguna razón, no funcionan para mí, y decidí agregar aquí todos los fragmentos que encontré. Me habría alegrado mucho encontrar algo así.
Fuente: habr.com
