Sie möchten Linux bei der Arbeit verwenden, ein Unternehmens-VPN jedoch nicht? Dann kann dieser Artikel helfen, obwohl dies nicht korrekt ist. Ich möchte im Voraus warnen, dass ich die Probleme der Netzwerkadministration schlecht verstehe, sodass es möglich ist, dass ich alles falsch gemacht habe. Andererseits ist es möglich, dass ich das Handbuch so schreibe, dass es für normale Menschen verständlich ist. Daher rate ich Ihnen, es auszuprobieren.
Der Artikel enthält viele zusätzliche Informationen, aber ohne dieses Wissen wäre ich nicht in der Lage, die Probleme zu lösen, die ich plötzlich mit der VPN-Einstellung hatte. Ich denke, dass jeder, der versucht, dieses Handbuch anzuwenden, Probleme hat, die ich nicht hatte, und ich hoffe, dass diese zusätzlichen Informationen dazu beitragen, diese Probleme auf eigene Faust zu lösen.
Die meisten im Handbuch verwendeten Befehle müssen über sudo ausgeführt werden, das der Kürze halber entfernt wurde. Denken Sie daran.
Die meisten IP-Adressen waren stark verschleiert. Wenn Sie also eine Adresse wie 435.435.435.435 sehen, sollte es für Ihren Fall eine normale IP-Adresse geben.
Ich habe Ubuntu 18.04, aber ich denke, mit ein paar Änderungen kann der Leitfaden auf andere Distributionen angewendet werden. In diesem Text ist jedoch Linux == Ubuntu.
Cisco verbinden
Benutzer unter Windows oder MacOS können über Cisco Connect eine Verbindung zu unserem Unternehmens-VPN herstellen. Cisco Connect muss die Gateway-Adresse angeben und bei jeder Verbindung ein Kennwort eingeben, das aus einem festen Teil und einem von Google Authenticator generierten Code besteht.
Im Falle von Linux war es nicht möglich, Cisco Connect zu erhalten, aber es stellte sich heraus, dass Google die Empfehlung zur Verwendung von openconnect aussprach, die speziell als Ersatz für Cisco Connect gedacht war.
Openconnect
Theoretisch gibt es in Ubunt eine spezielle grafische Oberfläche für OpenConnect, die aber bei mir nicht funktioniert hat. Vielleicht ist es das Beste.
In Ubunt wird openconnect vom Paketmanager aus installiert.
apt install openconnect
Unmittelbar nach der Installation können Sie versuchen, eine Verbindung zum VPN herzustellen
openconnect --user poxvuibr vpn.evilcorp.com
vpn.evilcorp.com ist die fiktive VPN-Adresse \
poxvuibr - fiktiver Benutzername
openconnect fordert Sie auf, ein Passwort einzugeben, das, wie ich mich erinnere, aus einem festen Teil und Code von Google Authenticator besteht, und versucht dann, eine Verbindung zu VPN herzustellen. Wenn es sich herausstellte, können Sie, herzlichen Glückwunsch, die schmerzhafte Mitte sicher überspringen und im Hintergrund auf den Punkt über OpenConnect gehen. Wenn es nicht funktioniert, können Sie fortfahren. Obwohl es sich herausstellte, wenn Sie sich beispielsweise von einem Gast aus über WLAN bei der Arbeit verbinden, ist es möglich, sich zu freuen, und Sie sollten versuchen, den Vorgang von zu Hause aus zu wiederholen.
Zertifikat
Mit hoher Wahrscheinlichkeit startet nichts und der OpenConnect-Auspuff sieht ungefähr so aus:
POST https://vpn.evilcorp.com/ Connected to 777.777.777.777:443 SSL negotiation with vpn.evilcorp.com Server certificate verify failed: signer not found Certificate from VPN server "vpn.evilcorp.com" failed verification. Reason: signer not found To trust this server in future, perhaps add this to your command line: --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 Enter 'yes' to accept, 'no' to abort; anything else to view: fgets (stdin): Operation now in progress
Dies ist zum einen unangenehm, da keine Verbindung zum VPN bestand, zum anderen ist es grundsätzlich nachvollziehbar, wie dieses Problem behoben werden kann.
Der Server hat uns dann ein Zertifikat gesendet, anhand dessen festgestellt werden kann, dass die Verbindung zum Server des einheimischen Unternehmens und nicht zum böswilligen Betrüger hergestellt wurde und dieses Zertifikat dem System unbekannt ist. Und so kann sie nicht überprüfen, ob der reale Server ist oder nicht. Und für alle Fälle funktioniert es nicht mehr.
Damit openconnect weiterhin 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 Sie können herausfinden, welches Zertifikat der Server direkt von welchem openconnect an uns gesendet hat. Hier von 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 progress
Mit diesem Befehl können Sie erneut versuchen, eine Verbindung herzustellen
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com
Vielleicht funktioniert es jetzt, dann können Sie bis zum Ende gehen. 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.com
habr.com wird aufgelöst, aber es ist nicht möglich, dort einzutreten. 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.534
Dann werden die Adressen im VPN auf magische Weise aufgelöst und es wird möglich sein, sie zu durchlaufen, dh nach was DNS sucht, um Adressen aufzulösen, wird in /etc/resolv.conf gesucht und nicht woanders.
Damit eine Verbindung zum VPN besteht und es funktioniert, können Sie ohne Änderungen in /etc/resolv.conf sicherstellen, dass Sie im Browser nur den symbolischen Namen der Ressource von vpn und deren IP-Adresse eingeben
Das Ergebnis sind zwei Probleme
- bei verbindung zu VPN wird seine dns nicht abgeholt
- Der gesamte Datenverkehr wird über VPN abgewickelt, sodass Sie nicht ins Internet gelangen können
Was ich jetzt tun werde, werde ich Ihnen sagen, aber zuerst ein wenig Automatisierung.
Automatische Eingabe des festen Teils des Passworts
Bis zum jetzigen Zeitpunkt haben Sie das Passwort höchstwahrscheinlich bereits mindestens fünf Mal eingegeben, und dieser Vorgang hat Sie bereits ziemlich müde gemacht. Erstens, weil das Passwort lang ist, und zweitens, weil Sie bei der Eingabe einen festgelegten Zeitraum einhalten müssen
Die endgültige Lösung des Problems war nicht im Artikel enthalten, kann jedoch so vorgenommen werden, dass der feste Teil des Kennworts nicht mehrmals eingegeben werden muss.
Angenommen, der feste Teil des Kennworts ist fixedPassword und ein Teil des Google Authenticator 567 987. Das gesamte Kennwort von openconnect kann über die Standardeingabe mit dem Argument --passwd-on-stdin übergeben werden.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdin
Jetzt können Sie ständig zum zuletzt eingegebenen Befehl zurückkehren und dort nur einen Teil von Google Authenticator ändern.
Das Unternehmens-VPN erlaubt keinen Internetzugang.
Im Allgemeinen ist es nicht sehr unpraktisch, wenn Sie einen separaten Computer verwenden müssen, um zu einem Hub zu gelangen. Das Fehlen der Fähigkeit, mit Stackoverfow zu kopieren und einzufügen, kann die Arbeit im Allgemeinen lahm legen, sodass etwas getan werden muss.
Es ist notwendig, sich irgendwie zu organisieren, damit Linux, wenn Sie vom internen Netzwerk auf die Ressource zugreifen müssen, auf vpn wechselt und wenn Sie auf den Hub zugreifen müssen, auf das 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 an das Eingabeskript übergeben, und es führt die VPN-Konfiguration durch. Leider konnte ich nicht herausfinden, wie ich den Datenverkehr mithilfe eines nativen Skripts zwischen Unternehmens-VPN und dem Rest des Internets aufteilen kann.
Scheinbar speziell für Leute wie mich wurde das Dienstprogramm vpn-slice entwickelt, mit dem Sie den Datenverkehr auf zwei Kanälen leiten können, ohne mit einem Tamburin zu tanzen. Nun, das heißt, Sie müssen tanzen, aber ein Schamane ist nicht erforderlich.
Split Verkehr mit VPN-Slice
Zunächst muss vpn-slice installiert werden, das müssen Sie selbst herausfinden. Wenn es Fragen in den Kommentaren gibt, werde ich einen separaten Beitrag dazu schreiben. Dies ist jedoch ein reguläres Python-Programm, daher sollte es keine Schwierigkeiten geben. Ich setze mit virtualenv.
Und dann müssen Sie das Dienstprogramm verwenden und den --script-Schlüssel verwenden, 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
In --script wird eine Zeile mit dem 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 in vpn zu besuchenden Adressen. Hiermit meine ich, dass, wenn die Adresse mit 192.168.430 beginnt, die Ressource mit dieser Adresse in VPN gesucht werden muss
Jetzt sollte die Situation fast normal sein. Fast. Jetzt können Sie sich am Hub anmelden und Sie können sich über die IP-Adresse bei der internen Unternehmensressource anmelden, aber Sie können sich nicht über den symbolischen Namen bei der internen Unternehmensressource anmelden. Wenn Sie die Entsprechung des symbolischen Namens und der Adresse in Hosts registrieren, sollte alles funktionieren. Und arbeiten, bis sich die IP ändert. Linux kann nun abhängig von der IP-Adresse auf das Internet oder das Unternehmensnetzwerk zugreifen. Für die Ermittlung der Adresse wird jedoch weiterhin DNS von Drittanbietern verwendet.
Das Problem kann sich immer noch in dieser Form manifestieren - bei der Arbeit ist alles in Ordnung, und zu Hause können Sie nur über IP auf interne Unternehmensressourcen zugreifen. Dies liegt daran, dass, wenn Sie mit dem Firmen-WLAN verbunden sind, auch der Firmen-DNS verwendet wird und darin die symbolischen Adressen aus dem VPN aufgelöst werden, obwohl es immer noch unmöglich ist, ohne Verwendung eines VPN zu einer solchen Adresse zu gelangen.
Automatische Änderung der Hosts-Datei
Wenn Sie höflich nach vpn-slice fragen, kann das VPN nach dem Erhöhen zu seinem DNS gehen, die IP-Adressen der erforderlichen Ressourcen dort anhand ihrer symbolischen Namen finden und sie in Hosts eingeben. Nach dem Deaktivieren von VPN werden diese Adressen von den Hosts entfernt. Übergeben Sie dazu symbolische Namen als Argumente an vpn-slice. 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 alles sowohl im Büro als auch am Strand funktionieren.
Suchen Sie nach Adressen aller Subdomains im DNS, das das VPN angegeben hat
Wenn es nur wenige Adressen im Netzwerk gibt, funktioniert der Ansatz, die Hosts-Datei automatisch zu ändern, einwandfrei. Wenn sich jedoch viele Ressourcen im Netzwerk befinden, müssen Sie ständig Zeilen wie zoidberg.test.evilcorp.com zum Skript zoidberg hinzufügen. Dies ist der Name eines der Teststände.
Aber jetzt haben wir ein wenig Verständnis dafür, warum dieses Bedürfnis beseitigt werden kann.
Wenn Sie nach dem Erhöhen des VPN nach / etc / hosts suchen, sehen Sie, dass hier eine Zeile steht
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
Ja, und eine neue Zeile wurde zu resolv.conf hinzugefügt. Kurz gesagt, vpn-slice hat irgendwie festgestellt, wo sich der DNS-Server für vpn befindet.
Jetzt müssen wir sicherstellen, dass Linux zur Ermittlung der IP-Adresse des Domainnamens, der auf evilcorp.com endet, zu Unternehmens-DNS gewechselt ist. Wenn etwas anderes benötigt wird, wird standardmäßig verwendet.
Ich habe lange gegoogelt und festgestellt, dass solche Funktionen sofort verfügbar sind. Dies bezieht sich auf die Fähigkeit, den lokalen DNS-DNSMASQ-Server zum Auflösen von Namen zu verwenden.
Das heißt, Sie können Linux veranlassen, immer auf den lokalen DNS-Server nach IP-Adressen zu suchen, die wiederum abhängig vom Domänennamen auf dem entsprechenden externen DNS-Server nach IP suchen.
Um alles zu verwalten, was mit Netzwerken und Netzwerkverbindungen zu tun hat, verwendet Ubunt den NetworkManager und die grafische Benutzeroberfläche, über die beispielsweise eine Wi-Fi-Verbindung ausgewählt werden kann, ist genau das Richtige.
Wir müssen in seiner Konfiguration klettern.
- Erstellen Sie eine Datei in /etc/NetworkManager/dnsmasq.d/evilcorp
address = /. evilcorp.com/192.168.430.534
Achte auf den Punkt vor evilcorp. Es signalisiert dnsmasq, dass alle evilcorp.com-Subdomains im Unternehmens-DNS gesucht werden müssen.
- Weisen Sie NetworkManager an, dnsmasq zum Auflösen von Namen zu verwenden
Die Konfiguration des Netzwerkmanagers befindet sich in /etc/NetworkManager/NetworkManager.conf. Sie müssen dort Folgendes hinzufügen:
[main]
dns = dnsmasq
- Starten Sie NetworkManager neu
service network-manager restart
Nach dem Herstellen einer VPN-Verbindung mit einer Reihe von openconnect- und vpn-slice-Elementen wird ip nun normalerweise erkannt, auch wenn Sie den Argumenten für vpnslice keine symbolischen Adressen hinzufügen.
So gehen Sie über VPN zu separaten Diensten
Nachdem sich herausstellte, dass eine Verbindung zu VPN hergestellt werden sollte, war ich zwei Tage lang sehr zufrieden. Dann stellte sich heraus, dass E-Mail nicht funktioniert, wenn Sie eine Verbindung zu VPN herstellen, die nicht über das Büronetzwerk erfolgt. Ein bekanntes Symptom, nicht wahr?
Unsere Mail befindet sich in mail.publicevilcorp.com, was bedeutet, dass sie nicht unter die Regel in dnsmasq fällt und die Adresse des Mailservers über öffentliches DNS durchsucht wird.
Nun, das Büro verwendet immer noch den DNS, in dem sich diese Adresse befindet. Das dachte ich mir. Nach dem Hinzufügen einer Zeile zu dnsmasq
address = / mail.publicevilcorp.com / 192.168.430.534
Die Situation hat sich nicht geändert. ip ist gleich geblieben. Ich musste zur Arbeit gehen.
Und erst dann, als ich mich mit der Situation befasst und das Problem ein wenig geklärt hatte, sagte mir eine kluge Person, wie ich es lösen sollte. Die Verbindung zum Mailserver musste nicht einfach so, sondern über VPN hergestellt werden
Ich verwende vpn-slice, um über das VPN zu Adressen zu gelangen, die mit 192.168.430 beginnen. Und auf dem Mailserver ist nicht nur die symbolische Adresse keine Unterdomäne von evilcorp, sondern auch eine IP-Adresse, die nicht mit 192.168.430 beginnt. Und natürlich lässt er niemanden aus dem allgemeinen Netzwerk heraus.
Damit Linux über das VPN auf den Mailserver zugreifen kann, müssen Sie ihn zu vpn-slice hinzufügen. Angenommen, die Adresse des Mailers 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 Auslösen eines VPN mit einem Argument
All dies ist natürlich nicht sehr bequem. Ja, Sie können den Text in einer Datei speichern und in die Konsole kopieren, anstatt mit den Händen zu tippen, aber es ist immer noch nicht angenehm genug. 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 567987
Aber aus irgendeinem Grund müssen Sie jetzt die Konsole, in der openconnect ausgeführt wird, geöffnet lassen
Openconnect-Start im Hintergrund
Glücklicherweise haben sich die Autoren von openconnect um uns gekümmert und dem Programm einen speziellen Key - Background hinzugefügt, der das Programm nach dem Start im Hintergrund laufen lässt. 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 nicht klar, wohin die Protokolle gehen. Protokolle werden für uns in der Regel nicht wirklich benötigt, aber Sie wissen es nie. openconnect kann sie an syslog weiterleiten, wo sie intakt bleiben. Sie müssen den --syslog-Schlüssel 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 den ps-Auspuff natürlich mit einem Grep herausfiltern und nach einem Prozess suchen, in dessen Namen openconnect steht, der aber irgendwie trostlos ist. Vielen Dank an die Autoren, die darüber nachgedacht haben. Openconnect verfügt über den Schlüssel --pid-file, mit dem Sie openconnect anweisen können, 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-pid
Jetzt können Sie den Vorgang jederzeit mit dem Befehl ausführen
kill $(cat ~/vpn-pid)
Wenn es keinen Prozess gibt, wird kill schwören, aber keinen Fehler auslösen. Wenn keine Datei vorhanden ist, geschieht auch nichts Schlimmes, sodass Sie den Prozess in der ersten Zeile des Skripts sicher 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-pid
Jetzt können Sie den Computer einschalten, die Konsole öffnen und den Befehl ausführen, indem Sie den Code von Google Authenticator übergeben. Die Konsole kann dann genagelt werden.
Ohne VPN-Slice. Anstelle eines Nachwortes
Es war sehr schwer zu verstehen, wie man ohne vpn-slice lebt. Ich musste viel lesen und googeln. Zum Glück, wenn ich so viel Zeit mit dem Problem verbracht habe, lesen sich technische Handbücher und sogar man openconnect wie aufregende Romane.
Als Ergebnis fand ich heraus, dass vpn-slice wie das native Skript die Routing-Tabelle so ändert, dass sie Netzwerke trennt.
Routing-Tabelle
In einfachen Worten, eine solche Tabelle in der ersten Spalte enthält, wo die Adresse beginnen soll, zu der Linux wechseln möchte, und in der zweiten Spalte, über welche Netzwerkkarte diese Adresse aufgerufen werden soll. Tatsächlich gibt es mehr Spalten, aber dies ä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
Hier ist jede Zeile dafür verantwortlich, wohin sie gehen soll, um eine Nachricht an eine Adresse zu senden. Die erste ist eine Beschreibung, wo die Adresse beginnen soll. Um zu verstehen, wie man feststellt, dass 192.168.0.0/16 bedeutet, dass die Adresse mit 192.168 beginnen muss, müssen Sie googeln, wie die Maske der IP-Adresse lautet. Nach dev steht der Name des Adapters, an den die Nachricht gesendet werden soll.
Für VPN hat Linux einen virtuellen Adapter erstellt - tun0. Damit der Datenverkehr für alle Adressen, die mit 192.168 beginnen, durchläuft, antwortet die Leitung
192.168.0.0/16 dev tun0 scope link
Sie können den aktuellen Status der Routingtabelle auch mit dem Befehl route -n abrufen (IP-Adressen sind anonym talentiert). Dieser Befehl führt zu einer anderen Form und ist im Allgemeinen veraltet. Die Ausgabe stößt jedoch häufig auf Online-Handbücher und muss gelesen werden können.
Wo die IP-Adresse für die Route beginnen soll, ist aus der Kombination der Spalten Destination und Genmask ersichtlich. Die Teile der IP-Adresse, denen die Nummern 255 in Genmask entsprechen, werden berücksichtigt, die Teile, denen 0 nicht entspricht. 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, eine Anforderung an diese Route erfolgt. Wenn das Ziel 192.168.0.0 ist, Genmask jedoch 255.255.0.0, werden Anforderungen an Adressen, die mit 192.168 beginnen, auf dieser Route ausgeführt
Um herauszufinden, was vpn-slice tatsächlich macht, habe ich mich vorher und nachher mit dem Zustand der Tabellen befasst
Vor der Aktivierung 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 wlp3s0
Nach 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 tun0
Und 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 tun0
Es ist zu sehen, dass openconnect, wenn Sie nicht vpn-slice verwenden, explizit schreibt, dass Sie vpn an alle Adressen senden müssen, mit Ausnahme der separat angegebenen Adressen.
Hier:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0
In der Nähe wurde sofort ein anderer Pfad angegeben, der verwendet werden sollte, wenn die Adresse, die Linux zu durchlaufen versucht, keiner Maske aus der Tabelle entspricht.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0
Hier wurde bereits geschrieben, dass Sie in diesem Fall den Standard-WLAN-Adapter verwenden müssen.
Ich glaube, dass der Pfad für das VPN verwendet wird, weil es das erste in der Routingtabelle ist.
Und theoretisch sollte, wenn Sie diesen Standardpfad aus der Routingtabelle entfernen, in Verbindung mit dnsmasq openconnect den normalen Betrieb sicherstellen.
Ich habe es versucht
route del default
Und es hat funktioniert.
Weiterleiten von Anforderungen an einen Mailserver ohne VPN-Slice
Aber ich habe auch einen Mail-Server mit der Adresse 555.555.555.555, den Sie auch über VPN gehen müssen. Der Weg dorthin muss ebenfalls von Hand hinzugefügt werden.
ip route add 555.555.555.555 via dev tun0
Und jetzt alle Regeln. Sie können also auf vpn-slice verzichten, aber Sie müssen bereits genau wissen, was Sie tun. Ich denke jetzt darüber nach, die Entfernung der Standardroute und die Route für den Mailer nach dem Herstellen einer Verbindung zu vpn in der letzten Zeile des nativen openconnect-Skripts hinzuzufügen, um die Anzahl der beweglichen Teile in meinem Fahrrad zu verringern.
Wahrscheinlich würde jemand, um zu verstehen, wie man ein VPN konfiguriert, genug von diesem Nachwort haben. Aber während ich versuchte zu verstehen, was und wie ich es tun sollte, las ich eine Menge solcher Handbücher, die für den Autor funktionieren, aber aus irgendeinem Grund nicht für mich funktionieren, und beschloss, alle gefundenen Stücke hier hinzuzufügen. Ich würde mich sehr über so etwas freuen.