Vous voulez utiliser Linux au travail, mais pas un VPN d'entreprise? Cet article peut alors vous aider, bien que ce ne soit pas exact. Je tiens à avertir à l'avance que je comprends mal les problèmes d'administration de réseau, il est donc possible que j'ai tout mal fait. D'un autre côté, il est possible que je puisse écrire le manuel de manière à ce qu'il soit compréhensible pour les gens ordinaires, je vous conseille donc de l'essayer.
L'article contient beaucoup d'informations supplémentaires, mais sans cette connaissance, je ne serais pas en mesure de résoudre les problèmes que j'ai subitement rencontrés avec le paramètre vpn. Je pense que quiconque essaie d'appliquer ce manuel aura 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 moi-même.
La plupart des commandes utilisées dans le manuel doivent être exécutées via sudo, qui est supprimé par souci de concision. Gardez à l'esprit.
La plupart des adresses IP ont été gravement obscurcies, 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 que le manuel peut être appliqué à d'autres distributions avec quelques corrections. Cependant, dans ce texte, Linux == Ubuntu.
Cisco connect
Ceux qui sont assis sur Windows ou MacOS peuvent se connecter à notre VPN d'entreprise via Cisco Connect, qui doit spécifier l'adresse de la passerelle et entrer un mot de passe à chaque connexion, composé d'une partie fixe et d'un code généré par Google Authenticator.
Dans le cas de Linux, il n'était pas possible d'obtenir Cisco Connect, mais il s'est avéré google la recommandation d'utiliser openconnect, faite spécifiquement pour remplacer Cisco Connect.
Openconnect
En théorie, dans ubunt, il existe une interface graphique spéciale pour openconnect, mais cela n'a pas fonctionné pour moi. C'est peut-être pour le mieux.
Dans ubunt, openconnect est installé à partir du gestionnaire de paquets.
apt install openconnect
Immédiatement après l'installation, vous pouvez essayer de vous connecter au VPN
openconnect --user poxvuibr vpn.evilcorp.com
vpn.evilcorp.com est l'adresse VPN fictive \
poxvuibr - nom d'utilisateur fictif
openconnect vous demandera d'entrer un mot de passe, qui, je le rappelle, consiste en une partie fixe et un code de Google Authenticator, puis essaie de se connecter à vpn. Si cela s'est avéré, félicitations, vous pouvez sauter en toute sécurité au milieu, ce qui est très douloureux et aller au point sur l'openconnect en arrière-plan. Si cela ne fonctionne pas, vous pouvez continuer. Bien que si cela s'est avéré lors de la connexion, par exemple, à partir d'un Wi-Fi invité au travail, il est possible de se réjouir et tôt, vous devez essayer de répéter la procédure depuis votre domicile.
Attestation
Avec une forte probabilité, rien ne démarre et l'échappement openconnect ressemble à 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 progress
D'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 compréhensible en principe.
Ensuite, le serveur nous a envoyé un certificat, selon lequel il peut être établi que la connexion est établie avec le serveur de la société native, et non avec le fraudeur malveillant, et ce certificat est inconnu du système. Et donc elle ne peut pas vérifier si le vrai serveur l'est ou non. Et donc, juste au cas où, cela cesserait de fonctionner.
Pour qu'encenconnect se connecte toujours au serveur, vous devez lui indiquer explicitement quel certificat doit provenir du serveur VPN à l'aide de la clé --servercert
Et vous pouvez savoir quel certificat le serveur nous a envoyé directement à partir de quel openconnect imprimé. Voici 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 progress
Avec cette commande, vous pouvez essayer de vous reconnecter
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com
Peut-être que ça marche maintenant, alors vous pouvez aller à la fin. Mais Ubunta m'a personnellement 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.com
habr.com sera résolu, mais il ne sera pas possible d'y entrer. Les adresses comme jira.evilcorp.com ne résolvent pas du tout.
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.534
alors les adresses à l'intérieur du VPN se résoudront comme par magie et il sera possible de les parcourir, c'est-à-dire ce que le DNS cherche pour résoudre les adresses se trouve dans /etc/resolv.conf, et pas ailleurs.
Qu'il y ait une connexion au VPN et que cela fonctionne, vous pouvez vous assurer sans changements dans /etc/resolv.conf, pour cela il suffit d'entrer dans le navigateur non pas le nom symbolique de la ressource de vpn, mais son adresse ip
Le résultat est deux problèmes
- lors de la connexion au VPN, son DNS n'est pas pris
- tout le trafic passe par vpn, ce qui ne vous permet pas d'aller sur Internet
Ce que je vais faire maintenant, je vais vous le dire, mais d'abord un peu d'automatisation.
Saisie automatique de la partie fixe du mot de passe
À l'heure actuelle, vous avez probablement déjà entré le mot de passe au moins cinq fois et cette procédure vous a déjà assez fatigué. Premièrement, parce que le mot de passe est long, et deuxièmement, parce que lors de la saisie, vous devez le conserver dans un délai fixe
La solution finale au problème n'était pas incluse dans l'article, mais cela peut être fait pour que la partie fixe du mot de passe ne doive pas être entrée plusieurs fois.
Supposons que la partie fixe du mot de passe soit fixedPassword et une partie de Google Authenticator 567 987. Le mot de passe entier d'openconnect peut être transmis via une entrée standard en utilisant l'argument --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdin
Maintenant, vous pouvez constamment revenir à la dernière commande entrée et y modifier uniquement une partie de Google Authenticator.
Le VPN d'entreprise ne permet pas l'accès à Internet.
En règle générale, il n'est pas très gênant de se rendre sur un hub pour utiliser un ordinateur séparé. Le manque de capacité de copier-coller avec stackoverfow peut généralement paralyser le travail, donc quelque chose doit être fait.
Il est nécessaire d'organiser d'une manière ou d'une autre, de sorte que lorsque vous devez accéder à la ressource à partir du réseau interne, Linux passe à vpn, et lorsque vous devez accéder au concentrateur, il va à Internet.
openconnect après avoir démarré 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 transférées vers le script d'entrée, et il fait la configuration vpn. Malheureusement, je n'ai pas pu comprendre comment répartir les flux de trafic entre le VPN d'entreprise et le reste d'Internet à l'aide d'un script natif.
Apparemment spécialement pour des gens comme moi, l'utilitaire vpn-slice a été développé, qui vous permet de diriger le trafic via deux canaux sans danser avec un tambourin. Eh bien, vous devez danser, mais un chaman n'est pas nécessaire.
Fractionner le trafic avec vpn-slice
Tout d'abord, vpn-slice devra être installé, vous devrez le découvrir par vous-même. S'il y a des questions dans les commentaires, j'écrirai un article séparé à ce sujet. Mais c'est un programme Python normal, donc il ne devrait pas y avoir de difficultés. Je mets en utilisant virtualenv.
Et puis vous devez utiliser l'utilitaire, en utilisant la clé --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
En --script, une ligne est passée avec la commande qui doit être appelée à la place du script. ./bin/vpn-slice - chemin vers le fichier exécutable vpn-slice 192.168.430.0/24 - masque des adresses à visiter dans vpn. Ici, je veux dire que si l'adresse commence par 192.168.430, alors la ressource avec cette adresse doit être recherchée dans vpn
Maintenant, la situation devrait être presque normale. Presque. Vous pouvez maintenant vous connecter au concentrateur et vous pouvez vous connecter à la ressource d'entreprise interne par ip, mais vous ne pouvez pas vous connecter à la ressource d'entreprise interne par nom symbolique. Si vous enregistrez la correspondance du nom et de l'adresse symboliques dans les hôtes, tout devrait fonctionner. Et travaillez jusqu'à ce que l'IP change. Linux peut désormais accéder à Internet ou au réseau d'entreprise, selon l'ip. Mais le DNS non d'entreprise est toujours utilisé pour déterminer l'adresse.
Le problème peut toujours se manifester sous cette forme - tout va bien au travail, et à la maison, vous ne pouvez accéder aux ressources internes de l'entreprise que par 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 sont résolues, bien qu'il soit toujours impossible d'accéder à une telle adresse sans utiliser de VPN.
Modification automatique du fichier hosts
Si vous demandez poliment vpn-slice, puis après avoir augmenté le VPN, il peut accéder à son DNS, y trouver les adresses IP des ressources nécessaires par leurs noms symboliques et les entrer dans les hôtes. Une fois le VPN désactivé, ces adresses seront supprimées des hôtes. Pour ce faire, passez 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
Maintenant, tout devrait fonctionner à la fois au bureau et sur la plage.
Recherchez les adresses de tous les sous-domaines du DNS fournis par le VPN
S'il y a peu d'adresses dans le réseau, alors l'approche avec la modification automatique du fichier hosts fonctionne tout à fait. Mais s'il y a beaucoup de ressources sur le réseau, vous devrez constamment ajouter des lignes comme zoidberg.test.evilcorp.com au script zoidberg, c'est le nom de l'un des bancs d'essai.
Mais maintenant que nous comprenons un peu pourquoi ce besoin peut être éliminé.
Si, après avoir augmenté le VPN, regardez dans / etc / hosts, vous pouvez voir, voici une ligne
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
Oui, et une nouvelle ligne a été ajoutée à resolv.conf. En bref, vpn-slice a en quelque sorte déterminé l'emplacement du serveur DNS pour vpn.
Maintenant, nous devons nous assurer que pour découvrir l'adresse IP du nom de domaine se terminant sur evilcorp.com, Linux est allé au DNS d'entreprise, et si quelque chose d'autre est nécessaire, alors par défaut.
J'ai googlé pendant longtemps et j'ai constaté qu'une telle fonctionnalité est inutilisée hors de la boîte. Cela fait référence à la possibilité d'utiliser le serveur dns dnsmasq local pour résoudre les noms.
Autrement dit, vous pouvez faire en sorte que Linux accède toujours au serveur DNS local pour les adresses IP, qui à son tour, en fonction du nom de domaine, recherchera IP sur le serveur DNS externe correspondant.
Pour gérer tout ce qui concerne les réseaux et les connexions réseau, Ubunt utilise NetworkManager, et l'interface graphique pour sélectionner, par exemple, une connexion Wi-Fi n'est que le devant.
Il faudra grimper dans sa configuration.
- Créer un fichier dans /etc/NetworkManager/dnsmasq.d/evilcorp
adresse = /. evilcorp.com/192.168.430.534
Faites attention au point avant evilcorp. Cela signale à dnsmasq que tous les sous-domaines evilcorp.com doivent être recherchés dans les dns de l'entreprise.
- Dites à NetworkManager d'utiliser dnsmasq pour résoudre les noms
La configuration du gestionnaire de réseau se trouve dans /etc/NetworkManager/NetworkManager.conf Vous devez y ajouter:
[principal]
dns = dnsmasq
- Redémarrez NetworkManager
service network-manager restart
Maintenant, après la connexion à un VPN en utilisant un tas d'openconnect et de vpn-slice, ip sera détecté normalement même si vous n'ajoutez pas d'adresses symboliques aux arguments de vpnslice.
Comment passer par VPN pour séparer les services
Après qu'il s'est avéré qu'il se connectait à vpn, j'étais très heureux pendant deux jours, puis il s'est avéré que si vous vous connectez au VPN depuis l'extérieur du réseau du bureau, le courrier ne fonctionne pas. Un symptôme familier, n'est-ce pas?
Notre courrier est dans mail.publicevilcorp.com, ce qui signifie qu'il ne relève pas de la règle de dnsmasq et que l'adresse du serveur de messagerie est recherchée via le DNS public.
Eh bien, le bureau utilise toujours le DNS dans lequel se trouve cette adresse. Autrement dit, je le pensais. En fait, après avoir ajouté une ligne à dnsmasq
adresse = / mail.publicevilcorp.com / 192.168.430.534
la situation n'a pas changé. ip est resté le même. Je devais aller travailler.
Et seulement alors, quand j'ai fouillé la situation et réglé un peu le problème, une personne intelligente m'a dit comment le résoudre. Il était nécessaire de se connecter au serveur de messagerie non seulement comme ça, mais via vpn
J'utilise vpn-slice pour passer par le VPN aux adresses commençant par 192.168.430. Et sur le serveur de messagerie, non seulement l'adresse symbolique n'est pas un sous-domaine de evilcorp, elle a également une adresse IP qui ne commence pas par 192.168.430. Et bien sûr, il ne laisse personne sortir du réseau général.
Pour que Linux passe par le VPN et le serveur de messagerie, vous devez l'ajouter à vpn-slice. Supposons que l'adresse de l'expéditeur soit 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 élever un VPN avec un argument
Tout cela, bien sûr, n'est pas très pratique. Oui, vous pouvez enregistrer le texte dans un fichier et le copier-coller sur la console, plutôt que de taper avec vos mains, mais ce n'est toujours pas assez agréable. Pour faciliter le processus, vous pouvez encapsuler la commande dans un script qui sera situé dans PATH. Et puis il vous suffit de saisir le code obtenu auprès 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 567987
Mais maintenant, de toute façon, pour une raison quelconque, vous devez garder ouverte la console dans laquelle openconnect fonctionne
Lancement d'Openconnect en arrière-plan
Heureusement, les auteurs d'openconnect ont pris soin de nous et ont ajouté une clé spéciale - arrière-plan au programme, qui fait fonctionner le programme en arrière-plan après son lancement. Si vous l'exécutez comme ceci, après le lancement, vous pouvez fermer la console
#!/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, il n'est pas clair où vont les journaux. Les journaux ne sont généralement pas vraiment nécessaires pour nous, mais vous ne savez jamais. openconnect peut les rediriger vers syslog, où ils seront conservés intacts. vous devez ajouter la clé --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 comment l'arrêter n'est pas clair. Autrement dit, vous pouvez, bien sûr, filtrer l'échappement ps avec un grep et rechercher un processus au nom de openconnect, mais il est en quelque sorte morne. Merci aux auteurs qui y ont réfléchi. Openconnect a la clé --pid-file, avec laquelle vous pouvez demander à openconnect d'écrire son ID 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-pid
Maintenant, vous pouvez toujours clouer le processus avec la commande
kill $(cat ~/vpn-pid)
S'il n'y a pas de processus, kill jurera, mais il ne lancera pas d'erreur. S'il n'y a pas de fichier, il ne se passera rien de mal non plus, vous pouvez donc tuer 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-pid
Vous pouvez maintenant allumer l'ordinateur, ouvrir la console et exécuter la commande, en lui passant le code de Google Authenticator. La console peut alors être clouée.
Sans tranche vpn. Au lieu d'une postface
Il était très difficile de comprendre comment vivre sans vpn-slice. J'ai dû lire beaucoup et google. Heureusement, quand j'ai passé tellement de temps avec le 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
En termes simples, un tel tableau dans la première colonne contient où doit commencer l'adresse où Linux veut aller, et dans la seconde via quelle carte réseau aller à cette adresse. En fait, il y a plus de colonnes, mais cela ne change pas l'essence.
Pour voir 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ù aller afin d'envoyer un message à une adresse. Le premier est une description de l'endroit où l'adresse doit commencer. 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 le masque de l'adresse IP. Après dev est le nom de l'adaptateur auquel le message doit être envoyé.
Pour VPN, Linux a créé un adaptateur virtuel - tun0. Pour que le trafic de toutes les adresses commençant par 192.168 le traverse, la ligne répond
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 route -n (les adresses IP sont douées de manière anonyme) .Cette commande produit des résultats sous une forme différente et est généralement déconseillée, mais son épuisement provient souvent de manuels en ligne et vous devez pouvoir la lire.
L'endroit où l'adresse IP pour l'itinéraire doit commencer peut être compris à partir de la combinaison des colonnes Destination et Genmask. Les parties de l'adresse IP auxquelles correspondent les nombres 255 dans Genmask sont prises en compte, et celles où 0 ne l'est pas. C'est-à-dire que la combinaison de Destination 192.168.0.0 et Genmask 255.255.255.0 signifie que si l'adresse commence par 192.168.0, une demande lui sera envoyée le long de cette route. Et si la destination est 192.168.0.0 mais que Genmask est 255.255.0.0, 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 l'état 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 wlp3s0
Après avoir appelé openconnect sans vpn-slice, il est devenu si
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 tun0
Et 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 tun0
On peut voir que si vous n'utilisez pas vpn-slice, alors openconnect écrit explicitement que vous devez passer par vpn à toutes les adresses sauf indication contraire.
Ici:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0
À proximité, il a immédiatement indiqué un autre chemin à utiliser si l'adresse que Linux essaie de parcourir ne correspond à aucun masque de la table.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0
Il a déjà été écrit ici que dans ce cas, vous devez passer par l'adaptateur Wi-Fi standard.
Je crois que le chemin du VPN est utilisé car il est le premier dans 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 assurer un fonctionnement normal.
J'ai essayé
route del default
Et ça a marché.
Routage des demandes vers un serveur de messagerie sans tranche vpn
Mais j'ai également un serveur de messagerie avec l'adresse 555.555.555.555, dont vous devez également passer par vpn. L'itinéraire doit également être ajouté à la main.
ip route add 555.555.555.555 via dev tun0
Et maintenant toutes les règles. Vous pouvez donc vous passer de vpn-slice, mais vous devez déjà bien savoir ce que vous faites. Je pense maintenant à ajouter la suppression de l'itinéraire par défaut et à ajouter l'itinéraire de l'expéditeur après la connexion à vpn à la dernière ligne du script natif openconnect, juste pour réduire le nombre de pièces mobiles dans mon vélo.
Probablement, quelqu'un pour comprendre comment configurer un VPN aurait assez de cette postface. Mais pendant que j'essayais de comprendre quoi et comment le faire, j'ai lu beaucoup de ces manuels qui fonctionnent pour l'auteur, mais pour une raison quelconque, ils 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 content de quelque chose comme ça.