Sie möchten Linux bei der Arbeit nutzen, aber Ihr Firmen-VPN lässt das nicht zu? Dann kann dieser Artikel hilfreich sein, obwohl dies nicht sicher ist. Ich möchte Sie vorab warnen, dass ich mich in Fragen der Netzwerkadministration nicht gut auskenne und daher möglicherweise alles falsch gemacht habe. Andererseits ist es möglich, dass ich einen Leitfaden so schreiben kann, dass er auch für den Normalbürger verständlich ist, daher empfehle ich Ihnen, es auszuprobieren.
Der Artikel enthält viele unnötige Informationen, aber ohne dieses Wissen hätte ich die unerwartet auftretenden Probleme bei der Einrichtung eines VPN nicht lösen können. Ich denke, dass jeder, der versucht, diesen Leitfaden zu verwenden, auf Probleme stoßen wird, die ich nicht hatte, und ich hoffe, dass diese zusätzlichen Informationen dabei helfen, diese Probleme selbst zu lösen.
Die meisten in diesem Handbuch verwendeten Befehle müssen über sudo ausgeführt werden, was der Kürze halber entfernt wurde. Merken Sie sich.
Die meisten IP-Adressen wurden stark verschleiert. Wenn Sie also eine Adresse wie 435.435.435.435 sehen, muss dort eine normale IP-Adresse vorhanden sein, die speziell auf Ihren Fall zutrifft.
Ich habe Ubuntu 18.04, aber ich denke, mit geringfügigen Änderungen kann die Anleitung auf andere Distributionen angewendet werden. Allerdings ist in diesem Text Linux == Ubuntu.
Cisco Connect
Wer Windows oder MacOS verwendet, kann sich über Cisco Connect mit unserem Unternehmens-VPN verbinden. Dabei muss die Gateway-Adresse angegeben und bei jeder Verbindung ein Passwort eingegeben werden, das aus einem festen Teil und einem von Google Authenticator generierten Code besteht.
Im Fall von Linux konnte ich Cisco Connect nicht zum Laufen bringen, aber ich habe es geschafft, bei Google eine Empfehlung für die Verwendung von OpenConnect zu finden, die speziell als Ersatz für Cisco Connect entwickelt wurde.
Openconnect
Theoretisch hat Ubuntu eine spezielle grafische Oberfläche für OpenConnect, aber das hat bei mir nicht funktioniert. Vielleicht ist es zum Besseren.
Unter Ubuntu wird openconnect über den Paketmanager installiert.
apt install openconnectUnmittelbar nach der Installation können Sie versuchen, eine Verbindung zu einem VPN herzustellen
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com ist die Adresse eines fiktiven VPN
poxvuibr – fiktiver Benutzername
openconnect fordert Sie auf, ein Passwort einzugeben, das, wie ich Sie daran erinnern möchte, aus einem festen Teil und einem Code von Google Authenticator besteht, und versucht dann, eine Verbindung zum VPN herzustellen. Wenn es funktioniert, herzlichen Glückwunsch, können Sie die Mitte, die sehr mühsam ist, getrost überspringen und mit dem Punkt über die Ausführung von OpenConnect im Hintergrund fortfahren. Wenn es nicht funktioniert, können Sie fortfahren. Wenn es jedoch beispielsweise bei der Verbindung über ein Gast-WLAN am Arbeitsplatz funktioniert hat, ist es möglicherweise noch zu früh, sich zu freuen; Sie sollten versuchen, den Vorgang von zu Hause aus zu wiederholen.
Zertifikat
Es besteht eine hohe Wahrscheinlichkeit, dass nichts startet und die openconnect-Ausgabe etwa 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 progressDas ist einerseits unangenehm, da keine Verbindung zum VPN bestand, andererseits ist aber im Prinzip klar, wie man dieses Problem beheben kann.
Hier hat uns der Server ein Zertifikat geschickt, anhand dessen wir feststellen können, dass die Verbindung zum Server unseres Heimatkonzerns und nicht zu einem bösen Betrüger hergestellt wird, und dieses Zertifikat ist dem System unbekannt. Und deshalb kann sie nicht überprüfen, ob der Server echt ist oder nicht. Und so funktioniert es für alle Fälle nicht mehr.
Damit openconnect eine Verbindung zum Server herstellen kann, müssen Sie ihm mithilfe des Schlüssels „servercert“ explizit mitteilen, welches Zertifikat vom VPN-Server stammen soll
Und welches Zertifikat uns der Server geschickt hat, können Sie direkt aus dem Druck von openconnect herausfinden. 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 progressMit diesem Befehl können Sie erneut versuchen, eine Verbindung herzustellen
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comVielleicht funktioniert es jetzt, dann können Sie mit dem Ende fortfahren. Aber Ubunta hat mir persönlich eine Feige in dieser Form 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 zwar aufgelöst, aber Sie können nicht dorthin gelangen. Adressen wie jira.evilcorp.com werden überhaupt nicht aufgelöst.
Was hier passiert ist, ist mir nicht klar. Das Experiment zeigt jedoch, dass, wenn Sie die Zeile zu /etc/resolv.conf hinzufügen
nameserver 192.168.430.534Dann beginnen sich die Adressen innerhalb des VPN auf magische Weise aufzulösen, und Sie können sie durchgehen. Das heißt, das, wonach DNS zum Auflösen von Adressen sucht, wird speziell in /etc/resolv.conf und nicht irgendwo anders angezeigt.
Sie können überprüfen, ob eine Verbindung zum VPN besteht und diese funktioniert, ohne Änderungen an /etc/resolv.conf vorzunehmen. Geben Sie dazu einfach nicht den symbolischen Namen der Ressource aus dem VPN in den Browser ein, sondern deren IP-Adresse
Daraus ergeben sich zwei Probleme
- Beim Herstellen einer Verbindung zu einem VPN wird dessen DNS nicht erfasst
- Der gesamte Datenverkehr läuft über VPN, das keinen Zugriff auf das Internet ermöglicht
Ich sage Ihnen jetzt, was zu tun ist, aber zuerst ein wenig Automatisierung.
Automatische Eingabe des festen Teils des Passworts
Mittlerweile haben Sie Ihr Passwort bereits mindestens fünf Mal eingegeben und diese Prozedur hat Sie bereits ermüdet. Erstens, weil das Passwort lang ist, und zweitens, weil man bei der Eingabe einen festen Zeitrahmen einhalten muss
Die endgültige Lösung des Problems wurde im Artikel nicht aufgeführt, Sie können jedoch sicherstellen, dass der feste Teil des Passworts nicht mehrmals eingegeben werden muss.
Nehmen wir an, dass der feste Teil des Passworts „fixedPassword“ ist und der Teil von Google Authenticator 567 ist. Das gesamte Passwort kann über die Standardeingabe mit dem Argument „--passwd-on-stdin“ an openconnect übergeben werden.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinJetzt können Sie jederzeit zum zuletzt eingegebenen Befehl zurückkehren und dort nur einen Teil des Google Authenticators ändern.
Mit einem Unternehmens-VPN können Sie nicht im Internet surfen.
Im Allgemeinen ist es nicht sehr umständlich, wenn Sie einen separaten Computer verwenden müssen, um zu Habr zu gelangen. Die Unfähigkeit, aus Stackoverfow zu kopieren und einzufügen, kann im Allgemeinen die Arbeit lahmlegen, sodass etwas getan werden muss.
Wir müssen es irgendwie so organisieren, dass Linux zum VPN geht, wenn Sie auf eine Ressource aus dem internen Netzwerk zugreifen müssen, und wenn Sie zu Habr gehen müssen, geht es zum Internet.
openconnect führt nach dem Starten und Herstellen einer Verbindung mit VPN ein spezielles Skript aus, das sich in /usr/share/vpnc-scripts/vpnc-script befindet. Einige Variablen werden als Eingabe an das Skript übergeben und es konfiguriert das VPN. Leider konnte ich nicht herausfinden, wie ich den Datenverkehr mithilfe eines nativen Skripts zwischen einem 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 Datenverkehr über zwei Kanäle senden können, ohne mit dem Tamburin zu tanzen. Das heißt, Sie müssen tanzen, aber Sie müssen kein Schamane sein.
Verkehrstrennung mittels VPN-Slice
Zuerst müssen Sie VPN-Slice installieren, das müssen Sie selbst herausfinden. Sollten in den Kommentaren Fragen auftauchen, werde ich dazu einen separaten Beitrag verfassen. Da es sich jedoch um ein normales Python-Programm handelt, sollte es keine Schwierigkeiten geben. Ich habe mit virtualenv installiert.
Und dann muss das Dienstprogramm mithilfe des Schalters -script angewendet werden, der OpenConnect anzeigt, dass Sie anstelle des Standardskripts VPN-Slice verwenden müssen
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 " vpn.evilcorp.com --script wird eine Zeichenfolge mit einem Befehl übergeben, der anstelle des Skripts aufgerufen werden muss. ./bin/vpn-slice – Pfad zur ausführbaren VPN-Slice-Datei 192.168.430.0/24 – Maske der Adressen, zu denen in VPN gewechselt werden soll. Damit meinen wir, dass, wenn die Adresse mit 192.168.430 beginnt, die Ressource mit dieser Adresse im VPN gesucht werden muss
Mittlerweile dürfte die Situation nahezu normal sein. Fast. Jetzt können Sie zu Habr gehen und über die IP zur unternehmensinternen Ressource gehen, aber Sie können nicht über den symbolischen Namen zur unternehmensinternen Ressource gehen. Wenn Sie in hosts eine Übereinstimmung zwischen dem symbolischen Namen und der Adresse angeben, sollte alles funktionieren. Und arbeiten, bis sich die IP ändert. Linux kann nun je nach IP auf das Internet oder das Intranet zugreifen. Zur Ermittlung der Adresse wird jedoch weiterhin unternehmensfremdes DNS verwendet.
Das Problem kann sich auch in dieser Form manifestieren – am Arbeitsplatz ist alles in Ordnung, aber zu Hause kann man nur über IP auf unternehmensinterne Ressourcen zugreifen. Dies liegt daran, dass bei einer Verbindung zum Unternehmens-WLAN auch das Unternehmens-DNS verwendet wird und symbolische Adressen aus dem VPN darin aufgelöst werden, obwohl es ohne die Verwendung eines VPN immer noch unmöglich ist, zu einer solchen Adresse zu gelangen.
Automatische Änderung der Hosts-Datei
Wenn VPN-Slice höflich gefragt wird, kann es nach dem Hochfahren des VPN zu seinem DNS gehen, dort die IP-Adressen der erforderlichen Ressourcen anhand ihrer symbolischen Namen finden und sie in Hosts eingeben. Nach dem Ausschalten des VPN werden diese Adressen von den Hosts entfernt. Dazu müssen Sie symbolische Namen als Argumente an vpn-slice übergeben. So.
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 sowohl im Büro als auch am Strand alles funktionieren.
Suchen Sie im vom VPN angegebenen DNS nach den Adressen aller Subdomains
Wenn es nur wenige Adressen im Netzwerk gibt, funktioniert der Ansatz, die Hosts-Datei automatisch zu ändern, recht gut. 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 einer der Prüfstände.
Aber jetzt verstehen wir ein wenig, warum dieses Bedürfnis beseitigt werden kann.
Wenn Sie nach dem Hochfahren des VPN in /etc/hosts nachsehen, können Sie diese Zeile sehen
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOMATISCH ERSTELLT
Und eine neue Zeile wurde zur resolv.conf hinzugefügt. Kurz gesagt, vpn-slice hat irgendwie festgestellt, wo sich der DNS-Server für den VPN befindet.
Jetzt müssen wir sicherstellen, dass Linux zum Unternehmens-DNS geht, um die IP-Adresse eines Domänennamens mit der Endung evilcorp.com herauszufinden, und wenn etwas anderes benötigt wird, dann zum Standard-DNS.
Ich habe eine ganze Weile gegoogelt und herausgefunden, dass solche Funktionen in Ubuntu sofort verfügbar sind. Damit ist die Möglichkeit gemeint, den lokalen DNS-Server dnsmasq zum Auflösen von Namen zu verwenden.
Das heißt, Sie können sicherstellen, dass Linux sich für IP-Adressen immer an den lokalen DNS-Server wendet, der wiederum, abhängig vom Domänennamen, auf dem entsprechenden externen DNS-Server nach der IP sucht.
Um alles zu verwalten, was mit Netzwerken und Netzwerkverbindungen zu tun hat, verwendet Ubuntu NetworkManager, und die grafische Oberfläche zum Auswählen beispielsweise von Wi-Fi-Verbindungen ist lediglich ein Frontend.
Wir müssen in seiner Konfiguration klettern.
- Erstellen Sie eine Datei in /etc/NetworkManager/dnsmasq.d/evilcorp
Adresse=/.evilcorp.com/192.168.430.534
Achten Sie auf den Punkt vor evilcorp. Es signalisiert dnsmasq, dass alle Subdomains von evilcorp.com im Unternehmens-DNS durchsucht werden sollen.
- Weisen Sie NetworkManager an, dnsmasq für die 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 über openconnect und vpn-slice eine Verbindung zu einem VPN hergestellt haben, wird die IP normal ermittelt, auch wenn Sie den Argumenten für vpnslice keine symbolischen Adressen hinzufügen.
So greifen Sie über 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 E-Mails nicht funktionierten, wenn ich von außerhalb des Büronetzwerks eine Verbindung zum VPN herstellte. Das Symptom ist bekannt, nicht wahr?
Unsere E-Mails befinden sich unter mail.publicevilcorp.com, was bedeutet, dass sie nicht unter die Regel in dnsmasq fallen und die Mailserveradresse über öffentliches DNS durchsucht wird.
Nun, das Büro verwendet immer noch DNS, das diese Adresse enthält. Das dachte ich mir. Tatsächlich wurde nach dem Hinzufügen der Zeile zu dnsmasq
Adresse=/mail.publicevilcorp.com/192.168.430.534
Die Situation hat sich überhaupt nicht geändert. IP blieb gleich. Ich musste zur Arbeit gehen.
Und erst später, als ich tiefer in die Situation eintauchte und das Problem ein wenig verstand, erklärte mir eine kluge Person, wie ich es lösen kann. Es war nicht einfach so notwendig, eine Verbindung zum Mailserver herzustellen, sondern über VPN
Ich verwende VPN-Slice, um über das VPN zu Adressen zu gelangen, die mit 192.168.430 beginnen. Und der Mailserver hat nicht nur eine symbolische Adresse, die keine Subdomain von evilcorp ist, sondern auch keine IP-Adresse, die mit 192.168.430 beginnt. Und natürlich lässt er niemanden aus dem allgemeinen Netzwerk zu sich kommen.
Damit Linux über das VPN zum Mailserver gelangen kann, müssen Sie es auch zu 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 Erhöhen von VPN mit einem Argument
Das alles ist natürlich nicht sehr praktisch. Ja, Sie können den Text in einer Datei speichern und in die Konsole kopieren und einfügen, anstatt ihn von Hand einzugeben, aber das ist immer noch nicht sehr angenehm. Um den Vorgang zu vereinfachen, können Sie den Befehl in ein Skript einschließen, das sich in PATH befindet. Und dann müssen Sie nur noch den vom Google Authenticator erhaltenen Code eingeben
#!/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 es einfach in die Konsole schreiben
connect_evil_corp 567987Aber jetzt müssen Sie aus irgendeinem Grund immer noch die Konsole, in der openconnect läuft, offen lassen
OpenConnect im Hintergrund ausführen
Glücklicherweise haben sich die Autoren von openconnect um uns gekümmert und dem Programm einen speziellen Schlüssel hinzugefügt –background, 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 einfach nicht klar, wohin die Protokolle gehen. Im Allgemeinen brauchen wir keine Protokolle, aber man weiß nie. openconnect kann sie an Syslog umleiten, wo sie sicher aufbewahrt werden. Sie müssen dem Befehl den 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 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 auch darüber nachgedacht haben. Openconnect verfügt über einen Schlüssel -pid-file, mit dem Sie openconnect anweisen können, seine Prozesskennung 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 einen Prozess jederzeit mit dem Befehl beenden
kill $(cat ~/vpn-pid)Wenn es keinen Prozess gibt, wird kill verfluchen, aber keinen Fehler auslösen. Wenn die Datei nicht vorhanden ist, passiert auch nichts Schlimmes, sodass Sie den Prozess sicher in der ersten Zeile des Skripts beenden können.
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, den Befehl ausführen und ihm den Code von Google Authenticator übergeben. Anschließend kann die Konsole festgenagelt werden.
Ohne VPN-Slice. Anstelle eines Nachworts
Es stellte sich als sehr schwierig zu verstehen, wie man ohne VPN-Slice leben kann. Ich musste viel lesen und googeln. Glücklicherweise lesen sich technische Handbücher und sogar Man OpenConnect, nachdem man so viel Zeit mit einem Problem verbracht hat, wie spannende Romane.
Als Ergebnis habe ich herausgefunden, dass VPN-Slice, wie das native Skript, die Routing-Tabelle ändert, um Netzwerke zu trennen.
Routing-Tabelle
Vereinfacht ausgedrückt handelt es sich hierbei um eine Tabelle, die in der ersten Spalte angibt, womit die Adresse beginnen soll, über die Linux gehen möchte, und in der zweiten Spalte, über welchen Netzwerkadapter diese Adresse durchlaufen werden soll. Tatsächlich gibt es mehr Lautsprecher, aber das ändert nichts am Wesen.
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 Hier ist jede Zeile dafür verantwortlich, wohin Sie gehen müssen, um eine Nachricht an eine Adresse zu senden. Das erste ist eine Beschreibung, wo 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 sollte, müssen Sie googeln, was eine IP-Adressmaske ist. Hinter 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 stellt sicher, dass der Datenverkehr für alle Adressen, die mit 192.168 beginnen, über sie geleitet wird
192.168.0.0/16 dev tun0 scope link Mit dem Befehl können Sie auch den aktuellen Status der Routing-Tabelle anzeigen Route -n (IP-Adressen werden geschickt anonymisiert) Dieser Befehl liefert Ergebnisse in einer anderen Form und ist im Allgemeinen veraltet, aber seine Ausgabe ist oft in Handbüchern im Internet zu finden und Sie müssen ihn lesen können.
Wo die IP-Adresse für eine Route beginnen soll, lässt sich aus der Kombination der Spalten „Destination“ und „Genmask“ erkennen. Berücksichtigt werden diejenigen Teile der IP-Adresse, die den Zahlen 255 in Genmask entsprechen, nicht jedoch diejenigen, bei 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 erfolgt. Und wenn das Ziel 192.168.0.0, aber Genmask 255.255.0.0 ist, werden Anfragen an Adressen, die mit 192.168 beginnen, über diese Route weitergeleitet
Um herauszufinden, was vpn-slice tatsächlich macht, habe ich beschlossen, mir die Zustände der Tabellen vorher und nachher anzusehen
Vor dem Einschalten des 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 wurde es so
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 diesem
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 ersichtlich, dass OpenConnect explizit schreibt, dass auf alle Adressen, mit Ausnahme der ausdrücklich angegebenen, über VPN zugegriffen werden muss, wenn Sie VPN-Slice nicht verwenden.
Hier:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Dort wird gleich daneben ein weiterer Pfad angezeigt, der verwendet werden muss, wenn die Adresse, die Linux durchzuleiten 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 Sie in diesem Fall einen Standard-WLAN-Adapter verwenden müssen.
Ich glaube, dass der VPN-Pfad verwendet wird, weil er der erste in der Routing-Tabelle ist.
Und theoretisch sollte, wenn Sie diesen Standardpfad aus der Routing-Tabelle entfernen, in Verbindung mit dnsmasq openconnect 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, auf den ebenfalls per VPN zugegriffen werden muss. Die Route dorthin muss ebenfalls manuell hinzugefügt werden.
ip route add 555.555.555.555 via dev tun0Und jetzt ist alles in Ordnung. Sie können also auf VPN-Slice verzichten, müssen aber genau wissen, was Sie tun. Ich denke jetzt darüber nach, in der letzten Zeile des nativen OpenConnect-Skripts die Entfernung der Standardroute hinzuzufügen und eine Route für den Mailer nach der Verbindung mit dem VPN hinzuzufügen, nur damit es weniger bewegliche Teile in meinem Fahrrad gibt.
Wahrscheinlich würde dieses Nachwort ausreichen, damit jemand versteht, wie man ein VPN einrichtet. Aber während ich versuchte zu verstehen, was und wie zu tun ist, habe ich eine ganze Reihe solcher Anleitungen gelesen, die für den Autor funktionieren, aber aus irgendeinem Grund für mich nicht funktionieren, 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