Chcesz używać Linuksa w pracy, ale firmowy VPN tego nie pozwala? W takim razie ten artykuł może pomóc, chociaż nie jest to pewne. Chcę wcześniej ostrzec, że słabo rozumiem kwestie administracji sieci, więc nie wykluczam, że zrobiłem wszystko źle. Z drugiej strony, istnieje szansa, że mogę napisać poradnik, który będzie zrozumiały dla zwykłych ludzi, dlatego polecam spróbować.
W artykule znajduje się dużo zbędnych informacji, ale bez tej wiedzy nie udałoby mi się rozwiązać problemów, które niespodziewanie pojawiały się przy konfiguracji VPN. Myślę, że każdy, kto spróbuje skorzystać z tego poradnika, napotka problemy, których ja nie miałem, i mam nadzieję, że te dodatkowe informacje pomogą rozwiązać je samodzielnie.
Większość poleceń używanych w poradniku należy wykonywać przez sudo, które dla skrótu zostało pominięte. Miej to na uwadze.
Większość adresów IP została brutalnie zafałszowana, dlatego jeśli zobaczysz adres podobny do 435.435.435.435 – tam powinien być jakiś normalny adres IP, specyficzny dla twojego przypadku.
Mam Ubuntu 18.04, ale myślę, że z niewielkimi poprawkami poradnik można stosować także do innych dystrybucji. Jednak w tym tekście linux == Ubuntu.
Cisco Connect
Osoby korzystające z Windows lub MacOS mogą połączyć się z naszym firmowym VPN przez Cisco Connect, któremu należy podać adres bramy i przy każdym połączeniu wprowadzić hasło składające się z części stałej oraz kodu generowanego przez Google Authenticator.
W przypadku Linuksa nie udało się zainstalować Cisco Connect, ale udało się znaleźć zalecenie użycia openconnect, stworzonego specjalnie w celu zastąpienia Cisco Connect.
Openconnect
Teoretycznie w Ubuntu istnieje specjalny interfejs graficzny dla openconnect, ale u mnie nie zadziałał. Może to i lepiej.
W Ubuntu openconnect instaluje się z menedżera pakietów.
apt install openconnectBezpośrednio po instalacji można spróbować połączyć się z VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com to adres fikcyjnego VPN
poxvuibr – to nazwa fikcyjnego użytkownika
openconnect poprosi o podanie hasła, które, przypominam, składa się z części stałej oraz kodu z Google Authenticator, a następnie spróbuje połączyć się z vpn. Jeśli się udało, gratulacje, możecie pominąć środek, w którym jest wiele bólu, i przejść do punktu o pracy openconnect w tle. Jeśli nie zadziałało, można kontynuować. Chociaż jeśli udało się połączyć na przykład z gościnnej sieci Wi-Fi w pracy, to możliwe, że radość jest przedwczesna, należy spróbować powtórzyć procedurę z domu.
Certyfikat
Z dużym prawdopodobieństwem nic się nie uruchomi, a wynik openconnect będzie wyglądał mniej więcej tak:
POST https://vpn.evilcorp.com/
Połączono z 777.777.777.777:443
Negocjacja SSL z vpn.evilcorp.com
Weryfikacja certyfikatu serwera nie powiodła się: podpisujący nie został znaleziony
Certyfikat z serwera VPN "vpn.evilcorp.com" nie przeszedł weryfikacji.
Powód: podpisujący nie znaleziony
Aby zaufać temu serwerowi w przyszłości, być może dodaj to do swojego wiersza poleceń:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Wpisz 'tak', aby zaakceptować, 'nie', aby przerwać; cokolwiek innego, aby wyświetlić: fgets (stdin): Operacja w tokuZ jednej strony jest to nieprzyjemne, ponieważ połączenie z VPN się nie udało, ale z drugiej strony, jak naprawić ten problem, w zasadzie wiadomo.
Serwer wysłał nam certyfikat, na podstawie którego można ustalić, że połączenie odbywa się do serwera macierzystej korporacji, a nie do złowrogiego oszusta, ale system nie zna tego certyfikatu. Dlatego nie może zweryfikować, czy serwer jest prawdziwy czy nie. I dlatego, na wszelki wypadek, przerywa działanie.
Aby openconnect jednak połączył się z serwerem, należy wyraźnie powiedzieć mu, jaki certyfikat powinien przyjść od serwera VPN za pomocą opcji —servercert
Aby dowiedzieć się, jaki certyfikat wysłał nam serwer, można to zrobić bezpośrednio z tego, co wydrukował openconnect. Oto ten fragment:
Aby zaufać temu serwerowi w przyszłości, być może dodaj to do swojego wiersza poleceń:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Wpisz 'tak', aby zaakceptować, 'nie', aby przerwać; cokolwiek innego, aby wyświetlić: fgets (stdin): Operacja w tokuMożna spróbować połączyć się jeszcze raz za pomocą takiej komendy
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comMożliwe, że teraz działa, wtedy można przejść do końca. Ale osobiście Ubuntu pokazało mi coś w tej formie.
POST https://vpn.evilcorp.com/
Połączono z 777.777.777.777:443
Negocjacje SSL z vpn.evilcorp.com
Weryfikacja certyfikatu serwera nie powiodła się: nie znaleziono podpisującego
Połączono z HTTPS na vpn.evilcorp.com
XML POST włączony
Proszę wprowadzić nazwę użytkownika i hasło.
POST https://vpn.evilcorp.com/
Otrzymano odpowiedź CONNECT: HTTP/1.1 200 OK
CSTP połączone. DPD 300, Keepalive 30
Ustawienie DTLS nie powiodło się; używanie SSL zamiast tego
Połączono jako 192.168.333.222, używając SSL
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
RTNETLINK odpowiada: Plik istnieje
/etc/resolvconf/update.d/libc: Ostrzeżenie: /etc/resolv.conf nie jest symbolicznym linkiem do /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 będzie rozwiązywać się, ale wejście będzie niemożliwe. Adresy typu jira.evilcorp.com w ogóle nie są rozwiązywane.
Co się tutaj wydarzyło, nie rozumiem. Ale eksperyment pokazuje, że jeśli dodasz do /etc/resolv.conf linię
nameserver 192.168.430.534to adresy wewnątrz VPN zaczną magicznie się rozwiązywać i będzie można do nich uzyskać dostęp, tzn. to, co szuka, jakimi DNS rozwiązać adresy, patrzy właśnie w /etc/resolv.conf, a nie gdzie indziej.
Można upewnić się, że połączenie z VPN jest i działa, nawet bez modyfikacji w /etc/resolv.conf, wystarczy wpisać w przeglądarkę nie symboliczne imię zasobu z vpn, a jego adres IP.
W rezultacie mamy dwa problemy
- przy połączeniu z VPN nie wczytuje jej DNS
- cały ruch idzie przez vpn, który nie pozwala na dostęp do internetu
Co robić, opowiem teraz, ale najpierw trochę automatyzacji.
Automatyczne wprowadzanie stałej części hasła
Na ten moment prawdopodobnie już wpisaliłeś hasło co najmniej pięć razy i ta procedura już cię znudziła. Po pierwsze, ponieważ hasło jest długie, po drugie ponieważ przy wprowadzaniu trzeba zmieścić się w stałym okresie czasu.
Ostateczne rozwiązanie problemu nie znalazło się w artykule, ale można zrobić tak, aby stała część hasła nie musiała być wprowadzana wiele razy.
Załóżmy, że stała część hasła to fixedPassword, a część z Google Authenticator to 567 987. Całe hasło openconnect można przekazać przez standardowe wejście za pomocą argumentu --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinTeraz można ciągle wracać do ostatnio wprowadzonej komendy i zmieniać tam tylko część z Google Authenticator.
Korzytowy VPN nie pozwala na dostęp do internetu.
W ogóle nie jest to wygodne, kiedy aby wejść na habr trzeba używać osobnego komputera. Brak możliwości kopiowania i wklejania ze stackoverflow może całkowicie sparaliżować pracę, dlatego trzeba coś zrobić.
Trzeba jakoś zorganizować, żeby gdy trzeba będzie wejść na zasób z wewnętrznej sieci, Linux łączył się przez VPN, a gdy trzeba będzie wejść na Habr — łączył się z internetem.
Openconnect po uruchomieniu i nawiązaniu połączenia z VPN, wykonuje specjalny skrypt, który znajduje się w /usr/share/vpnc-scripts/vpnc-script. Do skryptu przekazywane są pewne zmienne, a on dokonuje konfiguracji VPN. Niestety, nie udało mi się zrozumieć, jak podzielić strumienie ruchu pomiędzy firmowym VPN a pozostałym internetem za pomocą natywnego skryptu.
Widocznie specjalnie dla takich jak ja została opracowana aplikacja vpn-slice, która pozwala kierować ruch w dwóch kanałach bez większych trudności. No, to znaczy, będzie trzeba się trochę pomęczyć, ale nie trzeba być szamanem.
Podział ruchu za pomocą vpn-slice
Po pierwsze, trzeba zainstalować vpn-slice, z tym będę musiał poradzić sobie samodzielnie. Jeśli w komentarzach będą pytania, napiszę na ten temat osobny post. Ale to zwykły program w Pythonie, więc nie powinno być żadnych trudności. Instalowałem przez virtualenv.
Następnie trzeba zastosować aplikację, przy pomocy klucza —script, wskazując openconnect, co oznacza, że 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 W —script przekazywana jest linia z komendą, którą należy wywołać zamiast skryptu. ./bin/vpn-slice — ścieżka do pliku wykonywalnego vpn-slice 192.168.430.0/24 — maska adresów, po których należy przechodzić w VPN. Chodzi tutaj o to, że jeśli adres zaczyna się od 192.168.430 — to zasób z tym adresem należy szukać wewnątrz VPN.
Teraz sytuacja powinna być prawie w porządku. Prawie. Teraz można wejść na Habr i można wejść na wewnętrzny zasób po IP, ale nie można wejść na wewnętrzny zasób po nazwie symbolicznej. Jeśli zapiszesz odpowiadające sobie imię symboliczne i adres w hosts — wszystko powinno działać. I działać, dopóki IP się nie zmieni. Linux teraz umie łączyć się z internetem lub z wewnętrzną siecią w zależności od IP. Ale do określenia adresu wciąż używana jest niekorporacyjna usługa DNS.
Problem może również objawiać się w ten sposób — w pracy wszystko działa normalnie, a w domu dostęp do wewnętrznych zasobów korporacyjnych możliwy jest tylko przez IP. Dzieje się tak, ponieważ gdy jesteś podłączony do sieci Wi-Fi w firmie, używany jest również korporacyjny DNS, w którym adresy symboliczne z VPN są rozwiązywane, mimo że ich odwiedzenie bez użycia VPN nadal jest niemożliwe.
Automatyczna modyfikacja pliku hosts
Jeśli vpn-slice grzecznie poprosi, to po uruchomieniu VPN może zajrzeć do jego DNS, znaleźć tam adresy IP potrzebnych zasobów po ich nazwach symbolicznych i wpisać je do hosts. Po wyłączeniu VPN adresy te zostaną usunięte z hosts. W tym celu należy przekazać nazwy symboliczne do vpn-slice jako argumenty. Oto jak to zrobić.
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.
Wyszukiwanie adresów wszystkich subdomen w DNS, który przekazała VPN
Jeśli jest niewiele adresów w sieci, podejście z automatyczną modyfikacją pliku hosts jest jak najbardziej skuteczne. Ale jeśli zasobów w sieci jest dużo, konieczne będzie ciągłe dodawanie do skryptu linijek takich jak zoidberg.test.evilcorp.com, a zoidberg to nazwa jednego z testowych środowisk.
Ale teraz, gdy nieco lepiej rozumiemy sytuację, można tę potrzebę wyeliminować.
Jeśli po uruchomieniu VPN spojrzeć do /etc/hosts, można zobaczyć taką linię
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
A w resolv.conf dodano nową linię. Krótko mówiąc, vpn-slice w jakiś sposób zidentyfikował lokalizację serwera DNS dla VPN.
Teraz trzeba tak ustawić, aby Linux przy ustalaniu adresu IP nazwy domeny kończącej się na evilcorp.com korzystał z korporacyjnego DNS, a w przypadku innych informacji z domyślnego.
Długo szukałem w Google i odkryłem, że taka funkcjonalność istnieje w Ubuntu od razu. Mówię o możliwości użycia lokalnego serwera DNS dnsmasq do rozwiązywania nazw.
Można więc ustawić, aby Linux zawsze sprawdzał adresy IP na lokalnym serwerze DNS, który w zależności od nazwy domeny będzie poszukiwał IP na odpowiadającym zewnętrznym serwerze DNS.
Do zarządzania wszystkim, co związane z sieciami i połączeniami sieciowymi, w Ubuntu używa się NetworkManagera, a graficzny interfejs do wyboru na przykład połączenia WiFi to po prostu jego front.
Będziemy musieli poprzeszukiwać jego konfiguracje.
- Utwórz plik w /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Zwróć uwagę na kropkę przed evilcorp. Informuje ona dnsmasq, że wszystkie subdomeny evilcorp.com powinny być szukane właśnie w korporacyjnym DNS.
- Powiedz NetworkManagerowi, że do rozwiązywania nazw ma używać dnsmasq.
Konfiguracja network-managera znajduje się w /etc/NetworkManager/NetworkManager.conf. Musisz dodać tam:
[main]
dns=dnsmasq
- Zrestartuj NetworkManager.
service network-manager restartTeraz, po połączeniu z VPN za pomocą zestawu openconnect i vpn-slice, IP będzie prawidłowo ustalane, nawet jeśli nie dodaje się adresów symbolicznych do argumentów vpnslice.
Jak korzystać z VPN do określonych usług.
Po tym, jak udało mi się połączyć z VPN, przez dwa dni bardzo się cieszyłem, a potem odkryłem, że gdy łączę się z VPN nie z sieci biurowej, to nie działa poczta. Znajomy objaw, prawda?
Nasza poczta znajduje się na mail.publicevilcorp.com, więc nie podlega zasadzie w dnsmasq i adres serwera pocztowego jest poszukiwany przez publiczny DNS.
No a w biurze wciąż używa się DNS, w którym ten adres występuje. Tak myślałem. W rzeczywistości, po dodaniu do dnsmasq wpisu
address=/mail.publicevilcorp.com/192.168.430.534
sytuacja wcale się nie zmieniła. IP pozostało to samo. Musiałem chodzić do pracy.
A już później, gdy zagłębiłem się w sytuację i trochę rozszyfrowałem problem, jeden mądry człowiek podpowiedział mi, jak go rozwiązać. Należało połączyć się z serwerem pocztowym nie po prostu tak, ale przez VPN.
Używam vpn-slice, aby łączyć się przez VPN z adresami, które zaczynają się od 192.168.430. A adres serwera pocztowego nie tylko nie jest subdomeną evilcorp, ale także jego adres IP nie zaczyna się od 192.168.430. I w ogólnej sieci oczywiście nikogo do siebie nie wpuszcza.
Aby Linux mógł łączyć się przez VPN i z serwerem pocztowym, musisz dodać go do vpn-slice. Powiedzmy, że adres poczty 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 do uruchomienia VPN z jednym argumentem.
Oczywiście, to nie jest zbyt wygodne. Tak, można zapisać tekst do pliku i skopiować go do konsoli, zamiast wpisywać ręcznie, ale i tak jest mało przyjemnie. Aby ułatwić ten proces, można zawinąć komendę w skrypt, który będzie znajdował się w PATH. Wtedy wystarczy tylko wpisać kod 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~, to można po prostu pisać w konsoli.
connect_evil_corp 567987Ale teraz i tak trzeba utrzymywać otwartą konsolę, w której uruchomiony jest openconnect.
Uruchamianie openconnect w tle
Na szczęście autorzy openconnect zadbali o nas i dodali do programu specjalny klucz —background, który sprawia, że program po uruchomieniu działa w tle. Jeśli uruchomisz go w ten sposób, konsolę można po uruchomieniu zamknąć.
#!/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 tylko nie wiadomo, gdzie trafiają logi. Logi nie są nam w zasadzie bardzo potrzebne, ale tak dla pewności. openconnect może przekierować je do syslog, gdzie będą przechowywane w całości i bezpieczeństwie. Należy dodać do komendy klucz —syslog.
#!/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 w ten sposób openconnect działa gdzieś tam w tle i nikomu nie przeszkadza, ale jak go zatrzymać, nie wiadomo. Można oczywiście przefiltrować wyjście ps grepem i szukać procesu, którego nazwa zawiera openconnect, ale to jest dość męczące. Dzięki autorom, którzy o tym pomyśleli. W openconnect jest kluczyk —pid-file, za pomocą którego można polecić openconnect zapisać identyfikator swojego 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żna zabić proces poleceniem.
kill $(cat ~/vpn-pid)Jeśli procesu nie ma, kill wyświetli błąd, ale nie zgłosi wyjątku. Jeśli pliku nie ma, to też nic strasznego się nie stanie, więc można śmiało zabijać proces w pierwszej linii 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żna włączyć komputer, otworzyć konsolę i uruchomić komendę, przekazując jej kod z Google Authenticator. Konsolę potem można zamknąć.
Bez vpn-slice. Zamiast posłowia.
Zrozumienie, jak żyć bez vpn-slice, okazało się bardzo trudne. Musiałem dużo czytać i guglować. Na szczęście, kiedy tyle czasu spędziłem z problemem, podręczniki techniczne, a nawet man openconnect, czyta się jak pasjonujące powieści.
Ostatecznie ustaliłem, że vpn-slice, podobnie jak rodzimy skrypt, modyfikuje tablicę routingu w celu podziału sieci.
Tablica routingu
Jest to, w uproszczeniu, taka tabela, w której pierwsza kolumna zawiera, od czego powinien zaczynać się adres, przez który Linux chce przejść, a w drugiej, przez jaki adapter sieciowy ten adres powinien być osiągnięty. W rzeczywistości kolumn jest więcej, ale to nie zmienia istoty.
Aby zobaczyć tablicę routingu, należy wykonać 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 Każdy wiersz odpowiada za to, do którego adresu należy przejść, aby wysłać wiadomość. Najpierw pojawia się opis, od czego adres powinien się zaczynać. Aby zrozumieć, jak określić, że 192.168.0.0/16 oznacza, że adres musi zaczynać się od 192.168, należy poszukać w internecie, co to 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. To, że ruch dla wszystkich adresów zaczynających się od 192.168 przechodzi przez niego, określa wiersz
192.168.0.0/16 dev tun0 scope link Możesz również sprawdzić aktualny stan tablicy routingu za pomocą polecenia route -n (adresy IP sprytnie zanonimizowane) To polecenie zwraca wyniki w innej formie i jest ogólnie deprecated, ale jego wynik często pojawia się w podręcznikach w internecie i trzeba umieć go czytać.
Z czego powinien zaczynać się adres IP dla trasy można zrozumieć z kombinacji kolumn Destination i Genmask. Te części adresu IP, którym w Genmask odpowiadają cyfry 255, są brane pod uwagę, a te, gdzie są 0 — nie. 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, to zapytanie do niego pójdzie po tej trasie. A jeśli Destination to 192.168.0.0, ale Genmask to 255.255.0.0, to po tej trasie będą szły zapytania do adresów, które zaczynają się od 192.168.
Aby zrozumieć, co tak naprawdę robi vpn-slice, postanowiłem spojrzeć na stany tablic przed i po
Przed włączeniem VPN było tak
route -n
Tablica routingu IP w jądrze
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 wyglądało to tak
route -n
Tabela routingu IP jądra
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 tun0A po wywołaniu openconnect w połączeniu z vpn-slice wygląda to tak
Tabela routingu IP jądra
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 tun0Widać, że jeśli nie używać vpn-slice, to openconnect wyraźnie pisze, że dla wszystkich adresów, z wyjątkiem podanych, należy przechodzić przez VPN.
Tu:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Od razu wskazany jest inny sposób, który należy wykorzystać, jeśli adres, przez który próbuje przejść Linux, nie odpowiada żadnej masce z tabeli.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Już napisano, że w takim przypadku należy przechodzić przez standardowy adapter Wi-Fi.
Uważam, że trasa dla VPN jest używana, ponieważ widnieje jako pierwsza w tabeli routingu.
Teoretycznie, jeśli usunąć tę domyślną trasę z tabeli routingu, to w połączeniu z dnsmasq openconnect powinien zapewniać normalne działanie.
Próbowałem
route del defaultI wszystko zaczęło działać.
Routowanie zapytań do serwera pocztowego bez vpn-slice
Ale mam jeszcze serwer pocztowy o adresie 555.555.555.555, do którego również muszę przechodzić przez VPN. Trasę do niego również należy dodać ręcznie.
ip route add 555.555.555.555 via dev tun0I teraz wszystko jest w porządku. Można obyć się bez vpn-slice, ale trzeba dobrze wiedzieć, co się robi. Myślę teraz, czy nie dodać do ostatniego wiersza oryginalnego skryptu openconnect usunięcia domyślnej trasy i dodania trasy dla pocztowca po połączeniu z VPN, po prostu, aby zmniejszyć ruchome części w moim rowerze.
Prawdopodobnie dla niektórych, aby zrozumieć, jak skonfigurować VPN, wystarczyłoby to posłowie. Jednak ja, próbując zrozumieć, co i jak mam robić, przeczytałem wystarczająco wiele takich poradników, które działają u autora, ale z jakiegoś powodu nie działają u mnie, i postanowiłem dodać tutaj wszystkie fragmenty, które znalazłem. Cieszyłbym się, gdybym znalazł coś takiego.
Źródło: habr.com
