Želite koristiti Linux na poslu, ali korporativni VPN ne radi? Onda vam ovaj članak može pomoći, iako nije sigurno. Želim unaprijed upozoriti da slabo razumijem pitanja vezana uz administraciju mreža, pa nije isključeno da sam sve učinio pogrešno. S druge strane, nije isključeno da ću uspjeti napisati vodič tako da bude razumljiv običnim ljudima, pa vam savjetujem da pokušate.
U članku ima puno suvišnih informacija, ali bez tog znanja ne bih mogao riješiti probleme koji su mi nepredviđeno izlazili pri postavljanju VPN-a. Mislim da će svatko tko pokuša primijeniti ovaj vodič naići na probleme koje ja nisam imao, i nadam se da će te suvišne informacije pomoći da te probleme samostalno riješe.
Većinu naredbi koje se koriste u vodiču treba izvršavati preko sudo, koji je za sažetost izostavljen. Imajte to na umu.
Većina IP adresa je bila jako obfuskovana, tako da ako vidite adresu poput 435.435.435.435 — tu bi trebala biti neka normalna IP adresa specifična za vaš slučaj.
Imam Ubuntu 18.04, ali mislim da se uz male izmjene vodič može primijeniti i na druge distribucije. Međutim, u ovom tekstu Linux == Ubuntu.
Cisco Connect
Oni koji koriste Windows ili MacOS mogu se povezati na naš korporativni VPN putem Cisco Connect, kojem je potrebno unijeti adresu gateway-a i pri svakom povezivanju unositi lozinku koja se sastoji od fiksnog dijela i koda generiranog Google Authenticatorom.
U slučaju Linuxa, nisam uspio instalirati Cisco Connect, ali sam našao preporuku da se koristi openconnect, koji je posebno napravljen da zamijeni Cisco Connect.
Openconnect
Teoretski postoji poseban grafički sučelje za openconnect u Ubuntuu, ali meni nije radilo. Možda je to i bolje.
U Ubuntuu se openconnect instalira iz paketnog menadžera.
apt install openconnectOdmah nakon instalacije možete pokušati povezati se s VPN-om.
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com je adresa izmišljenog VPN-a
poxvuibr — ime izmišljenog korisnika
openconnect će zatražiti da unesete lozinku, koja se, podsjećam, sastoji od fiksnog dijela i koda iz Google Authenticatora, a zatim će pokušati povezati se na vpn. Ako je uspjelo, čestitamo, možete slobodno preskočiti sredinu s puno boli i preći na točku o radu openconnecta u pozadini. Ako nije uspjelo, možete nastaviti. Iako, ako je uspjelo prilikom povezivanja, na primjer, s gostujućeg Wi-Fi-a na poslu, možda je prerano za slavlje, trebate pokušati ponoviti postupak iz kuće.
Certifikat
S visokim je postotkom vjerojatno da ništa neće pokrenuti, a ishod openconnecta će izgledati ovako:
POST https://vpn.evilcorp.com/
Povezano s 777.777.777.777:443
SSL pregovaranje s vpn.evilcorp.com
Verifikacija poslužiteljskog certifikata nije uspjela: potpisnik nije pronađen
Certifikat s VPN poslužitelja "vpn.evilcorp.com" nije prošao verifikaciju.
Razlog: potpisnik nije pronađen
Da biste u budućnosti povjerovali ovom poslužitelju, možda dodajte ovo u svoju naredbenu liniju:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Upišite 'yes' za prihvaćanje, 'no' za prekid; bilo što drugo za pregled: fgets (stdin): Operacija je sada u tijekuS jedne strane, to je neugodno jer se VPN povezivanje nije ostvarilo, ali s druge strane, kako ispraviti ovaj problem, u načelu je jasno.
Ovdje je poslužitelj poslao certifikat po kojem možemo odrediti da se povezujemo upravo s poslužiteljem naše korporacije, a ne s zloćudnim prevarantom, ali ovom sustavu taj certifikat nije poznat. Zbog toga ne može provjeriti je li poslužitelj stvaran ili ne. I stoga, za svaki slučaj, prekida rad.
Da bi se openconnect ipak povezao s poslužiteljem, potrebno je izričito reći koji certifikat treba doći od VPN poslužitelja pomoću ključa --servercert
A možemo saznati koji nam je certifikat poslao poslužitelj iz onoga što je openconnect otisnuo. Evo iz ovog dijela:
Da biste u budućnosti povjerovali ovom poslužitelju, možda dodajte ovo u svoju naredbenu liniju:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Upišite 'yes' za prihvaćanje, 'no' za prekid; bilo što drugo za pregled: fgets (stdin): Operacija je sada u tijekuOvom naredbom možete pokušati ponovno povezati
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comMožda je sada uspjelo, tada možete preći na kraj. No osobno mi je Ubuntu prikazao figu u ovom obliku
POST https://vpn.evilcorp.com/
Connected to 777.777.777.777:443
SSL pregovaranje s vpn.evilcorp.com
Verifikacija certifikata poslužitelja nije uspjela: potpisnik nije pronađen
Povezano na HTTPS na vpn.evilcorp.com
XML POST je omogućen
Unesite svoje korisničko ime i lozinku.
POST https://vpn.evilcorp.com/
Primljen CONNECT odgovor: HTTP/1.1 200 OK
CSTP povezano. DPD 300, Keepalive 30
Postavljanje DTLS-a nije uspjelo; koristi se SSL umjesto njega
Povezano kao 192.168.333.222, koristi se SSL
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
RTNETLINK odgovori: Datoteka već postoji
/etc/resolvconf/update.d/libc: Upozorenje: /etc/resolv.conf nije simbolička poveznica na /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 će se riješiti, ali neće biti moguće pristupiti. Adrese poput jira.evilcorp.com uopće se ne riješavaju.
Što se ovdje dogodilo, nije mi jasno. Ali eksperiment pokazuje da ako dodate u /etc/resolv.conf redak
nameserver 192.168.430.534onda će adrese unutar VPN-a početi magično rješavati i moći ćete im pristupiti, što znači da ono što traži kako rješavati adrese koristi upravo /etc/resolv.conf, a ne nekamo drugdje.
To da postoji povezivanje na VPN i da radi može se provjeriti i bez izmjena u /etc/resolv.conf, dovoljno je u preglednik unijeti ne simbolično ime resursa iz VPN-a, već njegov IP adresu.
Na kraju dolazimo do dva problema
- prilikom povezivanja na VPN ne preuzima se njezin DNS
- sav promet ide preko VPN-a, koji ne dopušta pristup internetu
Što učiniti, sada ću objasniti, ali prvo malo automatizacije.
Automatski unos fiksnog dijela lozinke
Do ovog trenutka vjerojatno ste već unijeli lozinku najmanje pet puta i ova procedura vas već dobro umorila. Prvo, zato što je lozinka duga, drugo, zato što se prilikom unosa treba uklopiti u fiksni vremenski interval.
Završno rješenje problema nije ušlo u članak, ali se može napraviti da fiksni dio lozinke ne treba unositi više puta.
Recimo, fiksni dio lozinke je fixedPassword, a dio iz Google Authenticator 567 987. Cijelu lozinku openconnect možete prenijeti putem standardnog unosa koristeći argument —passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinSada se možete stalno vraćati na posljednju unesenu naredbu i mijenjati samo dio iz Google Authenticatora.
Korporativni VPN ne dopušta pristup internetu.
Uistinu nije nimalo praktično kada se za pristup habru mora koristiti poseban računar. Nedostatak mogućnosti kopiranja i lijepljenja s stackoverfow može potpuno paralizirati rad, stoga nešto treba učiniti.
Trebalo bi nekako organizirati da kada trebate pristupiti resursu iz unutarnje mreže, Linux koristi VPN, a kad trebate pristupiti Habr-u — ide na internet.
Openconnect nakon pokretanja i uspostavljanja veze s VPN-om izvršava poseban skript koji se nalazi u /usr/share/vpnc-scripts/vpnc-script. U skriptu se prenose neke varijable, a on obavlja konfiguraciju VPN-a. Nažalost, nisam uspio shvatiti kako odvojiti tokove prometa između korporativnog VPN-a i ostatka interneta koristeći izvorni skript.
Izgleda da je posebno za takve kao što sam ja razvijen alat vpn-slice, koji omogućuje usmjeravanje prometa putem dva kanala bez suvišnih komplikacija. Pa, točnije, morat ćete malo uvježbavati, ali nije potrebno biti šaman.
Razdvajanje prometa pomoću vpn-slice
Prvo, vpn-slice će se morati instalirati, s time ćete se morati sami nositi. Ako u komentarima budu pitanja, napisat ću o tome poseban post. No, to je običan program na Python-u, tako da ne bi trebalo biti problema. Instalirao sam ga putem virtualenv.
A zatim, treba primijeniti alat, koristeći ključ —script i navesti openconnect, da umjesto standardnog skripta koristite 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 U —script se prosljeđuje niz s naredbom koju treba pozvati umjesto skripta. .\/bin\/vpn-slice — put do izvršne datoteke vpn-slice 192.168.430.0\/24 — maska adresa kojima treba pristupiti putem VPN-a. Ovdje se misli da ako adresa počinje s 192.168.430 — resurs s tom adresom treba tražiti unutar VPN-a.
Sada bi situacija trebala biti gotovo normalna. Gotovo. Sada je moguće pristupiti Habr-u i unutar korporativnog resursa po IP-u, ali nije moguće pristupiti unutar korporativnog resursa po simboličkom imenu. Ako se navedu odgovarajuće podudarnosti simboličkog imena i adrese u hosts — sve bi trebalo proraditi. I raditi, sve dok se IP ne promijeni. Linux sada može pristupiti internetu ili unutar korporativne mreže ovisno o IP-u. No, za određivanje adrese i dalje se koristi ne korporativni DNS.
Problem se također može manifestirati na sljedeći način — na poslu sve radi normalno, dok kod kuće možete pristupiti unutar-korporativnim resursima samo putem IP adrese. To je zato što, kada ste povezani na korporativni Wi-Fi, koristi se korporativni DNS, gdje se simbolične adrese iz VPN-a razrješavaju, iako se na takvu adresu i dalje ne može pristupiti bez korištenja VPN-a.
Automatska modifikacija datoteke hosts
Ako vpn-slice ljubazno zatraži, može nakon podizanja VPN-a otići u njezin DNS, pronaći IP adrese potrebnih resursa prema njihovim simboličkim imenima i upisati ih u hosts. Nakon isključivanja VPN-a, te adrese će biti uklonjene iz hosts. Za to je potrebno proslijediti simbolička imena u vpn-slice kao argumente. Ovako.
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 Sada bi sve trebalo raditi i u uredu i na plaži.
Tražiti adrese svih poddomena u DNS-u koji je dala VPN.
Ako unutar mreže ima malo adresa, pristup s automatskom modifikacijom datoteke hosts je sasvim funkcionalan. No, ako ima mnogo resursa u mreži, stalno ćete morati dodavati retke u skript poput zoidberg.test.evilcorp.com. Zoidberg je ime jednog od testnih okruženja.
Ali sada, kada malo bolje razumijemo što se događa, tu potrebu možemo eliminirati.
Ako nakon podizanja VPN-a pogledate u \/etc\/hosts, možete vidjeti ovakav redak.
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
I u resolv.conf je dodan novi redak. Ukratko, vpn-slice je nekako odredila gdje se nalazi DNS poslužitelj za VPN.
Sada treba postaviti tako da, da bi saznao IP adresu domenskog imena koje završava na evilcorp.com, Linux ide u korporativni DNS, a ako treba nešto drugo, onda u zadani.
Dugo sam tražio i otkrio da takva funkcionalnost postoji u Ubuntuu iz kutije. Riječ je o mogućnosti korištenja lokalnog DNS poslužitelja dnsmasq za razrješavanje imena.
To znači da se može postaviti tako da Linux uvijek ide po IP adresama u lokalni DNS poslužitelj, koji će potom, ovisno o imenu domene, tražiti IP na odgovarajućem vanjskom DNS poslužitelju.
Za upravljanje svim aspektima mreža i mrežnih veza u Ubuntuu koristi se NetworkManager, a grafičko sučelje za odabir, na primjer, Wi-Fi veze — jednostavno je sučelje za njega.
Morat ćemo malo zaviriti u njegovim konfiguracijama.
- Izradite datoteku u /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Obratite pažnju na točku ispred evilcorp. Ona signalizira dnsmasq-u da treba tražiti sve poddomene evilcorp.com u korporativnom DNS-u.
- Reći NetworkManageru da za razrješavanje imena treba koristiti dnsmasq.
Konfiguracija network-manager-a se nalazi u /etc/NetworkManager/NetworkManager.conf. Treba to dodati:
[main]
dns=dnsmasq
- Ponovo pokrenite NetworkManager.
service network-manager restartSada, nakon povezivanja s VPN-om putem kombinacije openconnect i vpn-slice, IP će se pravilno određivati, čak i ako ne dodate simboličke adrese kao argumente na vpnslice.
Kako pristupiti različitim servisima putem VPN-a
Nakon što sam uspio povezati se na VPN, bio sam jako sretan dva dana, a potom se ispostavilo da kada se povezujem na VPN izvan uredske mreže, e-mail ne radi. Poznati simptom, zar ne?
Naša e-pošta se nalazi na mail.publicevilcorp.com, što znači da ne pada pod pravilo u dnsmasq i adresa poštanskog poslužitelja se traži putem javnog DNS-a.
U uredu se i dalje koristi DNS u kojem se ova adresa nalazi. Tako sam mislio. U praksi, nakon dodavanja u dnsmasq linije
address=/mail.publicevilcorp.com/192.168.430.534
situacija se nije promijenila. IP je ostao isti. Morao sam ići na posao.
I tek kasnije, kada sam dublje zaronio u situaciju i malo razjasnio problem, jedan pametan čovjek me savjetovao kako da ga riješim. Trebalo je pristupiti poštanskom poslužitelju ne samo tako, već preko VPN-a.
Koristim vpn-slice da prolazim kroz VPN do adresa koje počinju s 192.168.430. A poštanski poslužitelj ne samo da simbolička adresa nije poddomen evilcorp, već mu i IP adresa ne počinje s 192.168.430. Iz opće mreže, naravno, nikoga ne pušta unutra.
Kako bi Linux mogao pristupiti VPN-u i poštanskom poslužitelju, potrebno je dodati i njega u vpn-slice. Recimo da je adresa poštanskog poslužitelja - 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 Skripta za pokretanje VPN-a s jednim argumentom
Sve to, naravno, nije baš zgodno. Da, možete sačuvati tekst u datoteku i kopirati ga u konzolu umjesto da ga kucate ručno, ali iskustvo nije baš povoljno. Da biste olakšali proces, možete obaviti naredbu u skriptu koji će biti u PATH-u. Tako da će vam samo trebati unijeti kod iz Google Authenticatora.
#!/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 Ako stavite skript u connect~evilcorp~, možete jednostavno pisati u konzoli.
connect_evil_corp 567987Ali sada ćete i dalje morati držati konzolu otvorenom u kojoj je pokrenut openconnect.
Pokretanje openconnecta u pozadini
Na sreću, autori openconnecta su se pobrinuli za nas i dodali poseban ključ —background koji omogućava da program radi u pozadini nakon pokretanja. Ako ga pokrenete ovako, konzolu možete zatvoriti nakon pokretanja.
#!/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 Sada samo nije jasno kamo idu logovi. Logovi nam zapravo nisu toliko potrebni, ali tko zna. Openconnect može preusmjeriti logove u syslog, gdje će biti sačuvani. To treba dodati u naredbu s ključem —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 tako, izgleda da openconnect negdje radi u pozadini i nikome ne smeta, ali kako ga zaustaviti nije jasno. Može se, naravno, filtrirati izlaz ps-a s grep-om i tražiti proces čije ime sadrži openconnect, ali to je pomalo zamorno. Hvala autorima koji su mislili i o tome. Openconnect ima ključ —pid-file, pomoću kojeg možete naložiti openconnectu da zapiše identifikator svog procesa u datoteku.
#!/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-pidSada uvijek možete ubiti proces s naredbom.
kill $(cat ~/vpn-pid)Ako procesa nema, kill će se ljutiti, ali neće baciti grešku. Ako datoteka ne postoji, također se neće dogoditi ništa strašno, pa možete slobodno ubiti proces u prvom retku skripte.
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-pidSada možete uključiti računalo, otvoriti konzolu i pokrenuti naredbu, proslijedivši joj kod iz Google Authenticatora. Konzolu kasnije možete ubiti.
Bez vpn-slice. Umjesto poslijednje riječi.
Shvatiti kako živjeti bez vpn-slice bilo je vrlo teško. Morao sam puno čitati i pretraživati. Na sreću, kad ste proveli toliko vremena s problemom, tehnički priručnici pa čak i man openconnect čitaju se kao uzbudljive romane.
Na kraju sam saznao da vpn-slice, kao i domaći skript za razdvajanje mreža, modificira tabelu rutiranja.
Tabela rutiranja
To je, pojednostavljeno, tabela u kojoj se u prvoj koloni nalaze adrese s kojih Linux treba početi, a u drugoj kojoj mrežnoj adapter treba proći. U stvarnosti ima više kolona, ali to ne mijenja bit.
Da biste pogledali tabelu rutiranja, trebate izvršiti komandu 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 Ovde svaka linija odgovara za to kuda treba proći da bi se poslao paket na neku adresu. Prvo je opis sa koje adrese treba početi. Da biste razumeli šta znači 192.168.0.0/16, treba pretražiti šta je maska IP adrese. Nakon dev nalazi se ime adaptera na koji treba poslati poruku.
Za VPN, Linux je napravio virtuelni adapter — tun0. Linija
192.168.0.0/16 dev tun0 scope link Takođe, trenutnu stanje tabele rutiranja možete provjeriti pomoću komande rute -n (IP adrese su talentovano anonimne) Ova komanda daje rezultate u drugom formatu i uopšte je deprecated, ali se često može naći u priručnicima na internetu i treba znati kako ga čitati.
Od čega treba početi IP adresu za rutu može se shvatiti iz kombinacije kolona Destination i Genmask. Delovi IP adrese kojima u Genmask odgovaraju brojevi 255, se uzimaju u obzir, a oni gde su 0 — ne. Dakle, kombinacija Destination 192.168.0.0 i Genmask 255.255.255.0 znači da, ako adresa počinje sa 192.168.0, zahtev prema njoj ide ovom rutom. A ako je Destination 192.168.0.0, ali Genmask 255.255.0.0, onda će odatle ići zahtevi prema adresama koje počinju sa 192.168.
Da bih shvatio šta zapravo radi vpn-slice, odlučio sam da pogledam stanje tabela pre i posle
Pre aktiviranja VPN-a bilo je ovako
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 wlp3s0Nakon poziva openconnect bez vpn-slice situacija je ovakva
ruta -n
Kernel IP routing table
Odredište Gateway Genmask Oznake Metrika Ref Upotreba Sučelje
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 nakon poziva openconnect u kombinaciji s vpn-slice ovako
Kernel IP routing table
Odredište Gateway Genmask Oznake Metrika Ref Upotreba Sučelje
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 tun0Vidljivo je da ako se ne koristi vpn-slice, openconnect jasno piše da do svih adresa, osim onih posebno navedenih, treba ići preko vpna.
Evo ovdje:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Tu je odmah navedena još jedna ruta koju treba koristiti ako adresa, preko koje pokušava proći Linux, ne odgovara nijednoj maski iz tablice.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Ovdje već piše da u tom slučaju treba ići preko standardnog Wi-Fi adaptera.
Pretpostavljam da se ruta za VPN koristi jer je prva u tablici usmjeravanja.
I teorijski, ako se ukloni ova zadana ruta iz tablice usmjeravanja, openconnect bi trebao osigurati normalan rad u kombinaciji s dnsmasq.
Pokušao sam
ruta del defaultI sve je proradilo.
Usmjeravanje zahtjeva na mail poslužitelj bez vpn-slice
Ali imam još i mail poslužitelj s adresom 555.555.555.555, na koji također treba ići preko vpna. Rutu do njega također treba dodati ručno.
ip route add 555.555.555.555 via dev tun0I sada je sve u redu. Tako da se može proći bez vpn-slice, ali već treba dobro znati što radite. Sada razmišljam o dodavanju brisanja zadane rute i dodavanju rute za mail poslužitelj nakon povezivanja s vpn-om u zadnjem retku izvornog openconnect skripta, samo da bi količina pokretnih dijelova na mom biciklu bila manja.
Možda bi nekom bilo dovoljno da pročita ovu epilog kako bi shvatio kako postaviti VPN. Međutim, dok sam pokušavao shvatiti što i kako trebam učiniti, pročitao sam dovoljno mnoštvo takvih vodiča koji rade kod autora, ali iz nekog razloga ne rade kod mene, pa sam odlučio dodati ovdje sve dijelove koje sam pronašao. Jako bih se obradovao nečemu takvom.
Izvor: habr.com
