Sie möchten Linux bei der Arbeit verwenden, aber Ihr Firmen-VPN lässt dies nicht zu? Dann kann dieser Artikel hilfreich sein, auch wenn dies nicht sicher ist. Ich möchte Sie im Voraus warnen, dass ich mich mit Netzwerkadministrationsproblemen nicht besonders gut auskenne und es daher möglich ist, dass ich alles falsch gemacht habe. Andererseits ist es möglich, dass ich eine Anleitung schreiben kann, die für normale Menschen verständlich ist, also schlage ich vor, dass Sie es versuchen.
Der Artikel enthält zwar viele unnötige Informationen, aber ohne dieses Wissen hätte ich die Probleme, die ich unerwartet beim Einrichten eines VPN hatte, nicht lösen können. Ich denke, dass jeder, der versucht, dieses Handbuch zu verwenden, auf Probleme stoßen wird, die ich nicht hatte, und ich hoffe, dass diese zusätzlichen Informationen ihnen dabei helfen werden, diese Probleme selbst zu lösen.
Die meisten der in diesem Handbuch verwendeten Befehle müssen über sudo ausgeführt werden, das der Übersichtlichkeit halber entfernt wurde. Denken Sie daran.
Die meisten IP-Adressen sind stark verschleiert. Wenn Sie also eine Adresse wie 435.435.435.435 sehen, sollte es sich um eine normale IP handeln, die speziell auf Ihren Fall zutrifft.
Bei mir Ubuntu 18.04. April, aber ich denke, die Anleitung ließe sich mit geringfügigen Anpassungen auch auf andere Distributionen anwenden. In diesem Text bezieht sich Linux jedoch auf … Ubuntu.
Cisco Connect
Diejenigen, die auf Windows Oder MacOS können sich über Cisco Connect mit unserem Firmen-VPN verbinden. Hierfür muss die Gateway-Adresse angegeben und ein Passwort eingegeben werden, das aus einem festen Teil und einem von Google Authenticator bei jeder Verbindung generierten Code besteht.
Unter Linux war es nicht möglich, Cisco Connect zu starten, aber man konnte bei Google eine Empfehlung zur Verwendung von Openconnect finden, das speziell als Ersatz für Cisco Connect erstellt wurde.
Openconnect
Theoretisch verfügt Ubuntu über eine spezielle grafische Oberfläche für OpenConnect, die bei mir jedoch nicht funktioniert hat. Vielleicht ist es das Beste.
In Ubuntu wird Openconnect vom Paketmanager installiert.
apt install openconnectSie können sofort nach der Installation versuchen, eine Verbindung zum VPN herzustellen
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com ist die Adresse eines fiktiven VPN
poxvuibr – fiktiver Benutzername
openconnect fordert Sie zur Eingabe eines Passworts auf, das, zur Erinnerung, aus einem festen Teil und einem Code von Google Authenticator besteht, und versucht dann, eine Verbindung zum VPN herzustellen. Wenn es funktioniert hat, herzlichen Glückwunsch! Sie können den sehr mühsamen Mittelteil getrost überspringen und direkt zum Punkt über die Arbeit von OpenConnect im Hintergrund übergehen. Wenn es nicht funktioniert, können Sie fortfahren. Wenn es jedoch beispielsweise bei der Verbindung über ein Gast-WLAN bei der Arbeit funktioniert hat, ist es möglicherweise noch zu früh, sich zu freuen. Sie sollten versuchen, den Vorgang zu Hause zu wiederholen.
Zertifikat
Es besteht eine hohe Wahrscheinlichkeit, dass nichts gestartet wird und die OpenConnect-Ausgabe ungefähr so aussieht:
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 progressEinerseits ist dies ärgerlich, da die VPN-Verbindung nicht zustande kam, andererseits ist die Behebung dieses Problems grundsätzlich klar.
Hier hat uns der Server ein Zertifikat gesendet, anhand dessen wir feststellen können, dass die Verbindung zum Server des einheimischen Unternehmens und nicht zu einem böswilligen Betrüger hergestellt wurde, und dieses Zertifikat ist dem System unbekannt. Und deshalb kann sie nicht überprüfen, ob der Server echt ist oder nicht. Und deshalb, nur für den Fall, dass es nicht mehr funktioniert.
Damit openconnect eine Verbindung zum Server herstellen kann, müssen Sie ihm explizit mitteilen, welches Zertifikat vom VPN-Server stammen soll, indem Sie den Schlüssel —servercert verwenden.
Und welches Zertifikat uns der Server gesendet hat, können Sie direkt aus dem Ausdruck von Openconnect entnehmen. Hier ist aus diesem Stück:
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 progressSie können mit diesem Befehl erneut versuchen, eine Verbindung herzustellen
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comVielleicht klappt es ja jetzt, dann können wir zum Ende weitergehen. Aber persönlich hat Ubuntu mir in dieser Form den Finger gezeigt
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 wird aufgelöst, aber Sie können nicht darauf zugreifen. Adressen wie jira.evilcorp.com werden überhaupt nicht aufgelöst.
Ich verstehe nicht, was hier passiert ist. Aber Experimente zeigen, dass, wenn Sie eine Zeile zu /etc/resolv.conf hinzufügen
nameserver 192.168.430.534dann werden die Adressen innerhalb des VPN wie von Zauberhand aufgelöst und Sie können durch sie navigieren, das heißt, wer nach dem DNS zum Auflösen der Adressen sucht, sucht speziell in /etc/resolv.conf und nicht woanders.
Sie können überprüfen, ob die VPN-Verbindung besteht und funktioniert, ohne /etc/resolv.conf zu bearbeiten. Geben Sie dazu im Browser einfach nicht den symbolischen Namen der Ressource aus dem VPN ein, sondern deren IP-Adresse.
Daraus ergeben sich zwei Probleme.
- Bei der Verbindung mit VPN wird dessen DNS nicht erkannt
- Der gesamte Datenverkehr läuft über ein VPN, sodass Sie nicht online gehen können
Ich sage Ihnen jetzt, was zu tun ist, aber zuerst ein wenig Automatisierung.
Automatische Eingabe eines festen Teils des Passworts
Wahrscheinlich haben Sie Ihr Passwort inzwischen mindestens fünfmal eingegeben und diese Prozedur hat Sie schon ziemlich ermüdet. Erstens, weil das Passwort lang ist und zweitens, weil man bei der Eingabe in einen festgelegten Zeitraum passen muss.
Die endgültige Lösung des Problems war im Artikel nicht enthalten, es besteht jedoch die Möglichkeit, dafür zu sorgen, dass der feste Teil des Passworts nicht oft eingegeben werden muss.
Nehmen wir an, der feste Teil des Passworts lautet „fixedPassword“ und der Teil von Google Authenticator lautet „567 987“. Das gesamte OpenConnect-Passwort kann mit dem Argument „--passwd-on-stdin“ über die Standardeingabe übergeben werden.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinNun können Sie jederzeit zum zuletzt eingegebenen Befehl zurückkehren und dort nur den Teil des Google Authenticators ändern.
Über ein Unternehmens-VPN haben Sie keinen Zugriff auf das Internet.
Es ist überhaupt nicht praktisch, wenn Sie für den Zugriff auf Habr einen separaten Computer verwenden müssen. Die Unfähigkeit, von Stackoverflow zu kopieren und einzufügen, kann die Arbeit völlig lahmlegen, daher muss etwas getan werden.
Wir müssen es irgendwie so organisieren, dass Linux auf VPN geht, wenn wir auf eine Ressource aus dem internen Netzwerk zugreifen müssen, und auf das Internet, wenn wir auf Habr zugreifen müssen.
Openconnect führt nach dem Starten und Herstellen einer Verbindung mit VPN ein spezielles Skript aus, das sich unter /usr/share/vpnc-scripts/vpnc-script befindet. Dem Skript werden bei der Eingabe einige Variablen übergeben und es konfiguriert das VPN. Leider konnte ich nicht herausfinden, wie ich den Datenverkehr mithilfe des nativen Skripts zwischen dem Unternehmens-VPN und dem Rest des Internets aufteilen kann.
Anscheinend wurde das Dienstprogramm VPN-Slice speziell für Leute wie mich entwickelt, mit dem Sie den Datenverkehr über zwei Kanäle leiten können, ohne mit einem Tamburin zu tanzen. Das heißt, Sie müssen tanzen, aber Sie müssen kein Schamane sein.
Aufteilen des Datenverkehrs mit VPN-Slice
Zuerst müssen Sie VPN-Slice installieren. Das müssen Sie selbst herausfinden. Sollten in den Kommentaren Fragen auftauchen, werde ich hierzu einen separaten Beitrag verfassen. Da es sich jedoch um ein normales Python-Programm handelt, sollte es keine Schwierigkeiten geben. Ich habe es mit virtualenv installiert.
Und dann muss das Dienstprogramm mit dem Schlüssel -script angewendet werden, was openconnect angibt, dass anstelle des Standardskripts vpn-slice verwendet werden muss
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 " vpn.evilcorp.com --script übergibt eine Zeichenfolge mit einem Befehl, der anstelle des Skripts aufgerufen werden soll. ./bin/vpn-slice – Pfad zur ausführbaren Datei vpn-slice 192.168.430.0/24 – Maske der Adressen, zu denen im VPN gegangen werden soll. Hier bedeutet dies, dass, wenn die Adresse mit 192.168.430 beginnt, die Ressource mit dieser Adresse innerhalb des VPN gesucht werden muss
Die Situation dürfte mittlerweile nahezu normal sein. Fast. Jetzt können Sie zu Habr gehen und per IP zur internen Unternehmensressource gehen, aber Sie können nicht per symbolischem Namen zur internen Unternehmensressource gehen. Wenn Sie die Übereinstimmung zwischen dem symbolischen Namen und der Adresse in Hosts registrieren, sollte alles funktionieren. Und arbeiten Sie, bis sich die IP ändert. Linux kann nun je nach IP auf das Internet oder das Unternehmensintranet zugreifen. Zur Adressbestimmung wird jedoch weiterhin das unternehmensfremde DNS verwendet.
Das Problem kann sich auch so äußern: Auf der Arbeit ist alles in Ordnung, aber zu Hause kann man nur per IP auf Unternehmensressourcen zugreifen. Denn wenn Sie mit dem Firmen-WLAN verbunden sind, wird auch das Firmen-DNS verwendet und symbolische Adressen aus dem VPN werden darin aufgelöst, obwohl es ohne VPN immer noch nicht möglich ist, auf eine solche Adresse zuzugreifen.
Automatische Änderung der Hosts-Datei
Wenn Sie VPN-Slice höflich fragen, kann es nach dem Heraufsetzen des VPN zu seinem DNS gehen, dort die IP-Adressen der benötigten Ressourcen anhand ihrer symbolischen Namen finden und sie in Hosts eingeben. Nach dem Deaktivieren des VPN werden diese Adressen von den Hosts entfernt. Dazu müssen Sie symbolische Namen als Argumente an vpn-slice übergeben. So was.
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 Nun soll alles sowohl im Büro als auch am Strand funktionieren.
Suche nach Adressen aller Subdomänen im DNS, die durch VPN bereitgestellt wurden
Wenn es im Netzwerk nur wenige Adressen gibt, ist der Ansatz mit der automatischen Änderung der Hosts-Datei durchaus praktikabel. Wenn jedoch viele Ressourcen im Netzwerk vorhanden sind, müssen Sie dem Skript ständig Zeilen wie zoidberg.test.evilcorp.com hinzufügen. Zoidberg ist der Name eines der Prüfstände.
Aber da wir jetzt ein wenig verstehen, was Sache ist, kann dieser Bedarf beseitigt werden.
Wenn Sie nach dem Einrichten des VPN in /etc/hosts nachsehen, können Sie die folgende Zeile sehen
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOMATISCH ERSTELLT
Und eine neue Zeile wurde zu resolv.conf hinzugefügt. Kurz gesagt, VPN-Slice hat irgendwie ermittelt, wo sich der DNS-Server für VPN befindet.
Jetzt müssen wir es so einrichten, dass Linux zum Ermitteln der IP-Adresse eines Domänennamens mit der Endung evilcorp.com auf den DNS des Unternehmens zurückgreift und, falls etwas anderes benötigt wird, auf den Standard-DNS.
Ich habe eine ganze Weile gegoogelt und herausgefunden, dass diese Funktionalität in Ubuntu standardmäßig verfügbar ist. Dies bedeutet die Möglichkeit, den lokalen DNS-Server dnsmasq zur Namensauflösung zu verwenden.
Das heißt, es ist möglich, es so einzurichten, dass Linux für IP-Adressen immer auf einen lokalen DNS-Server zugreift, der wiederum, abhängig vom Domänennamen, auf dem entsprechenden externen DNS-Server nach der IP sucht.
Ubuntu verwendet NetworkManager, um alles zu verwalten, was mit Netzwerken und Netzwerkverbindungen zu tun hat, und die grafische Benutzeroberfläche zum Auswählen beispielsweise einer Wi-Fi-Verbindung ist nur ein Front-End dafür.
Wir müssen an der Konfiguration herumbasteln.
- Erstellen Sie eine Datei in /etc/NetworkManager/dnsmasq.d/evilcorp
Adresse=/.evilcorp.com/192.168.430.534
Beachten Sie den Punkt vor „evilcorp“. Es signalisiert dnsmasq, dass alle Subdomains von evilcorp.com im Unternehmens-DNS gesucht werden sollen.
- Weisen Sie NetworkManager an, dnsmasq zur Namensauflösung zu verwenden
Die Netzwerkmanager-Konfiguration befindet sich in /etc/NetworkManager/NetworkManager.conf. Sie müssen dort Folgendes hinzufügen:
[Main]
dns=dnsmasq
- Starten Sie NetworkManager neu
service network-manager restartNachdem Sie nun mithilfe der Kombination „openconnect“ und „vpn-slice“ eine Verbindung zum VPN hergestellt haben, wird die IP normal ermittelt, auch wenn Sie den Argumenten für „vpnslice“ keine symbolischen Adressen hinzufügen.
So greifen Sie per VPN auf einzelne Dienste zu
Nachdem ich es geschafft hatte, eine Verbindung zum VPN herzustellen, war ich zwei Tage lang sehr zufrieden, und dann stellte sich heraus, dass die E-Mail nicht funktionierte, wenn man sich von außerhalb des Büronetzwerks mit dem VPN verbindet. Das Symptom kommt Ihnen bekannt vor, 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 öffentliches DNS gesucht wird.
Nun, im Büro verwenden sie immer noch DNS, das diese Adresse enthält. Das ist, was ich dachte. Tatsächlich, nach dem Hinzufügen der Zeile zu dnsmasq
Adresse=/mail.publicevilcorp.com/192.168.430.534
die Situation hat sich überhaupt nicht geändert. Die IP blieb gleich. Ich musste zur Arbeit.
Und später, als ich mich tiefer mit der Situation befasste und das Problem ein wenig verstand, erklärte mir eine kluge Person, wie ich es lösen könnte. Es war notwendig, sich nicht einfach so mit dem Mailserver zu verbinden, sondern über ein VPN
Ich verwende VPN-Slice, um über VPN zu Adressen zu gelangen, die mit 192.168.430 beginnen. Und nicht nur stellt die symbolische Adresse des Mailservers keine Subdomäne von evilcorp dar, seine IP-Adresse beginnt auch nicht mit 192.168.430. Und natürlich lässt er niemanden aus dem allgemeinen Netzwerk in seinen Bereich.
Damit Linux über VPN auf den Mailserver zugreifen kann, müssen Sie es zum VPN-Slice hinzufügen. Nehmen wir an, die Adresse des Absenders lautet 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 Heraufsetzen eines VPN mit einem Argument
Das alles ist natürlich nicht sehr praktisch. Ja, Sie können den Text in einer Datei speichern und ihn per Copy-and-paste in die Konsole einfügen, anstatt ihn von Hand einzugeben, aber das ist trotzdem nicht sehr angenehm. Um den Vorgang zu vereinfachen, können Sie den Befehl in ein Skript einbinden, das sich in PATH befindet. Und dann müssen Sie nur noch den Code eingeben, den Sie von Google Authenticator erhalten haben
#!/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 Sie das Skript in connect~evilcorp~ einfügen, können Sie einfach in die Konsole schreiben
connect_evil_corp 567987Aber jetzt muss ich aus irgendeinem Grund immer noch die Konsole offen halten, in der OpenConnect ausgeführt wird
Führen Sie OpenConnect im Hintergrund aus
Glücklicherweise haben sich die Autoren von OpenConnect um uns gekümmert und dem Programm einen speziellen Schlüssel hinzugefügt – Hintergrund, der dafür sorgt, dass das Programm nach dem Start im Hintergrund läuft. Wenn Sie es so ausführen, können Sie die Konsole nach dem Start schließen
#!/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 nicht klar, wohin die Protokolle gehen. Wir brauchen eigentlich keine Protokolle, aber man weiß ja nie. Openconnect kann sie an Syslog weiterleiten, wo sie sicher gespeichert werden. Sie müssen den Schlüssel —syslog zum Befehl 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 stellt sich heraus, dass Openconnect irgendwo im Hintergrund arbeitet und niemanden stört, aber es ist nicht klar, wie man es stoppen kann. Das heißt, Sie können die PS-Ausgabe natürlich mit grep filtern und nach einem Prozess suchen, dessen Name openconnect enthält, aber das ist irgendwie mühsam. Vielen Dank an die Autoren, die sich auch darüber Gedanken gemacht haben. openconnect verfügt über einen Schalter --pid-file, mit dem openconnect angewiesen werden kann, seine 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 können Sie den Prozess jederzeit mit einem Befehl beenden
kill $(cat ~/vpn-pid)Wenn kein Prozess vorhanden ist, wird „kill“ eine Meldung ausgeben, aber keinen Fehler auslösen. Wenn die Datei nicht existiert, passiert auch nichts Schlimmes und Sie können den Prozess bedenkenlos in der ersten Zeile des Skripts beenden.
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 Ihren Computer einschalten, die Konsole öffnen und den Befehl ausführen, indem Sie ihm den Code von Google Authenticator übergeben. Anschließend kann die Konsole festgenagelt werden.
Ohne VPN-Slice. Statt eines Nachworts
Herauszufinden, wie man ohne VPN-Slice leben kann, erwies sich als sehr schwierig. Ich musste viel lesen und googeln. Glücklicherweise lesen sich technische Handbücher und sogar man openconnect wie fesselnde Romane, nachdem man sich so lange mit dem Problem beschäftigt hat.
Am Ende fand ich heraus, dass VPN-Slice, wie das native Skript, die Routing-Tabelle ändert, um Netzwerke zu trennen.
Routing-Tabelle
Dabei handelt es sich, vereinfacht ausgedrückt, um eine Tabelle, deren erste Spalte angibt, mit welcher Adresse die von Linux zu verwendende Adresse beginnen soll, und deren zweite Spalte angibt, über welchen Netzwerkadapter diese Adresse verwendet werden soll. Tatsächlich gibt es mehr Lautsprecher, aber das ändert nichts am Wesentlichen.
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 Dabei ist jede Zeile dafür verantwortlich, wohin Sie gehen müssen, um eine Nachricht an eine bestimmte Adresse zu senden. Die erste ist eine Beschreibung, womit die Adresse beginnen soll. Um zu verstehen, wie Sie feststellen können, dass 192.168.0.0/16 bedeutet, dass die Adresse mit 192.168 beginnen muss, müssen Sie googeln, was eine IP-Adressmaske ist. Nach dev steht der Name des Adapters, an den die Nachricht gesendet werden soll.
Für VPN hat Linux einen virtuellen Adapter erstellt – tun0. Die Leitung ist dafür verantwortlich, dass der Verkehr für alle Adressen, die mit 192.168 beginnen, über sie läuft.
192.168.0.0/16 dev tun0 scope link Sie können den aktuellen Status der Routing-Tabelle auch mit dem Befehl Route -n (IP-Adressen werden geschickt anonymisiert) Dieser Befehl erzeugt Ergebnisse in einer anderen Form und ist im Allgemeinen veraltet, aber seine Ausgabe findet sich oft in Handbüchern im Internet und Sie müssen in der Lage sein, sie zu lesen.
Mit welcher IP-Adresse die Route beginnen soll, lässt sich aus der Kombination der Spalten Destination und Genmask ersehen. Dabei werden die Teile der IP-Adresse berücksichtigt, die in Genmask den Zahlen 255 entsprechen, nicht jedoch die Teile, in denen 0 steht. Das heißt, die Kombination aus Ziel 192.168.0.0 und Genmask 255.255.255.0 bedeutet, dass, wenn die Adresse mit 192.168.0 beginnt, die Anfrage an sie über diese Route geht. Und wenn das Ziel 192.168.0.0 ist, die Genmask jedoch 255.255.0.0, 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, mir die Zustände der Tabellen vor und nach anzusehen
Vor dem Einschalten von VPN war es so
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 wlp3s0Nach dem Aufruf von OpenConnect ohne VPN-Slice sah es so aus
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 tun0Und nach dem Aufruf von openconnect in Kombination mit vpn-slice wie folgt
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 tun0Es ist klar, dass, wenn Sie VPN-Slice nicht verwenden, OpenConnect klar schreibt, dass auf alle Adressen, mit Ausnahme der speziell angegebenen, über VPN zugegriffen werden muss.
Hier:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Direkt daneben ist ein weiterer Pfad angegeben, der verwendet werden sollte, wenn die Adresse, zu der Linux wechseln möchte, mit keiner der Masken in der Tabelle übereinstimmt.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Hier steht bereits, dass in diesem Fall der Umweg über einen Standard-WLAN-Adapter notwendig ist.
Ich gehe davon aus, dass der VPN-Pfad verwendet wird, da er der erste in der Routing-Tabelle ist.
Und theoretisch, wenn Sie diesen Standardpfad aus der Routing-Tabelle entfernen, sollte Openconnect in Verbindung mit DNSMASQ einen normalen Betrieb gewährleisten.
Ich habe es versucht
route del defaultUnd alles hat funktioniert.
Weiterleiten von Anfragen an einen Mailserver ohne VPN-Slice
Ich habe aber auch einen Mailserver mit der Adresse 555.555.555.555, der ebenfalls über VPN erreichbar sein muss. Auch die Route dorthin muss manuell hinzugefügt werden.
ip route add 555.555.555.555 via dev tun0Und jetzt ist alles gut. Es ist also möglich, auf ein VPN-Slice zu verzichten, aber Sie müssen wissen, was Sie tun. Ich denke jetzt darüber nach, in der letzten Zeile des nativen Openconnect-Skripts die Entfernung der Standardroute und das Hinzufügen einer Route für den Mailer nach der Verbindung mit dem VPN hinzuzufügen, nur damit mein Fahrrad weniger bewegliche Teile hat.
Wahrscheinlich reicht dieses Nachwort aus, damit jemand versteht, wie man ein VPN einrichtet. Aber während ich versuchte zu verstehen, was und wie ich vorgehen soll, habe ich ziemlich viele solcher Anleitungen gelesen, die für den Autor funktionieren, für mich aber aus irgendeinem Grund nicht, und ich habe beschlossen, alle Teile, die ich gefunden habe, hier hinzuzufügen. Über so etwas würde ich mich sehr freuen.
Source: habr.com
