Chcesz używać Linuksa w pracy, ale Twoja firmowa sieć VPN Ci na to nie pozwala? Wtedy ten artykuł może pomóc, chociaż nie jest to pewne. Z góry uprzedzam, że nie rozumiem dobrze zagadnień związanych z administracją siecią, więc możliwe, że wszystko zrobiłem źle. Z drugiej strony jest jednak możliwość, że uda mi się napisać poradnik w taki sposób, aby był zrozumiały dla zwykłych ludzi, dlatego radzę spróbować.
Artykuł zawiera mnóstwo niepotrzebnych informacji, jednak bez tej wiedzy nie byłbym w stanie rozwiązać problemów, które niespodziewanie mi się pojawiły przy zakładaniu VPN. Myślę, że każdy, kto spróbuje skorzystać z tego poradnika, będzie miał problemy, których ja nie miałem i mam nadzieję, że te dodatkowe informacje pomogą samodzielnie rozwiązać te problemy.
Większość poleceń użytych w tym przewodniku należy uruchomić za pomocą sudo, które zostało usunięte ze względu na zwięzłość. Pamiętać.
Większość adresów IP została poważnie zaciemniona, więc jeśli widzisz adres taki jak 435.435.435.435, musi to być jakiś normalny adres IP, specyficzny dla Twojego przypadku.
Mam Ubuntu 18.04, ale myślę, że po niewielkich zmianach przewodnik można zastosować w innych dystrybucjach. Jednak w tym tekście Linux == Ubuntu.
Cisco Connect
Osoby korzystające z systemu Windows lub MacOS mogą połączyć się z naszą korporacyjną siecią VPN za pośrednictwem Cisco Connect, która musi określić adres bramy i przy każdym połączeniu wprowadzić hasło składające się ze stałej części i kodu wygenerowanego przez Google Authenticator.
W przypadku Linuksa nie udało mi się uruchomić Cisco Connect, ale udało mi się znaleźć w Google rekomendację dotyczącą korzystania z openconnect, stworzoną specjalnie w celu zastąpienia Cisco Connect.
Otwórz połączenie
Teoretycznie Ubuntu ma specjalny interfejs graficzny dla openconnect, ale u mnie to nie działało. Może tak będzie lepiej.
W systemie Ubuntu openconnect jest instalowany z menedżera pakietów.
apt install openconnectNatychmiast po instalacji możesz spróbować połączyć się z VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com to adres fikcyjnej sieci VPN
poxvuibr – fikcyjna nazwa użytkownika
openconnect poprosi Cię o podanie hasła, które, przypominam, składa się ze stałej części i kodu z Google Authenticator, a następnie spróbuje połączyć się z VPN. Jeśli to zadziała, gratulacje, możesz bezpiecznie pominąć środek, który jest bardzo uciążliwy i przejść do punktu o działaniu openconnect w tle. Jeśli to nie zadziała, możesz kontynuować. Chociaż jeśli zadziałało podczas łączenia się na przykład z gościnnym Wi-Fi w pracy, może być za wcześnie na radość, warto spróbować powtórzyć procedurę z domu.
Certyfikat
Istnieje duże prawdopodobieństwo, że nic się nie uruchomi, a wynik openconnect będzie wyglądał mniej więcej tak:
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 progressZ jednej strony jest to nieprzyjemne, bo nie było połączenia z VPN, ale z drugiej strony, jak rozwiązać ten problem, jest w zasadzie jasne.
Tutaj serwer przesłał nam certyfikat, po którym możemy stwierdzić, że połączenie jest nawiązywane z serwerem naszej rodzimej korporacji, a nie ze złym oszustem, a ten certyfikat jest nieznany systemowi. Dlatego nie może sprawdzić, czy serwer jest prawdziwy, czy nie. I tak na wszelki wypadek przestaje działać.
Aby openconnect mógł połączyć się z serwerem, musisz wyraźnie powiedzieć mu, który certyfikat powinien pochodzić z serwera VPN, używając klucza —servercert
Możesz dowiedzieć się, który certyfikat wysłał nam serwer bezpośrednio z tego, co wydrukował openconnect. Oto z tego fragmentu:
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 progressZa pomocą tego polecenia możesz spróbować połączyć się ponownie
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comByć może teraz już działa, wtedy możesz przejść do końca. Ale osobiście Ubunta pokazał mi figę w tej formie
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 rozwiąże problem, ale nie będziesz mógł tam wejść. Adresy takie jak jira.evilcorp.com nie są w ogóle rozpoznawane.
To, co się tutaj wydarzyło, nie jest dla mnie jasne. Ale eksperyment pokazuje, że jeśli dodasz linię do /etc/resolv.conf
nameserver 192.168.430.534wtedy adresy wewnątrz VPN zaczną się magicznie rozpoznawać i będziesz mógł przez nie przejść, to znaczy to, czego szuka DNS, aby rozwiązać adresy, wygląda konkretnie w /etc/resolv.conf, a nie gdzie indziej.
Możesz sprawdzić, czy istnieje połączenie z VPN i działa ono bez dokonywania jakichkolwiek zmian w pliku /etc/resolv.conf, w tym celu wystarczy wpisać w przeglądarce nie symboliczną nazwę zasobu z VPN, ale jego adres IP
W efekcie pojawiają się dwa problemy
- Podczas łączenia się z VPN jego DNS nie jest odbierany
- cały ruch przechodzi przez VPN, co nie pozwala na dostęp do Internetu
Powiem ci, co teraz zrobić, ale najpierw trochę automatyzacji.
Automatyczne wprowadzenie stałej części hasła
Do tej pory najprawdopodobniej wprowadziłeś już hasło co najmniej pięć razy i ta procedura już Cię zmęczyła. Po pierwsze dlatego, że hasło jest długie, a po drugie dlatego, że przy wejściu trzeba zmieścić się w określonym przedziale czasu
W artykule nie zawarto ostatecznego rozwiązania problemu, ale można mieć pewność, że stała część hasła nie będzie musiała być wpisana wielokrotnie.
Załóżmy, że stała część hasła to fixPassword, a część z Google Authenticator to 567 987. Całe hasło można przekazać do openconnect poprzez standardowe wejście za pomocą argumentu --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinTeraz możesz stale wracać do ostatnio wprowadzonego polecenia i zmieniać tam tylko część Google Authenticator.
Korporacyjna sieć VPN nie pozwala na surfowanie po Internecie.
Ogólnie rzecz biorąc, nie jest to zbyt niewygodne, gdy trzeba skorzystać z osobnego komputera, aby udać się do Habr. Brak możliwości kopiowania i wklejania ze stosu może ogólnie paraliżować pracę, więc trzeba coś zrobić.
Musimy to jakoś zorganizować tak, aby gdy trzeba uzyskać dostęp do zasobu z sieci wewnętrznej, Linux trafiał do VPN, a gdy trzeba udać się do Habr, trafiał do Internetu.
openconnect po uruchomieniu i nawiązaniu połączenia z VPN wykonuje specjalny skrypt, który znajduje się w /usr/share/vpnc-scripts/vpnc-script. Niektóre zmienne są przekazywane do skryptu jako dane wejściowe, które konfigurują VPN. Niestety nie wiedziałem, jak podzielić przepływ ruchu pomiędzy korporacyjną sieć VPN a resztę Internetu za pomocą natywnego skryptu.
Najwyraźniej narzędzie VPN-slice zostało opracowane specjalnie dla osób takich jak ja, które pozwala przesyłać ruch dwoma kanałami bez tańczenia z tamburynem. Cóż, to znaczy, że będziesz musiał tańczyć, ale nie musisz być szamanem.
Separacja ruchu za pomocą VPN-slice
Po pierwsze, będziesz musiał zainstalować VPN-slice, będziesz musiał sam to rozgryźć. Jeśli w komentarzach będą pytania, napiszę o tym osobny post. Ale to jest zwykły program w Pythonie, więc nie powinno być żadnych trudności. Zainstalowałem przy użyciu virtualenv.
Następnie należy zastosować narzędzie, używając przełącznika -script, wskazując, że aby otworzyć połączenie, zamiast standardowego skryptu należy użyć VPN-slice
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 " vpn.evilcorp.com --script otrzymuje ciąg znaków z poleceniem, które należy wywołać zamiast skryptu. ./bin/vpn-slice - ścieżka do pliku wykonywalnego VPN-slice 192.168.430.0/24 - maska adresów, do których należy przejść w VPN. Mamy tutaj na myśli, że jeśli adres zaczyna się od 192.168.430, to zasób o tym adresie należy przeszukać wewnątrz VPN
Sytuacja powinna być już prawie normalna. Prawie. Teraz możesz przejść do Habr i możesz przejść do zasobu wewnątrzkorporacyjnego po adresie IP, ale nie możesz przejść do zasobu wewnątrzkorporacyjnego po nazwie symbolicznej. Jeśli określisz dopasowanie pomiędzy symboliczną nazwą i adresem w hostach, wszystko powinno działać. I pracuj, aż zmieni się adres IP. Linux może teraz uzyskać dostęp do Internetu lub intranetu, w zależności od adresu IP. Jednak do określenia adresu nadal używany jest system DNS niekorporacyjny.
Problem może objawiać się również w tej formie – w pracy wszystko jest w porządku, natomiast w domu dostęp do wewnętrznych zasobów firmy można uzyskać jedynie poprzez IP. Dzieje się tak dlatego, że gdy jesteś podłączony do firmowej sieci Wi-Fi, używany jest również korporacyjny DNS i w nim rozpoznawane są adresy symboliczne z VPN, mimo że nadal nie da się przejść pod taki adres bez użycia VPN.
Automatyczna modyfikacja pliku hosts
Jeśli VPN-Slice zostanie grzecznie zapytany, to po podniesieniu VPN może przejść do swojego DNS, znaleźć tam adresy IP niezbędnych zasobów według ich symbolicznych nazw i wprowadzić je w hostach. Po wyłączeniu VPN adresy te zostaną usunięte z hostów. Aby to zrobić, musisz przekazać nazwy symboliczne do VPN-slice jako argumenty. Lubię to.
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 Teraz wszystko powinno działać zarówno w biurze, jak i na plaży.
Wyszukaj adresy wszystkich subdomen w DNS nadanym przez VPN
Jeśli w sieci jest niewiele adresów, metoda automatycznej modyfikacji pliku hosts sprawdza się całkiem nieźle. Ale jeśli w sieci jest dużo zasobów, będziesz musiał stale dodawać do skryptu linie takie jak zoidberg.test.evilcorp.com. zoidberg to nazwa jednego ze stanowisk testowych.
Ale teraz, gdy już trochę rozumiemy, dlaczego tę potrzebę można wyeliminować.
Jeśli po podniesieniu VPN zajrzysz do /etc/hosts, zobaczysz tę linię
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOUTWÓRZONE
Dodano nową linię do pliku resolv.conf. Krótko mówiąc, VPN-Slice w jakiś sposób określił, gdzie znajduje się serwer DNS dla VPN.
Teraz musimy się upewnić, że aby poznać adres IP domeny kończącej się na evilcorp.com, Linux przejdzie do korporacyjnego DNS, a jeśli potrzebne będzie coś innego, to do domyślnego.
Szukałem w Google przez dłuższy czas i odkryłem, że taka funkcja jest dostępna w Ubuntu od razu po wyjęciu z pudełka. Oznacza to możliwość wykorzystania lokalnego serwera DNS dnsmasq do rozpoznawania nazw.
Oznacza to, że możesz mieć pewność, że Linux zawsze kieruje się do lokalnego serwera DNS w celu uzyskania adresów IP, który z kolei, w zależności od nazwy domeny, będzie szukać adresu IP na odpowiednim zewnętrznym serwerze DNS.
Do zarządzania wszystkim, co jest związane z sieciami i połączeniami sieciowymi, Ubuntu używa NetworkManagera, a interfejs graficzny umożliwiający na przykład wybieranie połączeń Wi-Fi jest tylko jego interfejsem.
Będziemy musieli wspiąć się na jego konfigurację.
- Utwórz plik w /etc/NetworkManager/dnsmasq.d/evilcorp
adres=/.evilcorp.com/192.168.430.534
Zwróć uwagę na punkt przed złym korpusem. Sygnalizuje dnsmasq, że wszystkie subdomeny evilcorp.com powinny zostać przeszukane w korporacyjnym dns.
- Powiedz NetworkManagerowi, aby używał dnsmasq do rozpoznawania nazw
Konfiguracja menedżera sieci znajduje się w /etc/NetworkManager/NetworkManager.conf. Musisz tam dodać:
[główne] dns=dnsmasq
- Uruchom ponownie NetworkManagera
service network-manager restartTeraz, po połączeniu się z VPN za pomocą openconnect i VPN-slice, adres IP zostanie określony normalnie, nawet jeśli nie dodasz adresów symbolicznych do argumentów vpnslice.
Jak uzyskać dostęp do poszczególnych usług przez VPN
Po tym, jak udało mi się połączyć z VPN, przez dwa dni byłem bardzo szczęśliwy, a potem okazało się, że jeśli połączę się z VPN spoza sieci biurowej, to poczta nie działa. Objaw jest znajomy, prawda?
Nasza poczta znajduje się w mail.publicevilcorp.com, co oznacza, że nie podlega regułom dnsmasq, a adres serwera pocztowego jest przeszukiwany przez publiczny DNS.
Cóż, biuro nadal korzysta z DNS, który zawiera ten adres. To jest to co myślałam. W rzeczywistości po dodaniu linii do dnsmasq
adres=/mail.publicevilcorp.com/192.168.430.534
sytuacja w ogóle się nie zmieniła. ip pozostało takie samo. Musiałem iść do pracy.
I dopiero później, gdy zagłębiłem się w sytuację i trochę zrozumiałem problem, jedna mądra osoba powiedziała mi, jak go rozwiązać. Konieczne było połączenie się z serwerem pocztowym nie tylko w ten sposób, ale przez VPN
Używam VPN-slice, aby przejść przez VPN do adresów zaczynających się od 192.168.430. A serwer pocztowy nie tylko ma adres symboliczny, który nie jest subdomeną evilcorp, ale także nie ma adresu IP zaczynającego się od 192.168.430. I oczywiście nie pozwala, aby ktokolwiek z sieci ogólnej przychodził do niego.
Aby Linux mógł przejść przez VPN i do serwera pocztowego, musisz dodać go również do VPN-slice. Załóżmy, że adres nadawcy to 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 Skrypt podnoszący VPN z jednym argumentem
Wszystko to oczywiście nie jest zbyt wygodne. Tak, możesz zapisać tekst do pliku i skopiować i wkleić go do konsoli, zamiast wpisywać go ręcznie, ale nadal nie jest to zbyt przyjemne. Aby ułatwić ten proces, możesz zawinąć polecenie w skrypt, który będzie zlokalizowany w PATH. Następnie wystarczy wpisać kod otrzymany z Google Authenticator
#!/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 Jeśli umieścisz skrypt w connect~evilcorp~, możesz po prostu pisać w konsoli
connect_evil_corp 567987Ale teraz z jakiegoś powodu nadal musisz zachować otwartą konsolę, w której działa openconnect
Uruchamianie openconnect w tle
Na szczęście autorzy openconnect zaopiekowali się nami i dodali do programu specjalny klucz -background, który sprawia, że program po uruchomieniu będzie działał w tle. Jeśli uruchomisz to w ten sposób, możesz zamknąć konsolę po uruchomieniu
#!/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 Teraz po prostu nie jest jasne, dokąd trafiają dzienniki. Ogólnie rzecz biorąc, tak naprawdę nie potrzebujemy logów, ale nigdy nic nie wiadomo. openconnect może przekierować je do syslog, gdzie będą bezpieczne. musisz dodać przełącznik –syslog do polecenia
#!/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 I tak okazuje się, że openconnect działa gdzieś w tle i nikomu nie przeszkadza, ale nie wiadomo, jak to zatrzymać. Oznacza to, że możesz oczywiście filtrować dane wyjściowe ps za pomocą grep i szukać procesu, którego nazwa zawiera openconnect, ale jest to w pewnym sensie nudne. Dziękuję autorom, którzy również o tym pomyśleli. Openconnect ma klucz -pid-plik, za pomocą którego możesz poinstruować openconnect, aby zapisał swój identyfikator procesu do pliku.
#!/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-pidTeraz zawsze możesz zabić proces za pomocą polecenia
kill $(cat ~/vpn-pid)Jeśli nie ma procesu, kill przeklnie, ale nie zgłosi błędu. Jeśli pliku tam nie ma, to też nic złego się nie stanie, więc możesz spokojnie zakończyć proces w pierwszej linijce skryptu.
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-pidTeraz możesz włączyć komputer, otworzyć konsolę i uruchomić polecenie, przekazując mu kod z Google Authenticator. Następnie można przybić konsolę.
Bez kawałka VPN. Zamiast posłowia
Okazało się, że bardzo trudno jest zrozumieć, jak żyć bez kawałka VPN. Musiałem dużo czytać i googlować. Na szczęście po spędzeniu tak dużej ilości czasu z problemem podręczniki techniczne, a nawet man openconnect czyta się jak ekscytujące powieści.
W rezultacie dowiedziałem się, że VPN-slice, podobnie jak natywny skrypt, modyfikuje tablicę routingu, aby oddzielić sieci.
Tabela routingu
Mówiąc prościej, jest to tabela w pierwszej kolumnie, która zawiera, od czego powinien zaczynać się adres, przez który Linux chce przejść, a w drugiej kolumnie, przez którą kartę sieciową ma przejść pod tym adresem. Tak naprawdę głośników jest więcej, ale to nie zmienia istoty rzeczy.
Aby wyświetlić tablicę routingu, należy uruchomić polecenie ip Route
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 Tutaj każda linia odpowiada za to, dokąd należy się udać, aby wysłać wiadomość na jakiś adres. Pierwszy to opis tego, od czego adres powinien się zaczynać. Aby zrozumieć, jak ustalić, że 192.168.0.0/16 oznacza, że adres powinien zaczynać się od 192.168, musisz sprawdzić w Google, czym jest maska adresu IP. Po dev znajduje się nazwa adaptera, do którego należy wysłać wiadomość.
Dla VPN Linux stworzył wirtualny adapter - tun0. Linia zapewnia, że przechodzi przez nią ruch dla wszystkich adresów zaczynających się od 192.168
192.168.0.0/16 dev tun0 scope link Za pomocą polecenia możesz także sprawdzić bieżący stan tablicy routingu route -n (Adresy IP są sprytnie anonimizowane) To polecenie generuje wyniki w innej formie i jest generalnie przestarzałe, ale jego dane wyjściowe często można znaleźć w podręcznikach w Internecie i trzeba umieć je przeczytać.
Miejsce, w którym powinien zaczynać się adres IP trasy, można odczytać z kombinacji kolumn Destination i Genmask. Te części adresu IP, które odpowiadają cyfrom 255 w Genmask, są brane pod uwagę, ale te, w których jest 0, nie są brane pod uwagę. Oznacza to, że kombinacja Destination 192.168.0.0 i Genmask 255.255.255.0 oznacza, że jeśli adres zaczyna się od 192.168.0, wówczas żądanie do niego będzie przebiegać tą trasą. A jeśli Destination 192.168.0.0, ale Genmask 255.255.0.0, wówczas żądania do adresów zaczynających się od 192.168 będą przesyłane tą trasą
Aby dowiedzieć się, co właściwie robi VPN-slice, postanowiłem przyjrzeć się stanom tabel przed i po
Przed włączeniem VPN było tak
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 wlp3s0Po wywołaniu openconnect bez VPN-slice stało się tak
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 tun0I po wywołaniu openconnect w połączeniu z takim plasterkiem VPN
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 tun0Można zauważyć, że jeśli nie używasz VPN-slice, to openconnect wyraźnie pisze, że wszystkie adresy, z wyjątkiem tych wyraźnie wskazanych, muszą być dostępne przez VPN.
Tutaj:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Tam obok od razu wskazywana jest kolejna ścieżka, której należy użyć, jeśli adres, przez który próbuje przejść Linux, nie pasuje do żadnej maski z tabeli.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Napisano już tutaj, że w tym przypadku trzeba użyć standardowego adaptera Wi-Fi.
Uważam, że używana jest ścieżka VPN, ponieważ jest pierwsza w tabeli routingu.
I teoretycznie, jeśli usuniesz tę domyślną ścieżkę z tablicy routingu, to w połączeniu z dnsmasq openconnect powinien zapewnić normalne działanie.
próbowałem
route del defaultI wszystko zadziałało.
Kierowanie żądań do serwera pocztowego bez segmentu VPN
Ale mam też serwer pocztowy o adresie 555.555.555.555, do którego również trzeba uzyskać dostęp przez VPN. Trasę do niego również należy dodać ręcznie.
ip route add 555.555.555.555 via dev tun0A teraz wszystko jest w porządku. Możesz więc obejść się bez plasterka VPN, ale musisz dobrze wiedzieć, co robisz. Zastanawiam się teraz nad dodaniem do ostatniej linijki natywnego skryptu openconnect usunięcia domyślnej trasy i dodania trasy dla mailera po połączeniu się z VPN, tak żeby w moim rowerze było mniej ruchomych części.
Prawdopodobnie to posłowie wystarczyłoby, aby ktoś zrozumiał, jak skonfigurować VPN. Ale kiedy próbowałem zrozumieć, co i jak zrobić, przeczytałem całkiem sporo takich poradników, które działają dla autora, ale z jakiegoś powodu nie działają dla mnie, i zdecydowałem się dodać tutaj wszystkie kawałki, które znalazłem. Byłbym bardzo szczęśliwy z powodu czegoś takiego.
Źródło: www.habr.com