Želite li koristiti Linux na poslu, ali vam vaš korporativni VPN to ne dopušta? Onda bi ovaj članak mogao pomoći, iako to nije sigurno. Unaprijed vas upozoravam da se slabo razumijem u problematiku mrežne administracije pa je moguće da sam sve krivo napravio. S druge strane, moguće je da mogu napisati vodič na takav način da će biti razumljiv običnim ljudima, pa vam savjetujem da ga isprobate.
Članak sadrži puno nepotrebnih informacija, ali bez ovog znanja ne bih mogao riješiti probleme koji su mi se neočekivano pojavili s postavljanjem VPN-a. Mislim da će svatko tko pokuša koristiti ovaj vodič imati problema koje ja nisam imao i nadam se da će ove dodatne informacije pomoći u rješavanju tih problema.
Većinu naredbi korištenih u ovom vodiču potrebno je pokrenuti putem sudoa, koji je uklonjen radi sažetosti. Imati na umu.
Većina IP adresa ozbiljno je zamagljena, pa ako vidite adresu poput 435.435.435.435, tamo mora postojati neka normalna IP adresa, specifična za vaš slučaj.
Imam Ubuntu 18.04, ali mislim da se uz manje izmjene vodič može primijeniti na druge distribucije. Međutim, u ovom tekstu Linux == Ubuntu.
Cisco Connect
Oni koji koriste Windows ili MacOS mogu se spojiti na naš korporativni VPN putem Cisco Connecta, koji treba navesti adresu pristupnika i, svaki put kada se povežete, unijeti lozinku koja se sastoji od fiksnog dijela i koda koji generira Google Authenticator.
U slučaju Linuxa, nisam mogao pokrenuti Cisco Connect, ali sam uspio pronaći na Googleu preporuku za korištenje openconnecta, napravljenu posebno da zamijeni Cisco Connect.
Openconnect
U teoriji, Ubuntu ima posebno grafičko sučelje za openconnect, ali meni nije uspjelo. Možda je tako i bolje.
Na Ubuntuu se openconnect instalira iz upravitelja paketa.
apt install openconnectOdmah nakon instalacije možete se pokušati spojiti na VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com je adresa fiktivnog VPN-a
poxvuibr - izmišljeno korisničko ime
openconnect će vas pitati za lozinku koja se, podsjetit ću, sastoji od fiksnog dijela i koda iz Google Authenticatora, a zatim će se pokušati spojiti na vpn. Ako radi, čestitamo, možete sigurno preskočiti sredinu, koja je jako mučna, i prijeći na točku o openconnectu koji radi u pozadini. Ako ne uspije, možete nastaviti. Iako ako je uspjelo pri povezivanju, na primjer, s Wi-Fi mreže za goste na poslu, možda je prerano radovati se; pokušajte ponoviti postupak od kuće.
potvrda
Postoji velika vjerojatnost da se ništa neće pokrenuti, a openconnect izlaz će izgledati otprilike ovako:
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 progressS jedne strane, to je neugodno, jer nije bilo veze s VPN-om, ali s druge strane, kako riješiti ovaj problem je u načelu jasno.
Ovdje nam je server poslao certifikat, po kojem možemo utvrditi da se spaja na server naše matične korporacije, a ne na zlog prevaranta, a taj certifikat je nepoznat sustavu. Stoga ne može provjeriti je li poslužitelj pravi ili ne. I tako, za svaki slučaj, prestane raditi.
Kako bi se openconnect povezao s poslužiteljem, morate mu eksplicitno reći koji certifikat treba doći s VPN poslužitelja pomoću ključa —servercert
A koji nam je certifikat poslužitelj poslao možete saznati izravno iz onoga što je openconnect ispisao. Evo iz ovog djela:
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 progressPomoću ove naredbe možete se pokušati ponovno spojiti
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comMožda sada radi, onda možete prijeći do kraja. Ali osobno, Ubuntu mi je pokazao figu u ovom obliku
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 će riješiti, ali nećete moći otići tamo. Adrese poput jira.evilcorp.com uopće se ne rješavaju.
Nije mi jasno što se ovdje dogodilo. Ali eksperiment pokazuje da ako dodate redak u /etc/resolv.conf
nameserver 192.168.430.534tada će se adrese unutar VPN-a početi čarobno rješavati i možete proći kroz njih, to jest, ono što DNS traži za rješavanje adresa izgleda konkretno u /etc/resolv.conf, a ne negdje drugdje.
Možete provjeriti postoji li veza s VPN-om i radi li bez ikakvih promjena u /etc/resolv.conf; da biste to učinili, samo unesite u preglednik ne simbolički naziv resursa iz VPN-a, već njegovu IP adresu
Kao rezultat toga, postoje dva problema
- Kada se spaja na VPN, njegov dns se ne preuzima
- sav promet ide preko VPN-a koji ne dopušta pristup Internetu
Reći ću vam što da radite sada, ali prvo malo automatizacije.
Automatski unos fiksnog dijela lozinke
Do sada ste najvjerojatnije već unijeli lozinku barem pet puta i ovaj vas je postupak već umorio. Prvo, jer je lozinka dugačka, a drugo, jer prilikom unosa morate stati u fiksni vremenski period
Konačno rješenje problema nije uključeno u članak, ali možete se pobrinuti da se fiksni dio lozinke ne mora unositi mnogo puta.
Recimo da je fiksni dio lozinke fixedPassword, a dio iz Google Authenticatora je 567 987. Cijela lozinka može se proslijediti openconnect-u putem standardnog unosa pomoću argumenta --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinSada se stalno možete vraćati na zadnju unesenu naredbu i tamo mijenjati samo dio Google Authenticatora.
Korporativni VPN ne dopušta vam surfanje internetom.
Općenito, nije baš nezgodno kada morate koristiti zasebno računalo za odlazak na Habr. Nemogućnost kopiranja i lijepljenja iz stackoverfowa općenito može paralizirati rad, pa se mora nešto učiniti.
Moramo to nekako organizirati da kada treba pristupiti resursu s interne mreže, Linux ide na VPN, a kada treba ići na Habr, ide na Internet.
openconnect nakon pokretanja i uspostavljanja veze s vpn-om izvršava posebnu skriptu koja se nalazi u /usr/share/vpnc-scripts/vpnc-script. Neke se varijable prosljeđuju skripti kao ulaz, a ona konfigurira VPN. Nažalost, nisam mogao shvatiti kako podijeliti tokove prometa između korporativnog VPN-a i ostatka interneta pomoću izvorne skripte.
Očigledno, uslužni program vpn-slice razvijen je posebno za ljude poput mene, što vam omogućuje slanje prometa kroz dva kanala bez plesanja s tamburinom. Pa, to jest, morat ćete plesati, ali ne morate biti šaman.
Razdvajanje prometa pomoću vpn-slice
Prvo, morat ćete instalirati vpn-slice, ovo ćete morati sami shvatiti. Ako u komentarima bude pitanja, o tome ću napisati poseban post. Ali ovo je običan Python program, tako da ne bi trebalo biti nikakvih poteškoća. Instalirao sam koristeći virtualenv.
Zatim se uslužni program mora primijeniti, korištenjem prekidača -script, naznačujući za openconnect da umjesto standardne skripte trebate koristiti 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 se prosljeđuje niz s naredbom koju je potrebno pozvati umjesto skripte. ./bin/vpn-slice - put do vpn-slice izvršne datoteke 192.168.430.0/24 - maska adresa na koje se ide u vpn. Ovdje mislimo da ako adresa počinje s 192.168.430, tada resurs s ovom adresom treba pretražiti unutar VPN-a
Situacija bi sada trebala biti gotovo normalna. Skoro. Sada možete otići na Habr i možete otići na unutarkorporacijski resurs putem ip-a, ali ne možete otići na unutarkorporacijski resurs simboličnim imenom. Ako navedete podudaranje između simboličkog imena i adrese u hostovima, sve bi trebalo raditi. I raditi dok se ne promijeni ip. Linux sada može pristupiti internetu ili intranetu, ovisno o IP-u. Ali ne-korporacijski DNS još uvijek se koristi za određivanje adrese.
Problem se također može manifestirati u ovom obliku - na poslu je sve u redu, ali kod kuće možete pristupiti samo internim korporativnim resursima putem IP-a. To je zato što kada ste spojeni na korporativni Wi-Fi, koristi se i korporativni DNS, au njemu se rješavaju simbolične adrese iz VPN-a, unatoč činjenici da je i dalje nemoguće otići na takvu adresu bez korištenja VPN-a.
Automatsko mijenjanje datoteke domaćina
Ako se vpn-slice pristojno zamoli, tada nakon podizanja VPN-a može otići na svoj DNS, tamo pronaći IP adrese potrebnih resursa po njihovim simboličnim imenima i unijeti ih u hostove. Nakon isključivanja VPN-a, te će adrese biti uklonjene s hostova. Da biste to učinili, trebate proslijediti simbolična imena vpn-slice kao argumente. Kao ovo.
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 funkcionirati i u uredu i na plaži.
Potražite adrese svih poddomena u DNS-u koje daje VPN
Ako postoji nekoliko adresa unutar mreže, tada pristup automatske izmjene datoteke hostova funkcionira prilično dobro. Ali ako postoji mnogo resursa na mreži, tada ćete stalno morati dodavati retke poput zoidberg.test.evilcorp.com zoidberg je naziv jedne od ispitnih klupa.
Ali sada kada malo razumijemo zašto se ova potreba može eliminirati.
Ako, nakon podizanja VPN-a, pogledate u /etc/hosts, možete vidjeti ovaj redak
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOMATSKI STVORENO
I novi redak je dodan u resolv.conf. Ukratko, vpn-slice je nekako odredio gdje se nalazi dns poslužitelj za vpn.
Sada se moramo uvjeriti da Linux ide na korporativni DNS, a ako treba još nešto, onda na zadani, kako bi saznao IP adresu naziva domene koja završava na evilcorp.com.
Dugo sam guglao i otkrio da je takva funkcija dostupna u Ubuntuu odmah po izlasku. To znači mogućnost korištenja lokalnog DNS poslužitelja dnsmasq za rješavanje imena.
To jest, možete osigurati da Linux uvijek ide na lokalni DNS poslužitelj za IP adrese, koji će zauzvrat, ovisno o nazivu domene, tražiti IP na odgovarajućem vanjskom DNS poslužitelju.
Za upravljanje svime vezanim uz mreže i mrežne veze, Ubuntu koristi NetworkManager, a grafičko sučelje za odabir npr. Wi-Fi veza samo mu je front end.
Morat ćemo se popeti u njegovoj konfiguraciji.
- Napravite datoteku u /etc/NetworkManager/dnsmasq.d/evilcorp
adresa=/.evilcorp.com/192.168.430.534
Obratite pozornost na točku ispred evilcorp. Signalizira dnsmasq da sve poddomene evilcorp.com treba pretražiti u korporativnom DNS-u.
- Recite NetworkManageru da koristi dnsmasq za razlučivanje naziva
Konfiguracija mrežnog upravitelja nalazi se u /etc/NetworkManager/NetworkManager.conf Tu trebate dodati:
[glavni] dns=dnsmasq
- Ponovno pokrenite NetworkManager
service network-manager restartSada, nakon spajanja na VPN koristeći openconnect i vpn-slice, ip će se normalno odrediti, čak i ako ne dodate simboličke adrese argumentima za vpnslice.
Kako pristupiti pojedinačnim uslugama putem VPN-a
Nakon što sam se uspio spojiti na VPN, bio sam jako sretan dva dana, a onda se pokazalo da ako se spojim na VPN izvan uredske mreže, pošta ne radi. Simptom je poznat, zar ne?
Naša pošta se nalazi na mail.publicevilcorp.com, što znači da ne potpada pod pravilo u dnsmasq i da se adresa poslužitelja pošte pretražuje putem javnog DNS-a.
Pa, ured još uvijek koristi DNS, koji sadrži ovu adresu. To sam i mislio. Zapravo, nakon dodavanja retka u dnsmasq
adresa=/mail.publicevilcorp.com/192.168.430.534
situacija se nije nimalo promijenila. ip je ostao isti. Morao sam na posao.
I tek kasnije, kada sam dublje ušao u situaciju i malo shvatio problem, jedna pametna osoba mi je rekla kako to riješiti. Bilo je potrebno spojiti se na poslužitelj pošte ne samo tako, već putem VPN-a
Koristim vpn-slice za prolazak kroz VPN do adresa koje počinju s 192.168.430. Poslužitelj e-pošte ne samo da ima simboličnu adresu koja nije poddomena evilcorpa, nego također nema IP adresu koja počinje s 192.168.430. I naravno ne dopušta nikome iz opće mreže da dođe k njemu.
Da bi Linux mogao ići kroz VPN i do poslužitelja e-pošte, morate ga dodati i na vpn-slice. Recimo da je adresa pošiljatelja 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 podizanje VPN-a s jednim argumentom
Sve ovo, naravno, nije baš zgodno. Da, možete spremiti tekst u datoteku i kopirati ga u konzolu umjesto da ga upisujete rukom, ali i dalje nije baš ugodno. Da biste olakšali proces, možete zamotati naredbu u skriptu koja će se nalaziti u PATH. A tada ćete samo morati unijeti kod primljen od 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 skriptu u connect~evilcorp~, možete jednostavno pisati u konzoli
connect_evil_corp 567987Ali sada još uvijek iz nekog razloga morate držati otvorenu konzolu u kojoj se openconnect izvodi
Pokretanje openconnecta u pozadini
Srećom, autori openconnect-a su se pobrinuli za nas i dodali poseban ključ programu -background, koji čini da program nakon pokretanja radi u pozadini. Ako je ovako pokrenete, možete zatvoriti konzolu 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 jednostavno nije jasno kamo idu trupci. Općenito, zapravo nam ne trebaju trupci, ali nikad se ne zna. openconnect ih može preusmjeriti na syslog, gdje će biti sigurni i sigurni. naredbi trebate dodati prekidač –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, ispada da openconnect radi negdje u pozadini i nikome ne smeta, ali nije jasno kako to zaustaviti. To jest, možete, naravno, filtrirati ps izlaz koristeći grep i tražiti proces čije ime sadrži openconnect, ali to je nekako zamorno. Hvala autorima koji su i o tome razmišljali. Openconnect ima ključ -pid-datoteku, s kojom možete uputiti openconnect da zapiše svoj identifikator 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 prekinuti proces s naredbom
kill $(cat ~/vpn-pid)Ako nema procesa, kill će proklinjati, ali neće izbaciti pogrešku. Ako datoteka nije tamo, tada se neće dogoditi ništa loše, tako da možete sigurno 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 svoje računalo, otvoriti konzolu i pokrenuti naredbu, prosljeđujući joj kod iz Google Autentifikatora. Konzola se tada može pričvrstiti.
Bez VPN-slice. Umjesto pogovora
Ispostavilo se da je vrlo teško razumjeti kako živjeti bez VPN-slice. Morao sam puno čitati i guglati. Srećom, nakon toliko vremena provedenog s problemom, tehnički priručnici, pa čak i man openconnect čitaju se poput uzbudljivih romana.
Kao rezultat toga, otkrio sam da vpn-slice, poput izvorne skripte, mijenja tablicu usmjeravanja za odvajanje mreža.
Tablica usmjeravanja
Pojednostavljeno rečeno, ovo je tablica u prvom stupcu koja sadrži ono s čim treba započeti adresa kroz koju Linux želi proći, au drugom stupcu koji mrežni adapter treba proći na ovoj adresi. Zapravo, govornika ima više, ali to ne mijenja bit.
Kako biste vidjeli tablicu usmjeravanja, morate pokrenuti naredbu 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 Ovdje je svaka linija odgovorna za to gdje trebate ići da biste poslali poruku na neku adresu. Prvi je opis gdje adresa treba započeti. Da biste razumjeli kako odrediti da 192.168.0.0/16 znači da adresa treba započeti s 192.168, morate proguglati što je maska IP adrese. Nakon dev nalazi se naziv adaptera na koji treba poslati poruku.
Za VPN, Linux je napravio virtualni adapter - tun0. Linija osigurava da kroz nju ide promet za sve adrese koje počinju s 192.168
192.168.0.0/16 dev tun0 scope link Također možete pogledati trenutno stanje tablice usmjeravanja pomoću naredbe ruta -n (IP adrese su vješto anonimizirane) Ova naredba daje rezultate u drugačijem obliku i općenito je zastarjela, ali se njen izlaz često nalazi u priručnicima na Internetu i morate ju znati pročitati.
Gdje IP adresa za rutu treba započeti može se razumjeti iz kombinacije stupaca Destination i Genmask. Oni dijelovi IP adrese koji odgovaraju brojevima 255 u Genmasku su uzeti u obzir, ali oni gdje je 0 nisu. Odnosno, kombinacija Destination 192.168.0.0 i Genmask 255.255.255.0 znači da ako adresa počinje s 192.168.0, tada će zahtjev prema njoj ići ovom rutom. A ako je Destination 192.168.0.0, ali Genmask 255.255.0.0, tada će zahtjevi za adrese koje počinju s 192.168 ići ovom rutom
Kako bih shvatio što zapravo radi vpn-slice, odlučio sam pogledati stanja tablica prije i poslije
Prije paljenja 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-slicea postalo je ovako
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 nakon poziva openconnect u kombinaciji s ovakvim vpn-sliceom
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 tun0Vidi se da ako ne koristite vpn-slice, tada openconnect izričito piše da se svim adresama, osim onih koje su posebno naznačene, mora pristupiti putem vpn-a.
Upravo ovdje:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Tu je pored nje odmah naznačen drugi put koji se mora koristiti ako adresa kroz koju Linux pokušava proći ne odgovara niti jednoj maski iz tablice.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Ovdje je već napisano da u ovom slučaju trebate koristiti standardni Wi-Fi adapter.
Vjerujem da se koristi VPN staza jer je prva u tablici usmjeravanja.
I teoretski, ako uklonite ovaj zadani put iz tablice usmjeravanja, tada bi u kombinaciji s dnsmasq openconnect trebao osigurati normalan rad.
pokušao sam
route del defaultI sve je radilo.
Usmjeravanje zahtjeva na poslužitelj pošte bez vpn-slice
Ali imam i mail server s adresom 555.555.555.555, kojem također treba pristupiti putem VPN-a. Rutu do njega također treba dodati ručno.
ip route add 555.555.555.555 via dev tun0I sad je sve u redu. Dakle, možete i bez vpn-slicea, ali morate dobro znati što radite. Sada razmišljam o tome da u posljednji red izvorne openconnect skripte dodam uklanjanje zadane rute i dodam rutu za mailer nakon spajanja na vpn, samo tako da ima manje pokretnih dijelova u mom biciklu.
Vjerojatno bi ovaj pogovor bio dovoljan da netko shvati kako postaviti VPN. Ali dok sam pokušavao shvatiti što i kako učiniti, pročitao sam dosta takvih vodiča koji odgovaraju autoru, ali iz nekog razloga meni ne, i odlučio sam ovdje dodati sve dijelove koje sam našao. Tako nešto bi me jako veselilo.
Izvor: www.habr.com