Möchten Sie Linux bei der Arbeit nutzen, aber das Unternehmens-VPN lässt es nicht zu? Dann könnte dieser Artikel helfen, auch wenn ich mir nicht sicher bin. Ich möchte vorab warnen, dass ich nicht gut im Netzwerkmanagement bin, also ist es möglich, dass ich alles falsch gemacht habe. Auf der anderen Seite könnte ich in der Lage sein, eine Anleitung zu schreiben, die auch für normale Nutzer verständlich ist, also empfehle ich, es einfach auszuprobieren.
Im Artikel gibt es viele Informationen, die nicht unbedingt notwendig sind, aber ohne dieses Wissen hätte ich die Probleme, die plötzlich beim Einrichten des VPN auftraten, nicht lösen können. Ich denke, jeder, der versucht, diese Anleitung zu befolgen, wird auf Probleme stoßen, die ich nicht hatte, und ich hoffe, dass diese zusätzlichen Informationen helfen, diese Probleme selbst zu lösen.
Die meisten Befehle in der Anleitung müssen über sudo ausgeführt werden, was der Kürze halber weggelassen wurde. Bitte beachten Sie das.
Die meisten IP-Adressen wurden stark obfuskiert, also wenn Sie eine Adresse wie 435.435.435.435 sehen – dort sollte eine normale IP-Adresse sein, die spezifisch für Ihren Fall ist.
Ich habe Ubuntu 18.04, denke jedoch, dass die Anleitung mit kleinen Anpassungen auch für andere Distributionen anwendbar ist. In diesem Text steht Linux jedoch für Ubuntu.
Cisco Connect
Benutzer von Windows oder MacOS können sich über Cisco Connect mit unserem Firmennetzwerk-VPN verbinden. Hierbei muss die Gateway-Adresse angegeben werden und bei jedem Verbindungsaufbau ist ein Passwort einzugeben, das aus einem festen Teil und einem durch Google Authenticator generierten Code besteht.
Für Linux hat es nicht funktioniert, Cisco Connect einzurichten, aber ich habe die Empfehlung gefunden, openconnect zu verwenden, das speziell entwickelt wurde, um Cisco Connect zu ersetzen.
Openconnect
In Ubuntu sollte es eine spezielle grafische Benutzeroberfläche für openconnect geben, aber bei mir hat sie nicht funktioniert. Vielleicht ist das auch besser so.
In Ubuntu wird openconnect über den Paketmanager installiert.
apt install openconnectDirekt nach der Installation kann man versuchen, sich mit dem VPN zu verbinden.
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com ist die Adresse eines fiktiven VPNs.
poxvuibr ist ein fiktiver Benutzername.
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, gratuliere ich Ihnen, Sie können den schmerzhaften Teil überspringen und direkt zum nächsten Punkt über die Hintergrundfunktion von openconnect gehen. Wenn es nicht funktioniert hat, können Sie fortfahren. Es könnte jedoch ratenswert sein, die Verbindung erneut von zu Hause aus zu überprüfen, falls beispielsweise die Verbindung über das Gast-WLAN am Arbeitsplatz geklappt hat.
Zertifikat
Mit hoher Wahrscheinlichkeit wird nichts gestartet, und die Ausgabe von openconnect wird etwa so aussehen:
POST https://vpn.evilcorp.com/
Verbunden mit 777.777.777.777:443
SSL-Verhandlung mit vpn.evilcorp.com
Zertifikat des Servers konnte nicht verifiziert werden: Unterzeichner nicht gefunden
Zertifikat vom VPN-Server "vpn.evilcorp.com" hat die Überprüfung nicht bestanden.
Grund: Unterzeichner nicht gefunden
Um diesem Server in Zukunft zu vertrauen, fügen Sie möglicherweise Folgendes zu Ihrer Befehlszeile hinzu:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Geben Sie 'ja' ein, um zu akzeptieren, 'nein', um abzubrechen; alles andere, um anzuzeigen: fgets (stdin): Vorgang ist jetzt im Gange.Einerseits ist es unangenehm, da keine VPN-Verbindung hergestellt werden konnte, andererseits ist im Grunde klar, wie man dieses Problem beheben kann.
Hier hat der Server uns ein Zertifikat gesendet, mit dem festgestellt werden kann, dass die Verbindung tatsächlich zum Server des ursprünglichen Unternehmens und nicht zu einem böswilligen Betrüger erfolgt. Das System kennt dieses Zertifikat jedoch nicht. Daher kann es nicht überprüfen, ob der Server echt ist. Aus diesem Grund wird die Verbindung vorsichtshalber abgebrochen.
Damit openconnect trotzdem eine Verbindung zum Server herstellen kann, muss explizit angegeben werden, welches Zertifikat vom VPN-Server erwartet wird, mithilfe des Schlüssels —servercert.
Um herauszufinden, welches Zertifikat uns der Server gesendet hat, kann man direkt aus dem, was openconnect ausgegeben hat, entnehmen. Hier ist der relevante Abschnitt:
Um diesem Server in Zukunft zu vertrauen, fügen Sie möglicherweise Folgendes zu Ihrer Befehlszeile hinzu:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Geben Sie 'yes' ein, um zu akzeptieren, 'no', um abzubrechen; alles andere, um anzuzeigen: fgets (stdin): Vorgang läuft jetzt.Mit folgendem Befehl können Sie es erneut versuchen, sich zu verbinden:
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comVielleicht funktioniert es jetzt, dann können wir zum Ende übergehen. Aber persönlich hat mir Ubuntu sozusagen die kalte Schulter gezeigt.
POST https://vpn.evilcorp.com/
Verbunden mit 777.777.777.777:443
SSL-Verhandlung mit vpn.evilcorp.com
Serverzertifikat Überprüfung fehlgeschlagen: Signer nicht gefunden
Mit HTTPS auf vpn.evilcorp.com verbunden
XML POST aktiviert
Bitte geben Sie Ihren Benutzernamen und Ihr Passwort ein.
POST https://vpn.evilcorp.com/
Erhielt CONNECT-Antwort: HTTP/1.1 200 OK
CSTP verbunden. DPD 300, Keepalive 30
DTLS-Setup fehlgeschlagen; verwende stattdessen SSL
Verbunden als 192.168.333.222, verwende SSL
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
RTNETLINK antwortet: 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 Zugriff ist nicht möglich. Adressen wie jira.evilcorp.com werden überhaupt nicht aufgelöst.
Was hier passiert ist, ist mir unklar. Aber das Experiment zeigt, dass, wenn man die Zeile in /etc/resolv.conf hinzufügt,
nameserver 192.168.430.534, die Adressen innerhalb des VPNs auf wundersame Weise aufgelöst werden und sie aufgerufen werden können. Das heißt, das, was nach DNS sucht, um Adressen aufzulösen, schaut genau in /etc/resolv.conf und nicht woanders.
Dass die Verbindung zum VPN besteht und funktioniert, kann man auch ohne Änderungen in /etc/resolv.conf überprüfen. Dazu genügt es, in den Browser nicht den symbolischen Namen der Ressource aus dem VPN, sondern dessen IP-Adresse einzugeben.
Am Ende ergeben sich zwei Probleme:
- bei der Verbindung zum VPN wird deren DNS nicht übernommen.
- aller Verkehr läuft über das VPN, welches den Zugriff auf das Internet nicht erlaubt.
Ich werde Ihnen jetzt erklären, was zu tun ist, aber zunächst ein wenig über Automatisierung.
Automatischer Eingabe der festen Passwortkomponente
Inzwischen haben Sie wahrscheinlich das Passwort mindestens fünfmal eingegeben, und diese Prozedur hat Sie bereits genug ermüdet. Erstens, weil das Passwort lang ist, und zweitens, weil Sie beim Eingeben in einen festen Zeitrahmen passen müssen.
Die endgültige Lösung des Problems ist nicht im Artikel enthalten, aber es gibt Möglichkeiten, die feste Passwortkomponente nicht mehrfach eingeben zu müssen.
Angenommen, die feste Passwortkomponente ist – fixedPassword, und der Teil aus Google Authenticator ist 567 987. Das gesamte Passwort openconnect kann über den Standard-Eingang mit dem Argument –passwd-on-stdin übergeben werden.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinJetzt können Sie immer wieder zur zuletzt eingegebenen Zeile zurückkehren und nur den Teil aus Google Authenticator ändern.
Der Unternehmens-VPN erlaubt keinen Zugang zum Internet.
Es ist wirklich unpraktisch, wenn man für den Zugriff auf Habr einen anderen Computer benutzen muss. Das Fehlen der Möglichkeit, Inhalte von Stack Overflow zu kopieren und einzufügen, kann die Arbeit erheblich behindern, da man etwas unternehmen muss.
Es muss irgendwie organisiert werden, dass, wenn man auf Ressourcen im internen Netzwerk zugreifen muss, Linux über VPN verbunden wird, und wenn man auf Habr zugreifen möchte, direkt ins Internet geht.
Openconnect führt nach dem Start und der Herstellen der Verbindung mit dem VPN ein spezielles Skript aus, das sich in /usr/share/vpnc-scripts/vpnc-script befindet. Das Skript erhält bestimmte Variablen als Eingabe und konfiguriert das VPN. Leider habe ich es nicht geschafft, den Datenverkehr zwischen dem Unternehmens-VPN und dem Rest des Internets mit dem Standard-Skript zu trennen.
Offensichtlich wurde für Leute wie mich das Tool vpn-slice entwickelt, das es ermöglicht, den Datenverkehr über zwei Kanäle zu leiten, ohne große Umstände. Man muss zwar trotzdem etwas Aufwand betreiben, aber man muss dabei nicht unbedingt ein Schamane sein.
Datenverkehrsaufteilung mit vpn-slice
Zunächst müssen Sie vpn-slice installieren, dabei sollten Sie selbstständig vorgehen. Wenn es Fragen in den Kommentaren gibt, werde ich dazu einen separaten Beitrag schreiben. Es handelt sich jedoch um ein normales Programm in Python, daher sollten keine Schwierigkeiten auftreten. Ich habe es mit virtualenv installiert.
Anschließend muss das Tool angewendet werden, indem Sie mit dem Schlüssel —script openconnect angeben, 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 Im —script wird der Befehl übergeben, der anstelle des Skripts aufgerufen werden soll. ./bin/vpn-slice ist der Pfad zur ausführbaren Datei, 192.168.430.0/24 ist die Maskierung der Adressen, über die im VPN geroutet werden soll. Das bedeutet, dass wenn eine Adresse mit 192.168.430 beginnt, die Ressource mit dieser Adresse innerhalb des VPN gesucht werden sollte.
Jetzt sollte die Situation fast normal sein. Fast. Man kann jetzt auf Habr zugreifen und auf die Unternehmensressourcen über die IP-Adresse zugreifen, aber nicht über den symbolischen Namen. Wenn man die Zuordnung zwischen symbolischem Namen und Adresse in der hosts-Datei einträgt, sollte alles funktionieren. Und es wird funktionieren, solange sich die IP-Adresse nicht ändert. Linux kann jetzt je nach IP-Adresse ins Internet oder in das Unternehmensnetzwerk gehen. Aber zur Adressbestimmung wird nach wie vor nicht der Unternehmens-DNS verwendet.
Das Problem kann sich auch so äußern – bei der Arbeit funktioniert alles normal, aber zu Hause können Unternehmensressourcen nur über die IP-Adresse erreicht werden. Das liegt daran, dass, wenn du mit dem Unternehmens-WLAN verbunden bist, auch der DNS des Unternehmens verwendet wird, in dem symbolische Adressen aus dem VPN aufgelöst werden, obwohl man über eine solche Adresse ohne VPN nach wie vor nicht gehen kann.
Automatische Modifikation der hosts-Datei
Wenn vpn-slice höflich darum gebeten wird, kann es nach dem Start der VPN zu dessen DNS gehen, die IP-Adressen der benötigten Ressourcen anhand ihrer symbolischen Namen finden und diese in die Hosts-Datei eintragen. Nach dem Ausschalten der VPN werden diese Adressen aus den Hosts entfernt. Dafür müssen die symbolischen Namen als Argumente an vpn-slice übergeben werden. So funktioniert es.
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 der VPN bereitgestellt wurde.
Wenn es nur wenige Adressen im Netzwerk gibt, ist der Ansatz mit der automatischen Modifizierung der Hosts-Datei durchaus funktional. Wenn es jedoch viele Ressourcen im Netzwerk gibt, müssen Sie ständig Zeilen wie zoidberg.test.evilcorp.com zu dem Skript hinzufügen; zoidberg ist der Name eines der Teststandorte.
Aber jetzt, wo wir ein wenig verstehen, wie das Ganze funktioniert, kann diese Notwendigkeit beseitigt werden.
Wenn man nach dem Aufbau der VPN in /etc/hosts schaut, kann man eine solche Zeile sehen.
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
Auch in resolv.conf wurde eine neue Zeile hinzugefügt. Kurz gesagt, vpn-slice hat irgendwie den DNS-Server für die VPN ermittelt.
Jetzt müssen wir sicherstellen, dass Linux für die Abfrage der IP-Adresse einer Domain, die auf evilcorp.com endet, den Unternehmens-DNS verwendet. Bei Bedarf wird der Standard-DNS genutzt.
Ich habe eine Weile gegoogelt und herausgefunden, dass diese Funktionalität in Ubuntu standardmäßig vorhanden ist. Damit ist die Möglichkeit gemeint, einen lokalen DNS-Server, dnsmasq, für die Namensauflösung zu verwenden.
Das bedeutet, dass Linux immer den lokalen DNS-Server abfragt, der je nach Domainname die IP-Adresse von einem entsprechenden externen DNS-Server sucht.
Für alle netzwerkbezogenen Aufgaben und Verbindungen wird in Ubuntu der NetworkManager verwendet, und die grafische Benutzeroberfläche zur Auswahl von beispielsweise WLAN-Verbindungen ist einfach ein Frontend dafür.
Wir müssen in seinen Konfigurationen herumstöbern.
- Erstellen Sie eine Datei in /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Beachten Sie den Punkt vor evilcorp. Er signalisiert dnsmasq, dass alle Subdomains von evilcorp.com im Unternehmens-DNS gesucht werden sollen.
- NetworkManager anweisen, dass zur Namensauflösung dnsmasq verwendet werden soll.
Die Konfiguration des Network Managers befindet sich in /etc/NetworkManager/NetworkManager.conf. Dort muss Folgendes hinzugefügt werden:
[main]
dns=dnsmasq
- NetworkManager neu starten
service network-manager restartJetzt, nachdem ich mich mit OpenConnect und vpn-slice mit dem VPN verbunden habe, wird die IP korrekt erkannt, auch wenn keine symbolischen Adressen in die Argumente für vpnslice hinzugefügt werden.
Wie man über VPN auf bestimmte Dienste zugreift
Nachdem ich mich erfolgreich mit dem VPN verbunden hatte, war ich zwei Tage lang sehr glücklich, bis ich herausfand, dass die E-Mail nicht funktioniert, wenn ich mich nicht aus dem Büronetzwerk verbinde. Ein bekanntes Problem, oder?
Unsere E-Mail befindet sich unter mail.publicevilcorp.com, was bedeutet, dass sie nicht unter die Regel in dnsmasq fällt und die Adresse des Mailservers über den öffentlichen DNS gesucht wird.
Im Büro wird jedoch weiterhin der DNS verwendet, der diese Adresse enthält. So dachte ich zumindest. In der Praxis änderte sich jedoch nichts, nachdem ich die Zeile in dnsmasq hinzugefügt hatte:
address=/mail.publicevilcorp.com/192.168.430.534
Die Situation blieb unverändert. Die IP war die gleiche. Ich musste zur Arbeit gehen.
Erst als ich mich intensiver mit der Situation beschäftigte und das Problem etwas besser verstand, gab mir eine kluge Person einen Hinweis, wie ich es lösen kann. Ich musste mich nicht einfach mit dem Mailserver verbinden, sondern über das VPN.
Ich verwende vpn-slice, um über VPN auf Adressen zuzugreifen, die mit 192.168.430 beginnen. Der Mailserver hat nicht nur einen Symbolnamen, der kein Subdomain von evilcorp ist, sondern auch die IP-Adresse beginnt nicht mit 192.168.430. Aus dem gesamten Netzwerk lässt er natürlich niemanden zu sich.
Damit Linux über VPN auf den Mailserver zugreifen kann, muss ich ihn in 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 zum Herstellen der VPN-Verbindung mit einem Argument.
Das ist natürlich alles 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 man den Befehl in ein Skript packen, das im PATH liegt. Dann muss man nur den Code eingeben, der aus dem 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 man das Skript in connect~evilcorp~ platziert, kann man einfach in der Konsole schreiben.
connect_evil_corp 567987Aber jetzt muss ich trotzdem eine Konsole offen halten, in der openconnect läuft.
openconnect im Hintergrund starten
Glücklicherweise haben die Entwickler von openconnect an uns gedacht und einen speziellen Schalter —background in das Programm integriert. Dieser sorgt dafür, 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 unklar, wohin die Logs gehen. Die Logs sind eigentlich nicht wirklich nötig, aber man weiß ja nie. openconnect kann sie in syslog umleiten, wo sie sicher und unversehrt aufbewahrt werden. Man muss diesen Befehl nur mit dem Schalter —syslog ergänzen.
#!/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 So funktioniert openconnect nun 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 den Prozess mit 'grep' nach dem Namen openconnect durchsuchen, aber das ist etwas umständlich. Danke an die Entwickler, 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 der Prozess jederzeit mit dem Befehl
kill $(cat ~/vpn-pid)gestoppt werden. Wenn der Prozess nicht existiert, gibt kill eine Fehlermeldung aus, wirft aber keinen Fehler. Wenn die Datei nicht existiert, passiert ebenfalls nichts Schlimmes, sodass man den Prozess ruhig im ersten Zeilen 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 können Sie den Computer einschalten, die Konsole öffnen und den Befehl ausführen, wobei Sie den Code aus Google Authenticator übergeben. Danach kann die Konsole beendet werden.
Ohne vpn-slice. Statt eines Nachworts.
Es stellte sich als sehr schwierig heraus, herauszufinden, wie man ohne vpn-slice lebt. Ich musste viel lesen und googeln. Zum Glück, nachdem ich so viel Zeit mit dem Problem verbracht hatte, liest sich die technische Dokumentation und sogar `man openconnect` wie spannende Romane.
Letztendlich stellte ich fest, dass vpn-slice, wie das eigene Skript, zur Netzwerktrennung die Routing-Tabelle modifiziert.
Routing-Tabelle
Es handelt sich, vereinfacht gesagt, um eine Tabelle, in der in der ersten Spalte steht, mit welcher Adresse Linux beginnen soll, und in der zweiten durch welches Netzwerkinterface es diese Adresse erreichen möchte. Tatsächlich gibt es mehr Spalten, aber das ändert nichts an der Essenz.
Um die Routing-Tabelle anzuzeigen, müssen Sie 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 In dieser Zeile wird beschrieben, wie eine Nachricht an eine bestimmte Adresse gesendet wird. Zuerst folgt eine Beschreibung, mit welcher Adresse man beginnen sollte. Um zu verstehen, dass 192.168.0.0/16 bedeutet, dass die Adresse mit 192.168 beginnen muss, sollte man nachsehen, was eine IP-Maske ist. Nach 'dev' folgt der Name des Adapters, an den die Nachricht gesendet werden muss.
Für VPN hat Linux einen virtuellen Adapter erstellt – tun0. Die Weiterleitung des gesamten Traffics für alle Adressen, die mit 192.168 beginnen, erfolgt durch die folgende Zeile:
192.168.0.0/16 dev tun0 scope link Außerdem kann der aktuelle Zustand der Routing-Tabelle mit dem Befehl überprüft werden: route -n (Die IP-Adressen wurden professionell anonymisiert) Dieser Befehl gibt die Ergebnisse in einem anderen Format aus und ist insgesamt als veraltet anzusehen. Dennoch findet man oft seine Ausgabe in Handbüchern im Internet und sollte sie lesen können.
Der Beginn einer IP-Adresse für eine Route lässt sich aus der Kombination der Spalten Destination und Genmask ableiten. Die Teile der IP-Adresse, denen in der Genmask die Ziffer 255 zugeordnet ist, werden berücksichtigt, während die Teile mit 0 nicht berücksichtigt werden. Dies bedeutet, dass die Kombination Destination 192.168.0.0 und Genmask 255.255.255.0 anzeigt, dass Anfragen an Adressen, die mit 192.168.0 beginnen, über diese Route geleitet werden. Wenn die Destination jedoch 192.168.0.0 und die Genmask 255.255.0.0 lautet, werden Anfragen an Adressen, die mit 192.168, beginnen, über diese Route geleitet.
Um zu verstehen, was vpn-slice tatsächlich macht, habe ich beschlossen, die Zustände der Tabellen vor und nach dem Test zu überprüfen.
Vor der Aktivierung des VPN war es so:
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 sah es so aus.
route -n
Kernel-IP-Routing-Tabelle
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 tun0Und nach dem Aufruf von openconnect in Kombination mit vpn-slice sieht das so aus.
Kernel-IP-Routing-Tabelle
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0
222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0
333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0
192.168.430.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.430.534 0.0.0.0 255.255.255.255 UH 0 0 0 tun0Es ist zu erkennen, dass openconnect deutlich angibt, dass alle Adressen, außer den separat angegebenen, über VPN geleitet werden müssen, wenn vpn-slice nicht verwendet wird.
Hier:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Dort ist gleich ein weiterer Weg angegeben, der verwendet werden muss, wenn die Adresse, über die Linux versucht, eine Verbindung herzustellen, mit keiner der Masken aus der Tabelle übereinstimmt.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Hier steht bereits, dass man in diesem Fall über den standardmäßigen WLAN-Adapter gehen sollte.
Ich nehme an, dass der VPN-Pfad verwendet wird, weil er in der Routing-Tabelle an erster Stelle steht.
Und theoretisch, wenn man diesen Standardpfad aus der Routing-Tabelle entfernt, sollte openconnect in Kombination mit dnsmasq ordnungsgemäß funktionieren.
Ich habe es ausprobiert.
route del defaultUnd es hat alles funktioniert.
Routing von Anfragen an den Mailserver ohne vpn-slice.
Aber ich habe noch einen Mailserver mit der Adresse 555.555.555.555, zu dem man auch über VPN gehen muss. Den Pfad dorthin muss man ebenfalls manuell hinzufügen.
ip route add 555.555.555.555 via dev tun0Und jetzt läuft alles gut. Es ist also möglich, ohne vpn-slice auszukommen, aber man muss schon genau wissen, was man tut. Ich überlege jetzt, ob ich in die letzte Zeile des ursprünglichen openconnect-Skripts das Löschen des Standard-Routing und das Hinzufügen des Routing für den Mailserver nach der VPN-Verbindung einfügen soll, einfach um die beweglichen Teile in meinem Fahrrad zu minimieren.
Vielleicht würde es manchen reichen, um zu verstehen, wie man ein VPN einrichtet. Während ich versuchte zu begreifen, was ich tun soll, habe ich viele solcher Anleitungen gelesen, die beim Autor funktionieren, bei mir aber aus irgendeinem Grund nicht geklappt haben. Daher habe ich beschlossen, hier alle Teile zusammenzustellen, die ich gefunden habe. Ich hätte mich sehr über solch eine Hilfe gefreut.
Quelle: habr.com
