Voleu utilitzar Linux a la feina, però la vostra VPN corporativa no us ho permet? Aleshores, aquest article pot ajudar, encara que això no és segur. M'agradaria advertir-vos amb antelació que no entenc bé els problemes d'administració de la xarxa, per la qual cosa és possible que ho hagi fet tot malament. D'altra banda, és possible que puc escriure una guia de manera que sigui entenedora per a la gent comuna, així que us aconsello que la proveu.
L'article conté molta informació innecessària, però sense aquest coneixement no hauria pogut resoldre els problemes que em van aparèixer inesperadament amb la configuració d'una VPN. Crec que qualsevol persona que intenti utilitzar aquesta guia tindrà problemes que jo no vaig tenir, i espero que aquesta informació addicional els ajudi a resoldre aquests problemes pel seu compte.
La majoria de les ordres utilitzades en aquesta guia s'han d'executar mitjançant sudo, que s'ha eliminat per concisió. Tenir en ment.
La majoria de les adreces IP s'han ofuscat molt, de manera que si veieu una adreça com 435.435.435.435, hi ha d'haver una IP normal, específica per al vostre cas.
Tinc Ubuntu 18.04, però crec que amb canvis menors la guia es pot aplicar a altres distribucions. Tanmateix, en aquest text Linux == Ubuntu.
Cisco Connect
Els que estiguin a Windows o MacOS es poden connectar a la nostra VPN corporativa a través de Cisco Connect, que ha d'especificar l'adreça de la passarel·la i, cada vegada que es connecta, introduir una contrasenya formada per una part fixa i un codi generat per Google Authenticator.
En el cas de Linux, no vaig poder fer funcionar Cisco Connect, però vaig aconseguir buscar a Google una recomanació per utilitzar openconnect, feta específicament per substituir Cisco Connect.
Openconnect
En teoria, Ubuntu té una interfície gràfica especial per a openconnect, però no em va funcionar. Potser és per a millor.
A Ubuntu, openconnect s'instal·la des del gestor de paquets.
apt install openconnectImmediatament després de la instal·lació, podeu provar de connectar-vos a una VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com és l'adreça d'una VPN fictícia
poxvuibr - nom d'usuari fictici
openconnect us demanarà que introduïu una contrasenya, que, us ho recordo, consta d'una part fixa i un codi de Google Authenticator, i després intentarà connectar-vos a la VPN. Si funciona, felicitats, podeu saltar amb seguretat el centre, que és molt dolorós, i passar al punt sobre l'openconnect que s'executa en segon pla. Si no funciona, podeu continuar. Tot i que si va funcionar en connectar-se, per exemple, des d'una xarxa Wi-Fi convidada a la feina, potser és massa aviat per alegrar-se; hauríeu d'intentar repetir el procediment des de casa.
Certificat
Hi ha una gran probabilitat que no s'iniciï res i la sortida d'openconnect tindrà un aspecte semblant a això:
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 progressD'una banda, això és desagradable, perquè no hi havia connexió amb la VPN, però d'altra banda, com solucionar aquest problema és, en principi, clar.
Aquí el servidor ens va enviar un certificat, pel qual podem determinar que la connexió s'està fent amb el servidor de la nostra corporació nativa, i no amb un malvat estafador, i aquest certificat és desconegut pel sistema. I, per tant, no pot comprovar si el servidor és real o no. I així, per si de cas, deixa de funcionar.
Per tal que l'openconnect es connecti al servidor, heu de dir-li explícitament quin certificat ha de provenir del servidor VPN mitjançant la clau —servercert
I podeu esbrinar quin certificat ens va enviar el servidor directament des del que openconnect va imprimir. Aquí és d'aquesta peça:
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 progressAmb aquesta ordre podeu provar de connectar-vos de nou
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comPotser ara està funcionant, llavors podeu passar al final. Però personalment, Ubunta em va mostrar una figa d'aquesta 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 es resoldrà, però no hi podreu anar. Les adreces com jira.evilcorp.com no es resolen en absolut.
El que va passar aquí no ho tinc clar. Però l'experiment mostra que si afegiu la línia a /etc/resolv.conf
nameserver 192.168.430.534aleshores, les adreces dins de la VPN començaran a resoldre's de manera màgica i les podreu caminar, és a dir, el que el DNS busca per resoldre les adreces es veu específicament a /etc/resolv.conf, i no a un altre lloc.
Podeu comprovar que hi ha una connexió a la VPN i que funciona sense fer cap canvi a /etc/resolv.conf; per fer-ho, només cal que introduïu al navegador no el nom simbòlic del recurs de la VPN, sinó la seva adreça IP
Com a resultat, hi ha dos problemes
- Quan es connecta a una VPN, el seu dns no es recull
- tot el trànsit passa per VPN, que no permet l'accés a Internet
Ara us diré què heu de fer, però primer una mica d'automatització.
Entrada automàtica de la part fixa de la contrasenya
A hores d'ara, probablement ja hagueu introduït la vostra contrasenya almenys cinc vegades i aquest procediment ja us ha cansat. En primer lloc, perquè la contrasenya és llarga, i en segon lloc, perquè en entrar cal que encaixi en un període de temps determinat
La solució final al problema no es va incloure a l'article, però podeu assegurar-vos que la part fixa de la contrasenya no s'ha d'introduir moltes vegades.
Suposem que la part fixa de la contrasenya és fixedPassword i la part de Google Authenticator és 567. La contrasenya sencera es pot passar a openconnect mitjançant l'entrada estàndard mitjançant l'argument --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinAra podeu tornar constantment a l'última ordre introduïda i canviar-hi només una part de Google Authenticator.
Una VPN corporativa no us permet navegar per Internet.
En general, no és gaire inconvenient quan heu d'utilitzar un ordinador independent per anar a Habr. La incapacitat de copiar i enganxar des de stackoverfow generalment pot paralitzar el treball, de manera que cal fer alguna cosa.
Hem d'organitzar-ho d'alguna manera perquè quan necessiteu accedir a un recurs des de la xarxa interna, Linux vagi a la VPN, i quan necessiteu anar a Habr, vagi a Internet.
openconnect, després d'iniciar i establir una connexió amb vpn, executa un script especial, que es troba a /usr/share/vpnc-scripts/vpnc-script. Algunes variables es passen a l'script com a entrada i configura la VPN. Malauradament, no he pogut esbrinar com dividir els fluxos de trànsit entre una VPN corporativa i la resta d'Internet mitjançant un script natiu.
Pel que sembla, la utilitat vpn-slice es va desenvolupar especialment per a gent com jo, que permet enviar trànsit per dos canals sense ballar amb un tamborí. Bé, és a dir, hauràs de ballar, però no cal que siguis xaman.
Separació del trànsit mitjançant vpn-slice
En primer lloc, haureu d'instal·lar vpn-slice, haureu d'esbrinar-ho vosaltres mateixos. Si hi ha preguntes als comentaris, escriuré una publicació separada sobre això. Però aquest és un programa normal de Python, de manera que no hi hauria d'haver cap dificultat. Vaig instal·lar amb virtualenv.
I després s'ha d'aplicar la utilitat, utilitzant el commutador -script, indicant per obrir la connexió que en lloc de l'script estàndard, cal utilitzar 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 --script es passa una cadena amb una ordre que cal cridar en lloc de l'script. ./bin/vpn-slice - camí al fitxer executable de vpn-slice 192.168.430.0/24 - màscara d'adreces per anar a vpn. Aquí, volem dir que si l'adreça comença amb 192.168.430, s'ha de cercar el recurs amb aquesta adreça dins de la VPN.
Ara la situació hauria de ser gairebé normal. Gairebé. Ara pots anar a Habr i pots anar al recurs intracorporatiu per ip, però no pots anar al recurs intracorporatiu amb nom simbòlic. Si especifiqueu una coincidència entre el nom simbòlic i l'adreça als amfitrions, tot hauria de funcionar. I treballeu fins que canviï la ip. Linux ara pot accedir a Internet o a la intranet, depenent de la IP. Però encara s'utilitza DNS no corporatiu per determinar l'adreça.
El problema també es pot manifestar d'aquesta forma: a la feina tot està bé, però a casa només podeu accedir als recursos corporatius interns mitjançant IP. Això es deu al fet que quan esteu connectat a una Wi-Fi corporativa, també s'utilitza el DNS corporatiu i s'hi resolen les adreces simbòliques de la VPN, malgrat que encara és impossible anar a aquesta adreça sense utilitzar una VPN.
Modificació automàtica del fitxer hosts
Si es demana cortèsment a vpn-slice, després d'aixecar la VPN, pot anar al seu DNS, trobar-hi les adreces IP dels recursos necessaris pels seus noms simbòlics i introduir-los als amfitrions. Després de desactivar la VPN, aquestes adreces s'eliminaran dels amfitrions. Per fer-ho, heu de passar noms simbòlics a vpn-slice com a arguments. Com això.
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 Ara tot hauria de funcionar tant a l'oficina com a la platja.
Cerqueu les adreces de tots els subdominis al DNS proporcionat per la VPN
Si hi ha poques adreces a la xarxa, l'enfocament de modificar automàticament el fitxer hosts funciona força bé. Però si hi ha molts recursos a la xarxa, haureu d'afegir constantment línies com zoidberg.test.evilcorp.com al guió zoidberg és el nom d'un dels bancs de proves.
Però ara que entenem una mica per què es pot eliminar aquesta necessitat.
Si, després d'aixecar la VPN, busqueu a /etc/hosts, podeu veure aquesta línia
192.168.430.534 dns0.tun0 # vpn-slice-tun0 S'ha creat automàticament
I es va afegir una nova línia a resolv.conf. En resum, vpn-slice determina d'alguna manera on es troba el servidor dns per a la VPN.
Ara ens hem d'assegurar que per esbrinar l'adreça IP d'un nom de domini que acaba en evilcorp.com, Linux va al DNS corporatiu i, si cal alguna cosa més, al predeterminat.
Vaig buscar a Google durant força temps i vaig trobar que aquesta funcionalitat està disponible a Ubuntu de manera immediata. Això significa la possibilitat d'utilitzar el servidor DNS local dnsmasq per resoldre noms.
És a dir, podeu assegurar-vos que Linux sempre va al servidor DNS local per a les adreces IP, que al seu torn, segons el nom del domini, buscarà la IP al servidor DNS extern corresponent.
Per gestionar tot allò relacionat amb les xarxes i les connexions de xarxa, Ubuntu utilitza NetworkManager, i la interfície gràfica per seleccionar, per exemple, connexions Wi-Fi és només un front end.
Haurem de pujar en la seva configuració.
- Creeu un fitxer a /etc/NetworkManager/dnsmasq.d/evilcorp
adreça=/.evilcorp.com/192.168.430.534
Pareu atenció al punt davant de evilcorp. Indica a dnsmasq que s'han de cercar tots els subdominis d'evilcorp.com al dns corporatiu.
- Digueu a NetworkManager que utilitzi dnsmasq per a la resolució de noms
La configuració del gestor de xarxa es troba a /etc/NetworkManager/NetworkManager.conf. Cal afegir-hi:
[principal] dns=dnsmasq
- Reinicieu NetworkManager
service network-manager restartAra, després de connectar-vos a una VPN mitjançant openconnect i vpn-slice, la ip es determinarà normalment, fins i tot si no afegiu adreces simbòliques als arguments de vpnslice.
Com accedir a serveis individuals mitjançant VPN
Després d'haver aconseguit connectar-me a la VPN, vaig estar molt content durant dos dies, i després va resultar que si em connecto a la VPN des de fora de la xarxa de l'oficina, el correu no funciona. El símptoma és familiar, no?
El nostre correu es troba a mail.publicevilcorp.com, la qual cosa significa que no entra sota la regla de dnsmasq i l'adreça del servidor de correu es cerca a través del DNS públic.
Bé, l'oficina encara utilitza DNS, que conté aquesta adreça. Això és el que vaig pensar. De fet, després d'afegir la línia a dnsmasq
adreça=/mail.publicevilcorp.com/192.168.430.534
la situació no ha canviat gens. ip es va mantenir igual. Vaig haver d'anar a treballar.
I només més tard, quan vaig aprofundir en la situació i vaig entendre una mica el problema, una persona intel·ligent em va dir com resoldre'l. Calia connectar-se al servidor de correu no només així, sinó mitjançant VPN
Utilitzo vpn-slice per passar per la VPN a adreces que comencen amb 192.168.430. I el servidor de correu no només té una adreça simbòlica que no és un subdomini d'evilcorp, sinó que tampoc té una adreça IP que comenci amb 192.168.430. I és clar que no permet que ningú de la xarxa general li vingui.
Perquè Linux passi per la VPN i el servidor de correu, també l'heu d'afegir a vpn-slice. Suposem que l'adreça del correu és 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 per aixecar VPN amb un argument
Tot això, és clar, no és gaire convenient. Sí, podeu desar el text en un fitxer i copiar-lo i enganxar-lo a la consola en lloc d'escriure-lo a mà, però encara no és molt agradable. Per facilitar el procés, podeu embolicar l'ordre en un script que es trobarà a PATH. I llavors només hauràs d'introduir el codi rebut 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 poseu l'script a connect~evilcorp~, simplement podeu escriure a la consola
connect_evil_corp 567987Però ara encara heu de mantenir oberta la consola en què s'executa l'openconnect per algun motiu
S'està executant openconnect en segon pla
Afortunadament, els autors d'openconnect van tenir cura de nosaltres i van afegir una clau especial al programa -background, que fa que el programa funcioni en segon pla després del llançament. Si l'executeu així, podeu tancar la consola després de l'inici
#!/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 Ara no està clar on van els registres. En general, realment no necessitem registres, però mai se sap. openconnect pot redirigir-los a Syslog, on es mantindran segurs i protegits. heu d'afegir el commutador –syslog a l'ordre
#!/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 I, per tant, resulta que openconnect funciona en algun lloc en segon pla i no molesta a ningú, però no està clar com aturar-ho. És a dir, podeu, per descomptat, filtrar la sortida ps amb grep i buscar un procés el nom del qual contingui openconnect, però això és d'alguna manera tediós. Gràcies als autors que també han pensat en això. Openconnect té una clau -pid-file, amb la qual podeu indicar a openconnect que escrigui el seu identificador de procés en un fitxer.
#!/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-pidAra sempre podeu matar un procés amb l'ordre
kill $(cat ~/vpn-pid)Si no hi ha cap procés, kill maleirà, però no llançarà cap error. Si el fitxer no hi és, tampoc no passarà res dolent, de manera que podeu matar el procés amb seguretat a la primera línia de l'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-pidAra podeu encendre l'ordinador, obrir la consola i executar l'ordre, passant-li el codi de Google Authenticator. Aleshores, la consola es pot clavar.
Sense VPN-slice. En lloc d'un epílogo
Va resultar molt difícil entendre com viure sense VPN-slice. Vaig haver de llegir i buscar a Google molt. Afortunadament, després de passar tant de temps amb un problema, els manuals tècnics i fins i tot l'home openconnect es llegeixen com novel·les emocionants.
Com a resultat, vaig descobrir que vpn-slice, com l'script natiu, modifica la taula d'encaminament per separar xarxes.
Taula d'encaminament
Per dir-ho senzillament, aquesta és una taula a la primera columna que conté quina ha de començar l'adreça per la qual vol passar Linux i, a la segona columna, quin adaptador de xarxa ha de passar en aquesta adreça. De fet, hi ha més parlants, però això no canvia l'essència.
Per veure la taula d'encaminament, heu d'executar l'ordre 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ínia és responsable d'on heu d'anar per enviar un missatge a alguna adreça. El primer és una descripció d'on hauria de començar l'adreça. Per entendre com determinar que 192.168.0.0/16 vol dir que l'adreça hauria de començar per 192.168, heu de buscar a Google què és una màscara d'adreça IP. Després de dev hi ha el nom de l'adaptador al qual s'ha d'enviar el missatge.
Per a VPN, Linux va crear un adaptador virtual: tun0. La línia assegura que el trànsit de totes les adreces que comencen per 192.168 hi passa
192.168.0.0/16 dev tun0 scope link També podeu veure l'estat actual de la taula d'encaminament mitjançant l'ordre ruta -n (Les adreces IP estan anònimes de manera intel·ligent) Aquesta ordre produeix resultats en una forma diferent i en general està obsoleta, però la seva sortida es troba sovint als manuals d'Internet i cal que la puguis llegir.
On ha de començar l'adreça IP d'una ruta es pot entendre a partir de la combinació de les columnes Destinació i Genmask. Es tenen en compte aquelles parts de l'adreça IP que corresponen als números 255 de Genmask, però les on hi ha 0 no. És a dir, la combinació de Destinació 192.168.0.0 i Genmask 255.255.255.0 significa que si l'adreça comença per 192.168.0, la sol·licitud anirà per aquesta ruta. I si la destinació 192.168.0.0 però Genmask 255.255.0.0, les sol·licituds a adreces que comencen per 192.168 aniran per aquesta ruta
Per esbrinar què fa realment vpn-slice, vaig decidir mirar els estats de les taules abans i després
Abans d'encendre la VPN era així
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 wlp3s0Després de trucar a openconnect sense vpn-slice, es va convertir així
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 tun0I després de trucar a openconnect en combinació amb vpn-slice com aquesta
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 tun0Es pot veure que si no utilitzeu vpn-slice, openconnect escriu explícitament que s'ha d'accedir a totes les adreces, excepte les indicades específicament, mitjançant vpn.
Aquí mateix:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Allà, al costat, s'indica immediatament un altre camí, que s'ha d'utilitzar si l'adreça per la qual està intentant passar Linux no coincideix amb cap màscara de la taula.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Ja està escrit aquí que en aquest cas cal utilitzar un adaptador Wi-Fi estàndard.
Crec que s'utilitza la ruta VPN perquè és la primera de la taula d'encaminament.
I teòricament, si elimineu aquest camí predeterminat de la taula d'encaminament, juntament amb dnsmasq openconnect hauria de garantir un funcionament normal.
ho he intentat
route del defaultI tot va funcionar.
Encaminament de sol·licituds a un servidor de correu sense vpn-slice
Però també tinc un servidor de correu amb l'adreça 555.555.555.555, al qual també s'ha d'accedir mitjançant VPN. També cal afegir-hi manualment la ruta.
ip route add 555.555.555.555 via dev tun0I ara tot està bé. Així que pots prescindir de vpn-slice, però has de saber bé què estàs fent. Ara estic pensant si cal afegir a l'última línia de l'script d'openconnect natiu per eliminar la ruta predeterminada i afegir una ruta per al correu després de connectar-me a la VPN, només perquè hi hagi menys peces mòbils a la meva bicicleta.
Probablement, aquest epílogo seria suficient perquè algú entengués com configurar una VPN. Però mentre intentava entendre què i com fer, vaig llegir un munt de guies d'aquest tipus que funcionen per a l'autor, però per alguna raó no em funcionen, i vaig decidir afegir aquí totes les peces que vaig trobar. Estaria molt content d'una cosa així.
Font: www.habr.com