Vous souhaitez utiliser Linux au travail, mais le VPN de l'entreprise ne le permet pas ? Alors cet article pourrait vous aider, bien que ce ne soit pas garanti. Je tiens à vous avertir à l'avance que je ne comprends pas bien les questions d'administration réseau, donc il est possible que j'aie tout mal fait. D'un autre côté, il se peut que je parvienne à écrire un guide qui soit compréhensible pour des gens ordinaires, alors je vous conseille d'essayer.
L'article contient beaucoup d'informations supplémentaires, mais sans ces connaissances, je n'aurais pas pu résoudre des problèmes imprévus survenus lors de la configuration du VPN. Je pense que quiconque tentera d'appliquer ce guide rencontrera des problèmes que je n'ai pas eus, et j'espère que ces informations supplémentaires aideront à résoudre ces problèmes par eux-mêmes.
La plupart des commandes utilisées dans le guide doivent être exécutées avec sudo, qui a été omis pour des raisons de concision. Gardez cela à l'esprit.
La plupart des adresses IP ont été fortement obfusquées, donc si vous voyez une adresse comme 435.435.435.435 — il devrait y avoir une adresse IP normale, spécifique à votre cas.
J'ai Ubuntu 18.04, mais je pense qu'avec quelques modifications, le guide peut également être appliqué à d'autres distributions. Cependant, dans ce texte, Linux == Ubuntu.
Cisco Connect
Ceux qui sont sous Windows ou MacOS peuvent se connecter à notre VPN d'entreprise via Cisco Connect, auquel il faut indiquer l'adresse de la passerelle et, à chaque connexion, entrer un mot de passe composé d'une partie fixe et d'un code généré par Google Authenticator.
Dans le cas de Linux, je n'ai pas pu obtenir Cisco Connect, mais j'ai trouvé une recommandation pour utiliser openconnect, conçu spécifiquement pour remplacer Cisco Connect.
Openconnect
En théorie, Ubuntu dispose d'une interface graphique spéciale pour openconnect, mais elle n'a pas fonctionné chez moi. Peut-être que c'est pour le mieux.
Sur Ubuntu, openconnect s'installe via le gestionnaire de paquets.
apt install openconnectJuste après l'installation, vous pouvez essayer de vous connecter au VPN.
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com est l'adresse d'un VPN fictif.
poxvuibr est le nom d'utilisateur fictif.
openconnect vous demandera de saisir un mot de passe qui, je le rappelle, se compose d'une partie fixe et d'un code de Google Authenticator, puis tentera de se connecter au VPN. Si cela a réussi, félicitations, vous pouvez passer directement à la section sur le fonctionnement d'openconnect en arrière-plan, en évitant une étape pleine de douleurs. Si cela n'a pas fonctionné, vous pouvez continuer. Cependant, si cela a fonctionné par exemple en se connectant depuis un Wi-Fi invité au travail, il peut être prématuré de se réjouir, il faut essayer de répéter la procédure depuis chez soi.
Certificat
Il est très probable que rien ne démarre et que la sortie d'openconnect ressemblera à quelque chose comme ça :
POST https://vpn.evilcorp.com/
Connecté à 777.777.777.777:443
Négociation SSL avec vpn.evilcorp.com
Échec de la vérification du certificat du serveur : signataire non trouvé
Le certificat du serveur VPN "vpn.evilcorp.com" a échoué à la vérification.
Raison : signataire non trouvé
Pour faire confiance à ce serveur à l'avenir, vous pouvez peut-être ajouter cela à votre ligne de commande :
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Entrez 'yes' pour accepter, 'no' pour annuler ; tout autre pour voir : fgets (stdin) : opération maintenant en coursD'un côté, c'est désagréable car la connexion au VPN n'a pas eu lieu, mais d'un autre côté, il est clair comment corriger ce problème.
Ici, le serveur nous a envoyé un certificat à partir duquel on peut déterminer que la connexion se fait bien au serveur de notre entreprise et non à un méchant escroc, mais le système ne connaît pas ce certificat. Par conséquent, il ne peut pas vérifier si le serveur est authentique ou non. C'est pourquoi il arrête ses activités par précaution.
Pour que openconnect puisse quand même se connecter au serveur, il faut lui indiquer explicitement quel certificat doit être reçu du serveur VPN en utilisant l'option --servercert.
Et pour savoir quel certificat le serveur nous a envoyé, on peut directement le prendre dans ce que openconnect a imprimé. Voici ce morceau :
Pour faire confiance à ce serveur à l'avenir, vous pouvez peut-être ajouter cela à votre ligne de commande :
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Entrez 'yes' pour accepter, 'no' pour annuler ; tout autre pour voir : fgets (stdin) : opération maintenant en coursAvec cette commande, vous pouvez essayer de vous reconnecter.
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comPeut-être que ça a fonctionné maintenant, alors vous pouvez passer à la fin. Mais personnellement, Ubuntu m'a montré un doigt sous cette forme.
POST https://vpn.evilcorp.com/
Connecté à 777.777.777.777:443
Négociation SSL avec vpn.evilcorp.com
Échec de la vérification du certificat du serveur : signataire introuvable
Connecté à HTTPS sur vpn.evilcorp.com
XML POST activé
Veuillez entrer votre nom d'utilisateur et votre mot de passe.
POST https://vpn.evilcorp.com/
Réponse CONNECT reçue : HTTP/1.1 200 OK
CSTP connecté. DPD 300, Keepalive 30
Échec de la configuration de DTLS ; utilisation de SSL à la place
Connecté en tant que 192.168.333.222, utilisant SSL
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
RTNETLINK réponses : Le fichier existe
/etc/resolvconf/update.d/libc : Avertissement : /etc/resolv.conf n'est pas un lien symbolique vers /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 sera résolu, mais il sera impossible d'y accéder. Les adresses du type jira.evilcorp.com ne sont pas du tout résolues.
Ce qui s'est passé ici n'est pas clair pour moi. Mais l'expérience montre que si l'on ajoute la ligne dans /etc/resolv.conf
nameserver 192.168.430.534les adresses à l'intérieur du VPN commenceront à être résolues de manière magique et il sera possible d'y accéder, c'est-à-dire que ce que recherche le DNS pour résoudre les adresses regarde précisément dans /etc/resolv.conf, et non ailleurs.
Il est possible de s'assurer que la connexion au VPN existe et qu'elle fonctionne sans modifier /etc/resolv.conf, il suffit d'entrer dans le navigateur non pas un nom de ressource symbolique du VPN, mais son adresse IP.
En fin de compte, il y a deux problèmes.
- lors de la connexion au VPN, son DNS n'est pas pris en charge
- tout le trafic passe par le VPN, qui ne permet pas d'accéder à Internet.
Que faire, je vais le raconter maintenant, mais d'abord un peu d'automatisation.
Saisie automatique de la partie fixe du mot de passe.
À ce stade, vous avez probablement déjà saisi le mot de passe au moins cinq fois et cette procédure vous a déjà sérieusement fatigué. D'une part, parce que le mot de passe est long, d'autre part, parce qu'il faut le saisir dans un laps de temps fixe.
La solution définitive au problème n'a pas été incluse dans l'article, mais il est possible de faire en sorte que la partie fixe du mot de passe n'ait pas à être saisie plusieurs fois.
Supposons que la partie fixe du mot de passe soit fixedPassword et la partie de Google Authenticator 567 987. Le mot de passe complet openconnect peut être passé via l'entrée standard avec l'argument --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinMaintenant, vous pouvez constamment revenir à la dernière commande saisie et y changer seulement la partie de Google Authenticator.
Le VPN d'entreprise ne permet pas d'accéder à Internet.
C'est en fait très peu pratique, lorsqu'il faut utiliser un ordinateur séparé pour accéder à habr. L'absence de possibilité de copier-coller depuis stackoverflow peut vraiment paralyser le travail, donc il faut faire quelque chose.
Il faut organiser les choses de telle sorte que, lorsque l'on doit accéder à la ressource depuis le réseau local, Linux utilise le VPN, et lorsque l'on doit accéder à Habr, cela passe par Internet.
Après le lancement d'openconnect et l'établissement de la connexion VPN, un script spécial est exécuté, qui se trouve dans /usr/share/vpnc-scripts/vpnc-script. Certaines variables sont passées au script, et il configure le VPN. Malheureusement, je n'ai pas pu comprendre comment séparer les flux de trafic entre le VPN d'entreprise et le reste d'Internet à l'aide du script d'origine.
Apparemment, un outil a été spécialement développé pour les personnes comme moi : vpn-slice, qui permet d'acheminer le trafic par deux canaux sans trop de complications. Enfin, des complications seront inévitables, mais il n'est pas nécessaire d'être chaman.
Séparation du trafic avec vpn-slice
Tout d'abord, il faudra installer vpn-slice, c'est quelque chose que vous devrez gérer seul. Si vous avez des questions dans les commentaires, je rédigerai un post séparé à ce sujet. Mais c'est un programme Python classique, donc cela ne devrait pas être trop compliqué. Je l'ai installé avec virtualenv.
Ensuite, il faut appliquer l'outil, en utilisant le paramètre —script pour indiquer à openconnect qu'il doit utiliser vpn-slice à la place du script standard.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script ".\/bin\/vpn-slice 192.168.430.0\/24 " vpn.evilcorp.com La chaîne passée à —script contient la commande à appeler à la place du script. .\/bin\/vpn-slice — chemin vers le fichier exécutable vpn-slice 192.168.430.0\/24 — masque d'adresses à travers lequel le VPN doit être utilisé. Cela signifie que si l'adresse commence par 192.168.430, la ressource avec cette adresse doit être recherchée à l'intérieur du VPN.
La situation devrait maintenant être presque normale. Presque. On peut désormais accéder à Habr et aux ressources internes par IP, mais il est impossible d'accéder à une ressource interne par son nom symbolique. Si l'on configure la correspondance entre le nom symbolique et l'adresse dans hosts, tout devrait fonctionner. Et cela fonctionnera tant que l'IP ne change pas. Linux sait maintenant naviguer sur Internet ou dans le réseau d'entreprise en fonction de l'IP. Mais pour résoudre l'adresse, il continue d'utiliser un DNS non corporatif.
Le problème peut également se manifester de cette manière : au travail, tout fonctionne normalement, mais à la maison, on ne peut accéder aux ressources internes de l'entreprise qu'en utilisant l'adresse IP. C'est parce que lorsque vous êtes connecté au Wi-Fi de l'entreprise, le DNS utilisé est également celui de l'entreprise, et les adresses symboliques des ressources VPN sont résolues, même s'il n'est toujours pas possible d'y accéder sans utiliser le VPN.
Modification automatique du fichier hosts
Si vous demandez gentiment à vpn-slice, il peut aller dans son DNS après l'activation du VPN, trouver les adresses IP des ressources dont vous avez besoin par leurs noms symboliques et les ajouter au fichier hosts. Après la désactivation du VPN, ces adresses seront supprimées du fichier hosts. Pour cela, il faut transmettre les noms symboliques à vpn-slice comme arguments. Voici comment.
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 Maintenant, tout devrait fonctionner aussi bien au bureau qu'à la plage.
Rechercher les adresses de tous les sous-domaines dans le DNS fourni par le VPN
Si les adresses à l'intérieur du réseau sont peu nombreuses, l'approche de la modification automatique du fichier hosts fonctionne très bien. Mais s'il y a beaucoup de ressources dans le réseau, vous devrez constamment ajouter des lignes comme zoidberg.test.evilcorp.com dans le script, zoidberg étant le nom d'un des bancs d'essai.
Mais maintenant que nous comprenons un peu mieux, cette nécessité peut être éliminée.
Si après l'activation du VPN vous regardez dans \/etc\/hosts, vous pouvez voir une ligne comme celle-ci
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
De plus, une nouvelle ligne a été ajoutée à resolv.conf. Bref, vpn-slice a d'une manière ou d'une autre déterminé où se trouve le serveur DNS pour le VPN.
Maintenant, il faut faire en sorte que, pour connaître l'adresse IP d'un nom de domaine se terminant par evilcorp.com, Linux interroge le DNS de l'entreprise, et pour toute autre chose, le DNS par défaut.
J'ai cherché longtemps sur Google et j'ai découvert que cette fonctionnalité est intégrée dans Ubuntu. Cela signifie la possibilité d'utiliser un serveur DNS local dnsmasq pour la résolution de noms.
Ainsi, vous pouvez faire en sorte que, pour les adresses IP, Linux interroge toujours le serveur DNS local, qui, en fonction du nom de domaine, cherchera des IP sur le serveur DNS externe correspondant.
Pour gérer tout ce qui concerne les réseaux et les connexions réseau sous Ubuntu, on utilise NetworkManager, et l'interface graphique pour sélectionner, par exemple, une connexion WiFi, n'est qu'une façade pour cela.
Nous devrons explorer sa configuration.
- Créer un fichier dans /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Notez le point devant evilcorp. Cela indique à dnsmasq que tous les sous-domaines de evilcorp.com doivent être recherchés dans le DNS d'entreprise.
- Indiquer à NetworkManager qu'il faut utiliser dnsmasq pour résoudre les noms.
La configuration de network-manager se trouve dans /etc/NetworkManager/NetworkManager.conf. Il faut y ajouter :
[main]
dns=dnsmasq
- Redémarrer NetworkManager.
service network-manager restartMaintenant, après s'être connecté au VPN en utilisant le couple openconnect et vpn-slice, l'IP sera correctement déterminée, même sans ajouter d'adresses symboliques dans les arguments de vpnslice.
Comment accéder à certains services via VPN.
Après avoir réussi à me connecter au VPN, j'ai été très content pendant deux jours, puis j'ai découvert que si je me connectais au VPN en dehors du réseau de bureau, le courrier ne fonctionnait pas. Un symptôme familier, n'est-ce pas ?
Notre courrier se trouve sur mail.publicevilcorp.com, et donc il ne rentre pas dans la règle de dnsmasq, et l'adresse du serveur de messagerie est recherchée via le DNS public.
Eh bien, au bureau, nous utilisons toujours le DNS qui contient cette adresse. C'est ce que je pensais. En réalité, après avoir ajouté la ligne dans dnsmasq
address=/mail.publicevilcorp.com/192.168.430.534
la situation n'a pas changé. L'IP est restée la même. J'ai dû aller au travail.
Et ensuite, quand je me suis plongé dans la situation et que j'ai un peu compris le problème, une personne avisée m'a suggéré comment le résoudre. Il fallait se connecter au serveur de messagerie non pas n'importe comment, mais via le VPN.
J'utilise vpn-slice pour aller à travers le VPN vers les adresses qui commencent par 192.168.430. Or, l'adresse du serveur de messagerie n'est pas seulement un sous-domaine d'evilcorp, son adresse IP ne commence pas non plus par 192.168.430. Et depuis le réseau général, il ne laisse bien sûr personne entrer.
Pour que Linux accède au VPN et au serveur de messagerie, il faut l'ajouter dans vpn-slice également. Supposons que l'adresse du serveur de messagerie est 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 pour établir le VPN avec un argument.
Tout cela n'est évidemment pas très pratique. Oui, on peut enregistrer le texte dans un fichier et le copier-coller dans la console au lieu de le taper à la main, mais cela reste loin d'être agréable. Pour simplifier le processus, on peut envelopper la commande dans un script qui se trouvera dans le PATH. Il suffira alors d'entrer le code reçu depuis 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 l'on place le script dans connect~evilcorp~, on pourra simplement écrire dans la console.
connect_evil_corp 567987Mais maintenant, il faudra tout de même garder ouverte la console dans laquelle openconnect est lancé.
Lancer openconnect en arrière-plan.
Heureusement, les auteurs d'openconnect ont pensé à nous et ont ajouté dans le programme une option spéciale —background, qui permet à l'application de continuer à fonctionner en arrière-plan après son lancement. Si on l'exécute ainsi, on pourra fermer la console après le lancement.
#!/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 Maintenant, on ne sait pas vraiment où vont les logs. En réalité, les logs ne sont pas très importants, mais bon. Openconnect peut les rediriger vers syslog, où ils seront conservés en toute sécurité. Il faut donc ajouter l'option —syslog à la commande.
#!/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 Et voilà, openconnect fonctionne quelque part en arrière-plan sans gêner personne, mais il est difficile de savoir comment l'arrêter. On pourrait, bien sûr, filtrer la sortie de ps avec grep et chercher le processus dont le nom contient openconnect, mais cela reste fastidieux. Merci aux auteurs qui ont pensé à cela. Dans openconnect, il y a une option —pid-file, qui permet d'instruire openconnect à écrire l'identifiant de son processus dans un fichier.
#!/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-pidOn peut désormais toujours tuer le processus avec la commande.
kill $(cat ~/vpn-pid)S'il n'y a pas de processus, kill renverra une erreur, mais ne lancera pas d'exception. S'il n'y a pas de fichier, rien de grave ne se produira non plus, donc on peut sans souci tuer le processus dans la première ligne du 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-pidOn peut maintenant allumer l'ordinateur, ouvrir la console et lancer la commande en lui passant le code de Google Authenticator. On pourra ensuite tuer la console.
Sans vpn-slice. En guise de postface.
Comprendre comment vivre sans vpn-slice s'est avéré très difficile. J'ai dû beaucoup lire et googler. Heureusement, après avoir passé tant de temps avec ce problème, les manuels techniques et même man openconnect se lisent comme des romans captivants.
En fin de compte, j'ai découvert que vpn-slice, à l'instar du script natif, modifie la table de routage pour diviser les réseaux.
Table de routage
C'est, en résumé, une table dont la première colonne contient le début de l'adresse par laquelle Linux souhaite passer, et la seconde le périphérique réseau à travers lequel passer à cette adresse. En réalité, il y a plus de colonnes, mais cela n'en change pas le sens.
Pour visualiser la table de routage, il faut exécuter la commande 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 Ici, chaque ligne correspond à ce qu'il faut faire pour envoyer un message à une adresse donnée. Le premier élément décrit le début de l'adresse. Pour comprendre comment déterminer que 192.168.0.0/16 signifie que l'adresse doit commencer par 192.168, il faut chercher ce qu'est un masque d'adresse IP. Après dev se trouve le nom de l'adaptateur vers lequel le message doit être envoyé.
Pour le VPN, Linux a créé un adaptateur virtuel — tun0. La ligne suivante garantit que le trafic pour toutes les adresses commençant par 192.168 passe par lui :
192.168.0.0/16 dev tun0 scope link On peut également consulter l'état actuel de la table de routage à l'aide de la commande route -n (les adresses IP ont été habilement anonymisées) Cette commande fournit des résultats sous une forme différente et est en fait obsolète, mais son output apparaît souvent dans des manuels en ligne, et il faut savoir le lire.
Le début d'une adresse IP pour une route peut être compris par la combinaison des colonnes Destination et Genmask. Les parties de l'adresse IP dont les chiffres dans Genmask sont 255 sont prises en compte, tandis que celles où il y a 0 ne le sont pas. Ainsi, une combinaison Destination 192.168.0.0 et Genmask 255.255.255.0 signifie que si l'adresse commence par 192.168.0, la requête passera par cette route. Et si la Destination est 192.168.0.0 mais que le Genmask est 255.255.0.0, alors les requêtes pour les adresses commençant par 192.168 suivront cette route.
Pour comprendre ce que fait réellement vpn-slice, j'ai décidé de comparer les états des tables avant et après.
Avant d'activer le VPN, c'était comme ça :
route -n
Table de routage IP du noyau
Destination Passerelle 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 wlp3s0Après l'appel d'openconnect sans vpn-slice, c'était comme ça.
route -n
Table de routage IP du noyau
Destination Passerelle Masque de réseau Drapeaux Métrique Réf Utiliser Interface
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 tun0Et après avoir appelé openconnect en combinaison avec vpn-slice comme ceci
Table de routage IP du noyau
Destination Passerelle Masque de réseau Drapeaux Métrique Réf Utiliser Interface
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 tun0On voit que si on n'utilise pas vpn-slice, openconnect indique clairement que pour toutes les adresses, sauf celles spécifiées, il faut passer par le vpn.
Voici où :
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Il y a un autre chemin indiqué à proximité, qui doit être utilisé si l'adresse que Linux essaie d'atteindre ne correspond à aucun masque du tableau.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Ici, il est déjà mentionné que dans ce cas, il faut passer par l'adaptateur wifi standard.
Je suppose que le chemin pour le VPN est utilisé parce qu'il est le premier dans la table de routage.
Et théoriquement, si l'on supprime ce chemin par défaut de la table de routage, openconnect devrait assurer un bon fonctionnement en combinaison avec dnsmasq.
J'ai essayé
route del defaultEt tout a fonctionné.
Routage des requêtes vers le serveur de messagerie sans vpn-slice
Mais j'ai également un serveur de messagerie avec l'adresse 555.555.555.555, auquel il faut aussi accéder via le vpn. Il faut aussi ajouter manuellement le chemin vers ce serveur.
ip route add 555.555.555.555 via dev tun0Et maintenant tout est normal. Donc, il est possible de se passer de vpn-slice, mais il faut bien savoir ce que l'on fait. Je pense maintenant à ajouter, dans la dernière ligne du script openconnect, la suppression de la route par défaut et l'ajout de la route pour le serveur de messagerie après la connexion au vpn, juste pour réduire les éléments mobiles dans mon processus.
Peut-être que pour certains, cette postface suffirait pour comprendre comment configurer un VPN. Mais moi, en essayant de comprendre ce que je devais faire, j'ai lu un assez grand nombre de manuels qui fonctionnent pour l'auteur, mais qui ne fonctionnent pas chez moi, et j'ai décidé d'ajouter ici tous les morceaux que j'ai trouvés. J'aurais été très satisfait de quelque chose comme ça.
Source : habr.com
