Vous souhaitez utiliser Linux au travail, mais votre VPN d'entreprise ne vous le permet pas ? Alors cet article peut vous aider, même si ce n’est pas certain. Je voudrais vous prévenir à l'avance que je ne comprends pas bien les problèmes d'administration réseau, il est donc possible que j'aie tout mal fait. D'un autre côté, il est possible que je puisse rédiger un guide de telle manière qu'il soit compréhensible pour les gens ordinaires, je vous conseille donc de l'essayer.
L'article contient de nombreuses informations inutiles, mais sans ces connaissances, je n'aurais pas pu résoudre les problèmes qui me sont apparus de manière inattendue lors de la configuration d'un VPN. Je pense que quiconque essaiera d'utiliser ce guide rencontrera des problèmes que je n'ai pas rencontrés, 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 ce guide doivent être exécutées via sudo, qui a été supprimé par souci de concision. Gardez à l'esprit.
La plupart des adresses IP ont été gravement obscurcies, donc si vous voyez une adresse telle que 435.435.435.435, il doit y avoir une adresse IP normale, spécifique à votre cas.
J'ai Ubuntu 18.04, mais je pense qu'avec des modifications mineures, le guide peut être appliqué à d'autres distributions. Cependant, dans ce texte Linux == Ubuntu.
Connexion Cisco
Ceux qui sont sous Windows ou MacOS peuvent se connecter à notre VPN d'entreprise via Cisco Connect, qui doit préciser l'adresse de la passerelle et, à chaque connexion, saisir 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 faire fonctionner Cisco Connect, mais j'ai réussi à rechercher sur Google une recommandation d'utilisation d'openconnect, spécialement conçue pour remplacer Cisco Connect.
Connexion ouverte
En théorie, Ubuntu dispose d’une interface graphique spéciale pour openconnect, mais cela n’a pas fonctionné pour moi. C'est peut-être pour le mieux.
Sur Ubuntu, openconnect est installé depuis le gestionnaire de packages.
apt install openconnectImmédiatement après l'installation, vous pouvez essayer de vous connecter à un VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com est l'adresse d'un VPN fictif
poxvuibr - nom d'utilisateur fictif
openconnect vous demandera de saisir un mot de passe qui, je vous le rappelle, est constitué d'une partie fixe et d'un code de Google Authenticator, puis il tentera de se connecter au VPN. Si cela fonctionne, félicitations, vous pouvez sauter le milieu en toute sécurité, ce qui est très pénible, et passer au point sur l'exécution d'openconnect en arrière-plan. Si cela ne fonctionne pas, vous pouvez continuer. Bien que si cela a fonctionné lors de la connexion, par exemple, à partir d'un réseau Wi-Fi invité au travail, il est peut-être trop tôt pour se réjouir, vous devriez essayer de répéter la procédure depuis chez vous.
Certificat
Il y a une forte probabilité que rien ne démarre, et la sortie openconnect ressemblera à ceci :
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'une part, c'est désagréable, car il n'y avait pas de connexion au VPN, mais d'autre part, comment résoudre ce problème est en principe clair.
Ici, le serveur nous a envoyé un certificat, grâce auquel nous pouvons déterminer que la connexion est établie avec le serveur de notre société d'origine, et non avec un fraudeur malveillant, et ce certificat est inconnu du système. Et donc elle ne peut pas vérifier si le serveur est réel ou non. Et donc, juste au cas où, il cesserait de fonctionner.
Pour qu'openconnect se connecte au serveur, vous devez lui indiquer explicitement quel certificat doit provenir du serveur VPN à l'aide de la clé —servercert.
Et vous pouvez découvrir quel certificat le serveur nous a envoyé directement à partir de ce qu'openconnect a imprimé. Voici un extrait de cette pièce :
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 progressAvec cette commande, vous pouvez essayer de vous connecter à nouveau
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comPeut-être que maintenant ça marche, alors vous pourrez passer à la fin. Mais personnellement, Ubuntu m'a montré une figue sous cette forme
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 sera résolu, mais vous ne pourrez pas y accéder. Les adresses telles que 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 vous ajoutez la ligne à /etc/resolv.conf
nameserver 192.168.430.534alors les adresses à l'intérieur du VPN commenceront à se résoudre comme par magie et vous pourrez les parcourir, c'est-à-dire que ce que DNS recherche pour résoudre les adresses apparaît spécifiquement dans /etc/resolv.conf, et pas ailleurs.
Vous pouvez vérifier qu'il y a une connexion au VPN et qu'elle fonctionne sans apporter de modifications à /etc/resolv.conf ; pour cela, il suffit de saisir dans le navigateur non pas le nom symbolique de la ressource du VPN, mais son adresse IP.
En conséquence, il y a deux problèmes
- Lors de la connexion à un VPN, son DNS n'est pas récupéré
- tout le trafic passe par VPN, qui ne permet pas l'accès à Internet
Je vais vous dire quoi faire maintenant, mais d'abord un peu d'automatisation.
Saisie automatique de la partie fixe du mot de passe
À ce jour, vous avez probablement déjà saisi votre mot de passe au moins cinq fois et cette procédure vous a déjà fatigué. Premièrement, parce que le mot de passe est long, et deuxièmement, parce que lors de la saisie, vous devez respecter une période de temps déterminée.
La solution finale au problème n'a pas été incluse dans l'article, mais vous pouvez vous assurer que la partie fixe du mot de passe ne doit pas être saisie plusieurs fois.
Supposons que la partie fixe du mot de passe est fixedPassword et que la partie provenant de Google Authenticator est 567 987. Le mot de passe complet peut être transmis à openconnect via l'entrée standard en utilisant l'argument --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinVous pouvez désormais revenir à tout moment à la dernière commande saisie et n'y modifier qu'une partie de Google Authenticator.
Un VPN d'entreprise ne vous permet pas de surfer sur Internet.
En général, ce n'est pas très gênant de devoir utiliser un ordinateur séparé pour accéder à Habr. L'incapacité de copier-coller depuis stackoverfow peut généralement paralyser le travail, il faut donc faire quelque chose.
Nous devons l'organiser d'une manière ou d'une autre de manière à ce que lorsque vous devez accéder à une ressource depuis le réseau interne, Linux aille vers le VPN, et lorsque vous devez accéder à Habr, il aille vers Internet.
openconnect, après avoir lancé et établi une connexion avec VPN, exécute un script spécial, qui se trouve dans /usr/share/vpnc-scripts/vpnc-script. Certaines variables sont transmises au script en entrée et celui-ci configure le VPN. Malheureusement, je n’arrivais pas à comprendre comment répartir les flux de trafic entre un VPN d’entreprise et le reste d’Internet à l’aide d’un script natif.
Apparemment, l'utilitaire VPN-slice a été développé spécialement pour des gens comme moi, ce qui vous permet d'envoyer du trafic via deux canaux sans danser avec un tambourin. Eh bien, vous devrez danser, mais vous n'êtes pas obligé d'être un chaman.
Séparation du trafic à l'aide de VPN-slice
Tout d’abord, vous devrez installer VPN-slice, vous devrez le découvrir vous-même. S'il y a des questions dans les commentaires, j'écrirai un article séparé à ce sujet. Mais il s’agit d’un programme Python classique, il ne devrait donc y avoir aucune difficulté. J'ai installé en utilisant virtualenv.
Et puis l'utilitaire doit être appliqué, à l'aide du commutateur -script, indiquant à openconnect qu'au lieu du script standard, vous devez utiliser 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 reçoit une chaîne avec une commande qui doit être appelée à la place du script. ./bin/vpn-slice - chemin d'accès au fichier exécutable vpn-slice 192.168.430.0/24 - masque d'adresses auxquelles accéder dans VPN. Ici, nous voulons dire que si l'adresse commence par 192.168.430, alors la ressource avec cette adresse doit être recherchée dans le VPN.
La situation devrait désormais être presque normale. Presque. Maintenant, vous pouvez accéder à Habr et accéder à la ressource intra-entreprise par IP, mais vous ne pouvez pas accéder à la ressource intra-entreprise par nom symbolique. Si vous spécifiez une correspondance entre le nom symbolique et l'adresse dans les hôtes, tout devrait fonctionner. Et travaillez jusqu'à ce que l'adresse IP change. Linux peut désormais accéder à Internet ou à l'intranet, selon l'IP. Mais le DNS non professionnel est toujours utilisé pour déterminer l'adresse.
Le problème peut également se manifester sous cette forme : au travail, tout va bien, mais à la maison, vous ne pouvez accéder aux ressources internes de l'entreprise que via IP. En effet, lorsque vous êtes connecté au Wi-Fi d'entreprise, le DNS d'entreprise est également utilisé et les adresses symboliques du VPN y sont résolues, malgré le fait qu'il est toujours impossible d'accéder à une telle adresse sans utiliser un VPN.
Modification automatique du fichier hosts
Si vpn-slice est demandé poliment, alors après avoir lancé le VPN, il peut accéder à son DNS, y trouver les adresses IP des ressources nécessaires par leurs noms symboliques et les saisir dans les hôtes. Après avoir désactivé le VPN, ces adresses seront supprimées des hôtes. Pour ce faire, vous devez transmettre des noms symboliques à vpn-slice comme arguments. Comme ça.
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 Désormais, tout devrait fonctionner aussi bien au bureau qu'à la plage.
Rechercher les adresses de tous les sous-domaines dans le DNS donné par le VPN
S'il y a peu d'adresses sur le réseau, l'approche consistant à modifier automatiquement le fichier hosts fonctionne plutôt bien. Mais s'il y a beaucoup de ressources sur le réseau, alors vous devrez constamment ajouter des lignes comme zoidberg.test.evilcorp.com au script. zoidberg est le nom de l'un des bancs de test.
Mais maintenant que l’on comprend un peu pourquoi ce besoin peut être éliminé.
Si, après avoir augmenté le VPN, vous regardez dans /etc/hosts, vous pouvez voir cette ligne
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCRÉÉ
Et une nouvelle ligne a été ajoutée à resolv.conf. En bref, VPN-slice a déterminé d'une manière ou d'une autre où se trouve le serveur DNS du VPN.
Nous devons maintenant nous assurer que pour connaître l'adresse IP d'un nom de domaine se terminant par evilcorp.com, Linux accède au DNS de l'entreprise, et si quelque chose d'autre est nécessaire, alors au DNS par défaut.
J'ai cherché sur Google pendant un certain temps et j'ai découvert qu'une telle fonctionnalité était disponible immédiatement dans Ubuntu. Cela signifie la possibilité d'utiliser le serveur DNS local dnsmasq pour résoudre les noms.
Autrement dit, vous pouvez vous assurer que Linux accède toujours au serveur DNS local pour les adresses IP, qui à son tour, en fonction du nom de domaine, recherchera l'adresse IP sur le serveur DNS externe correspondant.
Pour gérer tout ce qui concerne les réseaux et les connexions réseau, Ubuntu utilise NetworkManager, et l'interface graphique permettant de sélectionner, par exemple, les connexions Wi-Fi n'en est qu'une façade.
Il faudra monter dans sa configuration.
- Créez un fichier dans /etc/NetworkManager/dnsmasq.d/evilcorp
adresse=/.evilcorp.com/192.168.430.534
Faites attention au point devant evilcorp. Il signale à Dnsmasq que tous les sous-domaines de evilcorp.com doivent être recherchés dans le DNS de l'entreprise.
- Dites à NetworkManager d'utiliser dnsmasq pour la résolution de noms
La configuration du gestionnaire de réseau se trouve dans /etc/NetworkManager/NetworkManager.conf Vous devez y ajouter :
[principal] dns=dnsmasq
- Redémarrer NetworkManager
service network-manager restartDésormais, après vous être connecté à un VPN à l'aide d'openconnect et de vpn-slice, l'adresse IP sera déterminée normalement, même si vous n'ajoutez pas d'adresses symboliques aux arguments de vpnslice.
Comment accéder à des services individuels via VPN
Après avoir réussi à me connecter au VPN, j'ai été très heureux pendant deux jours, puis il s'est avéré que si je me connecte au VPN depuis l'extérieur du réseau du bureau, le courrier ne fonctionne pas. Le symptôme est familier, n'est-ce pas ?
Notre courrier se trouve sur mail.publicevilcorp.com, ce qui signifie qu'il ne relève pas de la règle dnsmasq et que l'adresse du serveur de messagerie est recherchée via le DNS public.
Eh bien, le bureau utilise toujours le DNS, qui contient cette adresse. C'est ce que je pensais. En fait, après avoir ajouté la ligne à dnsmasq
adresse=/mail.publicevilcorp.com/192.168.430.534
la situation n'a pas changé du tout. l'ip est resté le même. Je devais aller travailler.
Et seulement plus tard, lorsque j'ai approfondi la situation et compris un peu le problème, une personne intelligente m'a expliqué comment le résoudre. Il fallait se connecter au serveur de messagerie non seulement comme ça, mais via VPN
J'utilise VPN-slice pour passer par le VPN vers des adresses commençant par 192.168.430. Et le serveur de messagerie possède non seulement une adresse symbolique qui n'est pas un sous-domaine d'Evilcorp, mais il n'a pas non plus d'adresse IP commençant par 192.168.430. Et bien sûr, il ne permet à personne du réseau généraliste de venir le voir.
Pour que Linux puisse passer par le VPN et accéder au serveur de messagerie, vous devez également l'ajouter à VPN-slice. Disons que l'adresse de l'expéditeur 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 augmenter le VPN avec un seul argument
Bien entendu, tout cela n’est 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 ce n'est quand même pas très agréable. Pour faciliter le processus, vous pouvez envelopper la commande dans un script qui sera situé dans PATH. Et puis il vous suffira de saisir le code reçu 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 vous mettez le script dans connect~evilcorp~ vous pouvez simplement écrire dans la console
connect_evil_corp 567987Mais maintenant, vous devez toujours garder ouverte la console dans laquelle openconnect est exécuté pour une raison quelconque
Exécuter openconnect en arrière-plan
Heureusement, les auteurs d'openconnect ont pris soin de nous et ont ajouté une clé spéciale au programme -background, qui permet au programme de fonctionner en arrière-plan après son lancement. Si vous l'exécutez ainsi, vous pouvez 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 tout simplement pas où vont les journaux. En général, nous n’avons pas vraiment besoin de logs, mais on ne sait jamais. openconnect peut les rediriger vers syslog, où ils seront conservés en toute sécurité. vous devez ajouter le commutateur –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 donc, il s’avère qu’openconnect fonctionne quelque part en arrière-plan et ne dérange personne, mais on ne sait pas comment l’arrêter. Autrement dit, vous pouvez bien sûr filtrer la sortie ps à l'aide de grep et rechercher un processus dont le nom contient openconnect, mais cela est en quelque sorte fastidieux. Merci aux auteurs qui y ont pensé aussi. Openconnect possède un fichier de clé -pid, avec lequel vous pouvez demander à openconnect d'écrire son identifiant de 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-pidVous pouvez désormais toujours tuer un processus avec la commande
kill $(cat ~/vpn-pid)S'il n'y a pas de processus, kill maudira, mais ne générera pas d'erreur. Si le fichier n'est pas là, rien de grave ne se produira non plus, vous pouvez donc arrêter le processus en toute sécurité 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-pidVous pouvez maintenant allumer votre ordinateur, ouvrir la console et exécuter la commande en lui transmettant le code de Google Authenticator. La console peut ensuite être clouée.
Sans tranche VPN. Au lieu d'une postface
Il s'est avéré très difficile de comprendre comment vivre sans VPN-Slice. J'ai dû beaucoup lire et chercher sur Google. Heureusement, après avoir passé autant de temps sur un problème, les manuels techniques et même Man OpenConnect se lisent comme des romans passionnants.
En conséquence, j'ai découvert que VPN-slice, comme le script natif, modifie la table de routage pour séparer les réseaux.
Table de routage
Pour faire simple, il s'agit d'un tableau dans la première colonne qui contient par quoi doit commencer l'adresse par laquelle Linux veut passer, et dans la deuxième colonne par quelle carte réseau passer à cette adresse. En fait, il y a plus d'enceintes, mais cela ne change rien à l'essentiel.
Pour afficher la table de routage, vous devez 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 est responsable de l'endroit où vous devez aller pour envoyer un message à une adresse. Le premier est une description de l’endroit où doit commencer l’adresse. Afin de comprendre comment déterminer que 192.168.0.0/16 signifie que l'adresse doit commencer par 192.168, vous devez rechercher sur Google ce qu'est un masque d'adresse IP. Après dev se trouve le nom de l'adaptateur auquel le message doit être envoyé.
Pour VPN, Linux a créé un adaptateur virtuel - tun0. La ligne garantit que le trafic de toutes les adresses commençant par 192.168 passe par elle.
192.168.0.0/16 dev tun0 scope link Vous pouvez également consulter l'état actuel de la table de routage à l'aide de la commande itinéraire -n (Les adresses IP sont intelligemment anonymisées) Cette commande produit des résultats sous une forme différente et est généralement obsolète, mais sa sortie se trouve souvent dans des manuels sur Internet et vous devez pouvoir la lire.
L'endroit où l'adresse IP d'une route doit commencer peut être compris à partir de la combinaison des colonnes Destination et Genmask. Les parties de l'adresse IP qui correspondent aux nombres 255 dans Genmask sont prises en compte, mais celles où il y a 0 ne le sont pas. Autrement dit, la combinaison de la destination 192.168.0.0 et du Genmask 255.255.255.0 signifie que si l'adresse commence par 192.168.0, la demande qui lui sera adressée empruntera cette route. Et si Destination 192.168.0.0 mais Genmask 255.255.0.0, alors les demandes adressées aux adresses commençant par 192.168 suivront cette route
Afin de comprendre ce que fait réellement VPN-slice, j'ai décidé de regarder les états des tables avant et après
Avant d'activer le VPN, c'était comme ça
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 wlp3s0Après avoir appelé openconnect sans VPN-slice, c'est devenu comme ça
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 tun0Et après avoir appelé openconnect en combinaison avec VPN-slice comme celui-ci
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 tun0On peut voir que si vous n'utilisez pas VPN-slice, openconnect écrit explicitement que toutes les adresses, à l'exception de celles spécifiquement indiquées, doivent être accessibles via VPN.
Ici:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Là, à côté, un autre chemin est immédiatement indiqué, qui doit être utilisé si l'adresse par laquelle Linux tente de passer ne correspond à aucun masque de la table.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Il est déjà écrit ici que dans ce cas, vous devez utiliser un adaptateur Wi-Fi standard.
Je pense que le chemin VPN est utilisé car c'est le premier de la table de routage.
Et théoriquement, si vous supprimez ce chemin par défaut de la table de routage, alors en conjonction avec dnsmasq openconnect devrait garantir un fonctionnement normal.
J'ai essayé
route del defaultEt tout a fonctionné.
Routage des requêtes vers un serveur de messagerie sans VPN-slice
Mais j'ai aussi un serveur de messagerie avec l'adresse 555.555.555.555, auquel il faut également accéder via VPN. L'itinéraire vers celui-ci doit également être ajouté manuellement.
ip route add 555.555.555.555 via dev tun0Et maintenant tout va bien. Vous pouvez donc vous passer de VPN-slice, mais vous devez bien savoir ce que vous faites. Je pense maintenant ajouter à la dernière ligne du script openconnect natif la suppression de la route par défaut et l'ajout d'une route pour le mailer après la connexion au VPN, juste pour qu'il y ait moins de pièces mobiles dans mon vélo.
Cette postface suffirait probablement à quelqu’un pour comprendre comment configurer un VPN. Mais pendant que j'essayais de comprendre quoi et comment faire, j'ai lu pas mal de guides de ce type qui fonctionnent pour l'auteur, mais pour une raison quelconque, ne fonctionnent pas pour moi, et j'ai décidé d'ajouter ici toutes les pièces que j'ai trouvées. Je serais très heureux de quelque chose comme ça.
Source: habr.com