Möchten Sie Linux bei der Arbeit verwenden, aber das Unternehmens-VPN lässt es nicht zu? Dann könnte dieser Artikel hilfreich sein, auch wenn ich mir da nicht ganz sicher bin. Ich möchte vorab warnen, dass ich nicht gut in Netzweradministration bin, weshalb es sein kann, dass ich alles falsch gemacht habe. Andererseits könnte es sein, dass ich in der Lage bin, eine Anleitung zu schreiben, die für normale Menschen verständlich ist, also empfehle ich, es auszuprobieren.
Der Artikel enthält viele überflüssige Informationen, aber ohne dieses Wissen hätte ich die Probleme, die unerwartet beim Einrichten des VPN aufgetreten sind, nicht lösen können. Ich denke, dass jeder, der versucht, diese Anleitung anzuwenden, auf Probleme stoßen wird, die ich nicht hatte, und ich hoffe, dass diese überflüssigen Informationen helfen, diese Probleme selbst zu lösen.
Die meisten Befehle, die in der Anleitung verwendet werden, müssen über sudo ausgeführt werden, was der Kürze halber weggelassen wurde. Bitte beachten Sie dies.
Die meisten IP-Adressen wurden stark obfuskiert, daher, wenn Sie eine Adresse wie 435.435.435.435 sehen, sollte dort eine normale IP-Adresse sein, die spezifisch für Ihren Fall ist.
Ich benutze Ubuntu 18.04, aber ich denke, dass die Anleitung mit kleinen Anpassungen auch für andere Distributionen funktionieren kann. In diesem Text bedeutet Linux jedoch == Ubuntu.
Cisco Connect
Benutzer von Windows oder MacOS können sich über Cisco Connect mit unserem Unternehmens-VPN verbinden, für das die Gateway-Adresse angegeben werden muss und bei jeder Verbindung ein Passwort eingegeben werden muss, das aus einem festen Teil und einem von Google Authenticator generierten Code besteht.
Im Fall von Linux ließ sich Cisco Connect nicht einrichten, aber ich fand die Empfehlung, openconnect zu verwenden, das speziell dafür entwickelt wurde, Cisco Connect zu ersetzen.
Openconnect
Technisch gibt es in Ubuntu eine spezielle grafische Oberfläche für openconnect, aber bei mir hat sie nicht funktioniert. Vielleicht ist das auch ganz gut so.
In Ubuntu wird openconnect über den Paketmanager installiert.
apt install openconnectDirekt nach der Installation können Sie versuchen, sich mit dem VPN zu verbinden.
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com ist die Adresse eines fiktiven VPNs.
poxvuibr ist der Name eines fiktiven Benutzers.
openconnect wird nach einem Passwort fragen, das aus einem festen Teil und einem Code aus Google Authenticator besteht, und dann versuchen, eine Verbindung zum VPN herzustellen. Wenn es funktioniert hat, herzlichen Glückwunsch, Sie können getrost die schmerzhafte Mitte überspringen und zum Punkt über den Betrieb von openconnect im Hintergrund übergehen. Wenn es nicht funktioniert hat, können Sie fortfahren. Obwohl, wenn es bei der Verbindung über zum Beispiel das Gäste-WLAN bei der Arbeit funktioniert hat, könnte es zu früh sein, sich zu freuen, Sie sollten versuchen, das Verfahren von zu Hause aus zu wiederholen.
Zertifikat
Mit hoher Wahrscheinlichkeit wird nichts starten, und die Ausgabe von openconnect wird etwa so aussehen:
POST https://vpn.evilcorp.com/
Verbunden mit 777.777.777.777:443
SSL-Aushandlung mit vpn.evilcorp.com
Serverzertifikat-Überprüfung fehlgeschlagen: Signer nicht gefunden
Zertifikat vom VPN-Server "vpn.evilcorp.com" hat die Überprüfung nicht bestanden.
Grund: Signer nicht gefunden
Um diesem Server in Zukunft zu vertrauen, fügen Sie vielleicht Folgendes zu Ihrer Befehlszeile hinzu:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Geben Sie 'yes' ein, um zu akzeptieren, 'no' um abzubrechen; alles andere, um anzuzeigen: fgets (stdin): Operation läuft jetzt.Einerseits ist es unangenehm, da keine VPN-Verbindung hergestellt wurde, aber andererseits ist im Grunde klar, wie man dieses Problem löst.
Hier hat der Server uns ein Zertifikat gesendet, anhand dessen man feststellen kann, dass die Verbindung tatsächlich zum Server der eigenen Firma und nicht zu einem bösen Betrüger hergestellt wird, aber das System kennt dieses Zertifikat nicht. Daher kann es nicht überprüfen, ob es sich um den echten Server handelt oder nicht. Und aus diesem Grund bricht es vorsichtshalber die Verbindung ab.
Um sicherzustellen, dass openconnect sich doch mit dem Server verbindet, müssen Sie ihm explizit sagen, welches Zertifikat vom VPN-Server kommen soll, indem Sie den Schlüssel --servercert verwenden.
Um herauszufinden, welches Zertifikat uns der Server gesendet hat, können wir direkt aus dem, was openconnect ausgegeben hat, lesen. Hier ist der relevante Abschnitt:
Um diesem Server in Zukunft zu vertrauen, fügen Sie vielleicht Folgendes zu Ihrer Befehlszeile hinzu:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Geben Sie 'yes' ein, um zu akzeptieren, 'no' um abzubrechen; alles andere, um anzuzeigen: fgets (stdin): Operation läuft jetzt.Mit diesem Befehl können Sie versuchen, sich erneut zu verbinden.
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comVielleicht hat es jetzt funktioniert, dann können Sie zum Schluss übergehen. Aber persönlich hat Ubuntu mir hier einen Korb gegeben.
POST https://vpn.evilcorp.com/
Verbunden mit 777.777.777.777:443
SSL-Verhandlung mit vpn.evilcorp.com
Serverzertifikat verifiziert nicht: Signator nicht gefunden
Verbunden mit HTTPS auf vpn.evilcorp.com
XML POST aktiviert
Bitte geben Sie Ihren Benutzernamen und Ihr Passwort ein.
POST https://vpn.evilcorp.com/
Erhaltene CONNECT-Antwort: HTTP/1.1 200 OK
CSTP verbunden. DPD 300, Keepalive 30
Einrichtung von DTLS fehlgeschlagen; SSL wird stattdessen verwendet
Verbunden als 192.168.333.222, verwendet SSL
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
RTNETLINK-Antworten: Datei existiert
/etc/resolvconf/update.d/libc: Warnung: /etc/resolv.conf ist kein symbolischer Link zu /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 wird aufgelöst, aber der Zugang dorthin ist nicht möglich. Adressen wie jira.evilcorp.com werden überhaupt nicht aufgelöst.
Was hier passiert ist, kann ich nicht nachvollziehen. Aber das Experiment zeigt, dass, wenn man in /etc/resolv.conf die Zeile hinzufügt
nameserver 192.168.430.534die Adressen innerhalb des VPNs auf magische Weise aufgelöst werden und man darauf zugreifen kann, das heißt, dass das, was sucht, um Adressen mit welchen DNS aufzulösen, tatsächlich in /etc/resolv.conf schaut und nicht irgendwo anders.
Dass die Verbindung zum VPN besteht und funktioniert, kann man auch ohne Änderungen an /etc/resolv.conf überprüfen, dazu reicht es, im Browser nicht den symbolischen Namen der Ressource aus dem VPN einzugeben, sondern die IP-Adresse.
Am Ende ergeben sich zwei Probleme
- beim Verbinden mit dem VPN wird dessen DNS nicht übernommen
- aller Verkehr läuft über das VPN, das keinen Internetzugang erlaubt
Was zu tun ist, werde ich jetzt erklären, aber zuerst etwas Automatisierung.
Automatische Eingabe des festen Teils des Passworts
Zu diesem Zeitpunkt haben Sie vermutlich das Passwort mindestens fünf Mal eingegeben und dieses Verfahren hat Sie bereits erheblich gelangweilt. Erstens, weil das Passwort lang ist, zweitens, weil man beim Eingeben in einem festen Zeitrahmen bleiben muss.
Eine endgültige Lösung des Problems kam nicht in den Artikel, aber man kann es so einrichten, dass der feste Teil des Passworts nicht mehrere Male eingegeben werden muss.
Angenommen, der feste Teil des Passworts ist fixedPassword, und der Teil aus Google Authenticator ist 567 987. Das gesamte Passwort kann bei openconnect über die Standard-Eingabe mit dem Argument --passwd-on-stdin übergeben werden.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinJetzt kann man ständig zur zuletzt eingegebenen Kommandzeile zurückkehren und dort nur den Teil aus Google Authenticator ändern.
Der Unternehmens-VPN erlaubt keinen Internetzugang.
Es ist überhaupt nicht sehr praktisch, wenn man einen separaten Computer verwenden muss, um auf Habr zuzugreifen. Die fehlende Möglichkeit, von stackoverflow zu kopieren, kann die Arbeit insgesamt lähmen, deshalb muss man etwas unternehmen.
Es muss irgendwie organisiert werden, dass bei Bedarf auf die Ressource aus dem internen Netzwerk Linux über VPN geht, und wenn man auf Habr zugreifen will, ins Internet geht.
Openconnect führt nach dem Start und dem Herstellen der Verbindung mit dem VPN ein spezielles Skript aus, das sich in /usr/share/vpnc-scripts/vpnc-script befindet. Einige Variablen werden an das Skript übergeben, und es konfiguriert das VPN. Leider konnte ich nicht herausfinden, wie man den Datenverkehr zwischen dem Unternehmens-VPN und dem restlichen Internet mit dem Standard-Skript trennt.
Offensichtlich wurde für solche wie mich das Tool vpn-slice entwickelt, das es ermöglicht, den Datenverkehr über zwei Kanäle ohne großen Aufwand zu leiten. Na ja, man muss schon etwas Aufwand betreiben, aber man muss dabei kein Schamane sein.
Trennung des Datenverkehrs mit vpn-slice
Zuerst muss vpn-slice installiert werden, damit muss man sich selbst auseinandersetzen. Wenn dazu Fragen in den Kommentaren auftauchen, werde ich einen separaten Beitrag dazu schreiben. Aber es ist ein gewöhnliches Programm in Python, daher sollte es keine Schwierigkeiten geben. Ich habe es mit virtualenv installiert.
Dann muss das Tool angewendet werden, indem man mit dem Schlüssel —script openconnect angibt, dass anstelle des Standard-Skripts vpn-slice verwendet werden soll.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script ".\/bin\/vpn-slice 192.168.430.0\/24 " vpn.evilcorp.com In —script wird der Befehl übergeben, der anstelle des Skripts aufgerufen werden soll. .\/bin\/vpn-slice — der Pfad zur ausführbaren Datei vpn-slice 192.168.430.0\/24 — die Adressmaske, über die man ins VPN gehen soll. Hier ist gemeint, dass wenn die Adresse mit 192.168.430 beginnt, die Ressource mit dieser Adresse im VPN gesucht werden sollte.
Nun sollte die Situation fast normal sein. Fast. Jetzt kann man auf Habr zugreifen und auf die interne Ressource über IP zugreifen, aber man kann nicht auf die interne Ressource über den symbolischen Namen zugreifen. Wenn man die Entsprechung des symbolischen Namens und der Adresse in hosts einträgt, sollte alles funktionieren. Und das funktioniert, bis sich die IP ändert. Linux kann jetzt je nach IP ins Internet oder ins Unternehmensnetzwerk gehen. Aber zur Adressbestimmung wird immer noch nicht der Unternehmens-DNS verwendet.
Das Problem kann sich auch so äußern – im Büro funktioniert alles normal, aber von zu Hause aus kann man auf interne Unternehmensressourcen nur über die IP-Adresse zugreifen. Das liegt daran, dass wenn du mit dem Unternehmens-WLAN verbunden bist, auch der DNS-Server corporate verwendet wird, und dort die symbolischen Adressen aus dem VPN aufgelöst werden, obwohl man über eine solche Adresse ohne VPN nach wie vor nicht zugreifen kann.
Automatische Modifikation der hosts-Datei
Wenn man vpn-slice höflich darum bittet, kann er nach dem Aufbau des VPNs in dessen DNS gehen, dort die IP-Adressen der benötigten Ressourcen anhand ihrer symbolischen Namen finden und in hosts eintragen. Nach dem Ausschalten des VPNs werden diese Adressen aus hosts entfernt. Dafür müssen die symbolischen Namen als Argumente an vpn-slice übergeben werden. So geht das.
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 Jetzt sollte alles sowohl im Büro als auch am Strand funktionieren.
Adressen aller Subdomains im DNS suchen, das von VPN bereitgestellt wurde.
Wenn es nicht viele Adressen im Netzwerk gibt, dann ist der Ansatz mit der automatischen Modifikation der hosts-Datei durchaus praktikabel. Aber wenn es viele Ressourcen im Netzwerk gibt, muss man ständig Zeilen wie zoidberg.test.evilcorp.com zum Skript hinzufügen; Zoidberg ist der Name einer der Testumgebungen.
Aber jetzt, da wir ein wenig verstehen, worum es geht, kann man diese Notwendigkeit beseitigen.
Wenn man nach dem Aufbau des VPNs in /etc/hosts schaut, sieht man so eine Zeile:
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
Außerdem wurde eine neue Zeile in resolv.conf hinzugefügt. Kurz gesagt, vpn-slice hat irgendwie bestimmt, wo sich der DNS-Server für das VPN befindet.
Jetzt muss man so einstellen, dass Linux für die Ermittlung der IP-Adresse eines Domainnamens, der auf evilcorp.com endet, den Unternehmens-DNS abfragt und für alles andere den Standard-DNS.
Ich habe ziemlich lange gegoogelt und herausgefunden, dass eine solche Funktionalität in Ubuntu standardmäßig vorhanden ist. Die Möglichkeit, den lokalen DNS-Server dnsmasq für die Namensauflösung zu verwenden.
Das heißt, man kann es so machen, dass Linux immer beim lokalen DNS-Server nach IP-Adressen fragt, der wiederum je nach Domainnamen auf dem entsprechenden externen DNS-Server nach IP sucht.
Zur Verwaltung aller Aspekte von Netzwerken und Netzwerkverbindungen in Ubuntu wird NetworkManager verwendet, und die grafische Benutzeroberfläche zur Auswahl, z. B. einer WLAN-Verbindung, ist einfach ein Frontend dafür.
Wir müssen seine Konfiguration durchsehen.
- Eine Datei in /etc/NetworkManager/dnsmasq.d/evilcorp erstellen
address=/evilcorp.com/192.168.430.534
Beachte den Punkt vor evilcorp. Er signalisiert dnsmasq, dass alle Subdomains von evilcorp.com im Unternehmens-DNS gesucht werden sollen.
- NetworkManager sagen, dass zur Namensauflösung dnsmasq verwendet werden soll
Die Konfiguration des network-manager befindet sich in /etc/NetworkManager/NetworkManager.conf. Dort muss Folgendes hinzugefügt werden:
[main]
dns=dnsmasq
- NetworkManager neu starten
service network-manager restartJetzt wird die IP nach dem Anschluss an VPN mit dem Bündel openconnect und vpn-slice korrekt erkannt, selbst wenn symbolische Adressen nicht als Argumente an vpnslice hinzugefügt werden.
Wie man über VPN auf bestimmte Dienste zugreift
Nachdem ich mich zwei Tage lang darüber gefreut hatte, dass ich mich mit VPN verbinden konnte, stellte ich fest, dass die E-Mails nicht funktionieren, wenn ich mich nicht aus dem Büro-Netzwerk verbinde. Ein bekanntes Symptom, nicht wahr?
Unsere E-Mails befinden sich unter mail.publicevilcorp.com, was bedeutet, dass sie nicht unter die Regel in dnsmasq fallen und die Adresse des Mailservers über das öffentliche DNS gesucht wird.
Aber im Büro wird dennoch das DNS verwendet, welches diese Adresse enthält. So dachte ich zumindest. Tatsächlich, nach dem Hinzufügen der Zeile in dnsmasq
address=/mail.publicevilcorp.com/192.168.430.534
hat sich die Situation nicht geändert. Die IP blieb die gleiche. Ich musste zur Arbeit gehen.
Erst als ich mich intensiver mit der Situation befasste und das Problem ein wenig verstand, gab mir eine kluge Person den Hinweis, wie man es löst. Ich musste mich nicht einfach mit dem Mailserver verbinden, sondern über VPN.
Ich verwende vpn-slice, um über VPN zu Adressen zuzugreifen, die mit 192.168.430 beginnen. Der Mailserver hat nicht nur keinen symbolischen Adresse als Subdomain von evilcorp, sein IP-Adresse beginnt auch nicht mit 192.168.430. Und aus dem allgemeinen Netzwerk lässt er natürlich niemanden zu.
Um sicherzustellen, dass Linux sowohl über VPN als auch auf den Mailserver zugreift, muss ich ihn zu vpn-slice hinzufügen. Angenommen, die Adresse des Mailservers ist 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 Skript zur Aktivierung von VPN mit einem Argument
Das ist natürlich nicht sehr bequem. Ja, man kann den Text in eine Datei speichern und in die Konsole kopieren, anstatt ihn von Hand einzugeben, aber angenehm ist das trotzdem nicht. Um den Prozess zu erleichtern, kann der Befehl in ein Skript eingepackt werden, das sich im PATH befindet. Dann muss man nur noch den Code eingeben, der aus Google Authenticator stammt.
#!/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 Wenn das Skript in connect~evilcorp~ platziert wird, kann man einfach in der Konsole schreiben.
connect_evil_corp 567987Jetzt muss die Konsole, in der openconnect läuft, jedoch trotzdem geöffnet bleiben.
openconnect im Hintergrund ausführen
Zum Glück haben die Autoren von openconnect an uns gedacht und einen speziellen Schalter —background hinzugefügt, der dafür sorgt, dass das Programm nach dem Start im Hintergrund weiterläuft. Wenn man es so startet, kann die Konsole nach dem Start geschlossen werden.
#!/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 Jetzt ist nur noch unklar, wohin die Logs gehen. Die Logs sind uns eigentlich nicht sehr wichtig, aber man weiß ja nie. openconnect kann sie ins syslog umleiten, wo sie sicher aufbewahrt werden. Das muss man einfach in den Befehl mit dem Schalter —syslog hinzufügen.
#!/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 Und so funktioniert openconnect irgendwo im Hintergrund und stört niemanden, aber wie man es stoppen kann, ist unklar. Man könnte natürlich die Ausgabe von ps filtern und nach einem Prozess suchen, dessen Name openconnect enthält, aber das ist etwas mühsam. Danke an die Autoren, die auch daran gedacht haben. In openconnect gibt es den Schalter —pid-file, mit dem man openconnect anweisen kann, die Prozess-ID in eine Datei zu schreiben.
#!/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-pidJetzt kann man den Prozess immer mit dem Befehl
kill $(cat ~/vpn-pid)Wenn der Prozess nicht vorhanden ist, wird kill sich beschweren, aber keinen Fehler auslösen. Wenn die Datei nicht vorhanden ist, passiert auch nichts Schlimmes, sodass man den Prozess ruhig in der ersten Zeile des Skripts beenden kann.
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-pidJetzt kann der Computer eingeschaltet, die Konsole geöffnet und der Befehl ausgeführt werden, wobei der Code aus Google Authenticator übergeben wird. Die Konsole kann danach beendet werden.
Ohne vpn-slice. Statt eines Nachworts.
Es stellte sich als sehr schwierig heraus, zu verstehen, wie man ohne vpn-slice lebt. Ich musste viel lesen und googeln. Glücklicherweise liest man, nachdem man so viel Zeit mit dem Problem verbracht hat, technische Handbücher und sogar man openconnect wie fesselnde Romane.
Letztendlich stellte ich fest, dass vpn-slice, wie das ursprüngliche Skript, zur Aufteilung von Netzwerken die Routingtabelle modifiziert.
Routingtabelle
Vereinfacht gesagt handelt es sich um eine Tabelle, in der in der ersten Spalte steht, mit welcher Adresse Linux beginnen soll, und in der zweiten, über welchen Netzwerkadapter es diese Adresse erreichen soll. Tatsächlich gibt es mehr Spalten, aber das ändert nichts an der Sache.
Um die Routingtabelle anzusehen, muss man den Befehl ip route ausführen.
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 Jede Zeile hier beschreibt, wohin man gehen muss, um eine Nachricht an eine bestimmte Adresse zu senden. Zuerst kommt die Beschreibung, von wo die Adresse beginnen sollte. Um zu verstehen, dass 192.168.0.0/16 bedeutet, dass die Adresse mit 192.168 beginnen sollte, muss man nach einer IP-Adressmaske googeln. Nach dev steht der Name des Adapters, an den die Nachricht gesendet werden muss.
Für VPN hat Linux einen virtuellen Adapter erstellt – tun0. Die Zeile, die dafür sorgt, dass der Verkehr für alle Adressen, die mit 192.168 beginnen, über diesen läuft, lautet
192.168.0.0/16 dev tun0 scope link Um den aktuellen Status der Routingtabelle anzuzeigen, kann man auch den Befehl verwenden. route -n (IP-Adressen wurden gekonnt anonymisiert) Dieser Befehl gibt die Ergebnisse in einer anderen Form aus und ist insgesamt veraltet, aber seine Ausgabe findet man oft in Handbüchern im Internet und man muss lernen, sie zu lesen.
Woraus die IP-Adresse für die Route beginnen sollte, kann man aus der Kombination der Spalten Destination und Genmask erkennen. Die Teile der IP-Adresse, denen in Genmask die Zahl 255 entspricht, werden berücksichtigt, während die, wo 0 steht, nicht beachtet werden. Das bedeutet, dass die Kombination Destination 192.168.0.0 und Genmask 255.255.255.0 bedeutet, dass Anfragen, die mit 192.168.0 beginnen, über diese Route geleitet werden. Wenn jedoch die Destination 192.168.0.0 mit einer Genmask von 255.255.0.0 vorliegt, gehen die Anfragen an Adressen, die mit 192.168 beginnen, über diese Route.
Um zu verstehen, was vpn-slice tatsächlich macht, beschloss ich, die Zustände der Tabellen vor und nach dem Einsatz zu betrachten.
Vor dem Aktivieren von VPN sah es so aus.
route -n
Kernel-IP-Routingtabelle
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 wlp3s0Nach dem Aufruf von openconnect ohne vpn-slice war es so.
route -n
Kernel IP-Routing-Tabelle
Ziel 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 tun0Und nach dem Aufruf von openconnect in Kombination mit vpn-slice so
Kernel IP-Routing-Tabelle
Ziel 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 ist offensichtlich, dass, wenn vpn-slice nicht verwendet wird, openconnect eindeutig angibt, dass für alle Adressen, außer für die ausdrücklich angegebenen, über VPN gegangen werden muss.
Hier:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Dort wird sofort ein weiterer Pfad angegeben, der verwendet werden muss, wenn die Adresse, zu der Linux zu gelangen versucht, mit keiner Maske aus der Tabelle übereinstimmt.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Hier steht bereits geschrieben, dass in diesem Fall über den Standard-WLAN-Adapter gegangen werden muss.
Ich nehme an, dass der Pfad für VPN verwendet wird, weil er in der Routingtabelle zuerst kommt.
Und theoretisch, wenn dieser Standardpfad aus der Routingtabelle entfernt wird, dann sollte openconnect in Verbindung mit dnsmasq normal funktionieren.
Ich habe versucht
route del defaultUnd alles hat funktioniert.
Routing von Anfragen an den Mailserver ohne vpn-slice
Aber ich habe auch einen Mailserver mit der Adresse 555.555.555.555, den ich ebenfalls über VPN erreichen muss. Die Route dorthin muss ich auch manuell hinzufügen.
ip route add 555.555.555.555 via dev tun0Und jetzt ist alles in Ordnung. Man kann also ohne vpn-slice auskommen, aber man muss schon gut wissen, was man tut. Ich denke darüber nach, in die letzte Zeile des originalen openconnect-Skripts das Löschen der Standardroute und das Hinzufügen der Route für den Mailserver nach der Verbindung zum VPN aufzunehmen, nur um die beweglichen Teile in meinem Fahrrad zu minimieren.
Vielleicht reicht es einigen, um zu verstehen, wie man ein VPN einrichtet, diesem Nachsatz. Aber während ich versuchte zu verstehen, was ich tun sollte, habe ich viele solcher Anleitungen gelesen, die für den Autor funktionieren, aber aus irgendeinem Grund nicht für mich. Deshalb habe ich beschlossen, hier alle Fragmente zusammenzustellen, die ich gefunden habe. Darüber hätte ich mich sehr gefreut.
Quelle: habr.com
