Ali želite uporabljati Linux v službi, vendar vam VPN v podjetju ne dovoljuje? Ta članek vam lahko pomaga, čeprav to ni gotovo. Vnaprej vas želim opozoriti, da se slabo razumem na vprašanja omrežne administracije, zato je možno, da sem naredil vse narobe. Po drugi strani pa je možno, da lahko napišem vodnik tako, da bo razumljiv običajnim ljudem, zato svetujem, da ga preizkusite.
Članek vsebuje veliko nepotrebnih informacij, vendar brez tega znanja ne bi mogel rešiti težav, ki so se mi nepričakovano pojavile pri nastavitvi VPN-ja. Mislim, da bo vsak, ki bo poskušal uporabiti ta vodnik, imel težave, ki jih jaz nisem imel, in upam, da bodo te dodatne informacije pomagale rešiti te težave same.
Večino ukazov, uporabljenih v tem priročniku, je treba zagnati prek programa sudo, ki je bil zaradi kratkosti odstranjen. Imejte v mislih.
Večina naslovov IP je bila močno zakritih, tako da, če vidite naslov, kot je 435.435.435.435, tam mora biti nek običajen IP, specifičen za vaš primer.
Imam Ubuntu 18.04, vendar mislim, da je vodnik z manjšimi spremembami mogoče uporabiti za druge distribucije. Vendar pa je v tem besedilu Linux == Ubuntu.
Cisco Connect
Tisti, ki uporabljate Windows ali MacOS, se lahko povežete z našim korporativnim VPN prek Cisco Connect, ki mora določiti naslov prehoda in ob vsaki povezavi vnesti geslo, sestavljeno iz fiksnega dela in kode, ki jo ustvari Google Authenticator.
V primeru Linuxa nisem mogel zagnati Cisco Connecta, vendar mi je uspelo poguglati priporočilo za uporabo openconnect, narejeno posebej za zamenjavo Cisco Connecta.
Odpri povezavo
Teoretično ima Ubuntu poseben grafični vmesnik za openconnect, vendar mi ni deloval. Mogoče je tako na bolje.
V Ubuntuju se openconnect namesti iz upravitelja paketov.
apt install openconnectTakoj po namestitvi se lahko poskusite povezati z VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com je naslov izmišljenega VPN-ja
poxvuibr - izmišljeno uporabniško ime
openconnect vas bo prosil za vnos gesla, ki je, naj vas spomnim, sestavljeno iz fiksnega dela in kode iz Google Authenticatorja, nato pa se bo poskušal povezati z vpn. Če deluje, čestitamo, lahko mirno preskočite sredino, ki je zelo mučna, in preidete na točko o openconnectu, ki teče v ozadju. Če ne deluje, lahko nadaljujete. Čeprav je delovalo pri povezovanju, na primer iz gostujočega Wi-Fi-ja v službi, potem je morda prezgodaj za veselje; poskusite ponoviti postopek od doma.
Potrdilo
Obstaja velika verjetnost, da se nič ne bo zagnalo, izhod openconnect pa bo videti nekako takole:
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 progressPo eni strani je to neprijetno, ker ni bilo povezave z VPN, po drugi strani pa je načeloma jasno, kako odpraviti to težavo.
Tukaj nam je strežnik poslal potrdilo, po katerem lahko ugotovimo, da se povezava vzpostavlja na strežnik naše domače korporacije in ne na zlobnega goljufa, in tega potrdila sistem ne pozna. In zato ne more preveriti, ali je strežnik pravi ali ne. In tako za vsak slučaj preneha delovati.
Da se openconnect poveže s strežnikom, mu morate s ključem —servercert izrecno povedati, katero potrdilo naj prihaja iz strežnika VPN
Kateri certifikat nam je poslal strežnik, lahko ugotovite neposredno iz tega, kar je natisnil openconnect. Tukaj je iz tega dela:
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 tem ukazom se lahko poskusite znova povezati
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comMorda zdaj deluje, potem lahko nadaljujete do konca. Osebno pa mi je Ubuntu v tej obliki pokazala figo
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 bo razrešil, vendar tja ne boste mogli iti. Naslovi, kot je jira.evilcorp.com, sploh niso razrešeni.
Kaj se je tukaj zgodilo, mi ni jasno. Vendar poskus kaže, da če dodate vrstico v /etc/resolv.conf
nameserver 192.168.430.534potem se bodo naslovi znotraj VPN-ja začeli čudežno razreševati in lahko se sprehodite skozi njih, kar pomeni, da tisto, kar DNS išče za razrešitev naslovov, je videti posebej v /etc/resolv.conf in ne kje drugje.
Lahko preverite, ali obstaja povezava z VPN in deluje, ne da bi spremenili /etc/resolv.conf; to storite tako, da v brskalnik ne vnesete simboličnega imena vira iz VPN, ampak njegov naslov IP
Posledično se pojavita dve težavi
- Pri povezovanju z VPN se njegov dns ne prevzame
- ves promet poteka prek VPN-ja, ki ne omogoča dostopa do interneta
Povedal vam bom, kaj storiti zdaj, ampak najprej malo avtomatizacije.
Samodejni vnos fiksnega dela gesla
Do sedaj ste najverjetneje že vsaj petkrat vnesli geslo in vas je ta postopek že utrudil. Prvič, ker je geslo dolgo, in drugič, ker se morate pri vnosu umestiti v določeno časovno obdobje
Končna rešitev težave ni bila vključena v članek, vendar lahko poskrbite, da fiksnega dela gesla ni treba večkrat vnašati.
Recimo, da je fiksni del gesla fixedPassword, del iz Google Authenticatorja pa 567 987. Celotno geslo je mogoče posredovati openconnect prek standardnega vnosa z uporabo argumenta --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinZdaj se lahko nenehno vračate na zadnji vneseni ukaz in tam spremenite le del Google Authenticatorja.
VPN podjetja vam ne omogoča brskanja po internetu.
Na splošno ni zelo neprijetno, če morate za dostop do Habra uporabiti ločen računalnik. Nezmožnost kopiranja in lepljenja iz stackoverfow lahko na splošno ohromi delo, zato je treba nekaj narediti.
Moramo ga nekako organizirati tako, da ko morate dostopati do vira iz notranjega omrežja, gre Linux na VPN, in ko morate iti na Habr, gre na internet.
openconnect po zagonu in vzpostavitvi povezave z vpn izvede poseben skript, ki se nahaja v /usr/share/vpnc-scripts/vpnc-script. Nekatere spremenljivke so posredovane skriptu kot vhod in ta konfigurira VPN. Na žalost nisem mogel ugotoviti, kako razdeliti prometne tokove med VPN podjetja in preostalim internetom z uporabo izvornega skripta.
Očitno je bil pripomoček vpn-slice razvit posebej za ljudi, kot sem jaz, ki vam omogoča pošiljanje prometa po dveh kanalih brez plesa s tamburinom. No, to pomeni, da boste morali plesati, ni pa vam treba biti šaman.
Ločevanje prometa z uporabo vpn-slice
Najprej boste morali namestiti vpn-slice, to boste morali ugotoviti sami. Če bodo v komentarjih vprašanja, bom o tem napisal ločeno objavo. Toda to je običajen program Python, tako da ne bi smelo biti težav. Namestil sem z virtualenv.
In nato je treba uporabiti pripomoček z uporabo stikala -script, ki nakazuje openconnectu, da morate namesto standardnega skripta uporabiti 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 posreduje niz z ukazom, ki ga je treba poklicati namesto skripta. ./bin/vpn-slice - pot do izvršljive datoteke vpn-slice 192.168.430.0/24 - maska naslovov, na katere želite iti v vpn. Tukaj mislimo, da če se naslov začne z 192.168.430, potem je treba vir s tem naslovom iskati znotraj VPN-ja
Stanje bi moralo biti zdaj skoraj normalno. Skoraj. Zdaj lahko greste na Habr in lahko greste na vir znotraj podjetja z ip, vendar ne morete iti na vir znotraj podjetja s simboličnim imenom. Če določite ujemanje med simboličnim imenom in naslovom v gostiteljih, bi moralo vse delovati. In delaj, dokler se ip ne spremeni. Linux lahko zdaj dostopa do interneta ali intraneta, odvisno od IP-ja. Vendar se za določanje naslova še vedno uporablja nekorporacijski DNS.
Težava se lahko kaže tudi v tej obliki - v službi je vse v redu, doma pa lahko do notranjih virov podjetja dostopate le prek IP-ja. To je zato, ker ko ste povezani na korporativni Wi-Fi, se uporablja tudi korporativni DNS in se v njem razrešijo simbolični naslovi iz VPN, kljub temu, da je še vedno nemogoče iti na tak naslov brez uporabe VPN.
Samodejno spreminjanje datoteke hosts
Če se vpn-slice vljudno vpraša, potem lahko po dvigu VPN odide na svoj DNS, tam poišče naslove IP potrebnih virov po njihovih simboličnih imenih in jih vnese v gostitelje. Po izklopu VPN bodo ti naslovi odstranjeni iz gostiteljev. Če želite to narediti, morate vpn-slice posredovati simbolična imena kot argumente. Všečkaj 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 Zdaj bi moralo vse delovati tako v pisarni kot na plaži.
Poiščite naslove vseh poddomen v DNS, ki jih poda VPN
Če je v omrežju malo naslovov, potem pristop samodejnega spreminjanja datoteke gostiteljev deluje precej dobro. Če pa je v omrežju veliko virov, boste morali v skript nenehno dodajati vrstice, kot je zoidberg.test.evilcorp.com, zoidberg je ime ene od preskusnih klopi.
Toda zdaj, ko malo razumemo, zakaj je to potrebo mogoče odpraviti.
Če po dvigu VPN pogledate v /etc/hosts, lahko vidite to vrstico
192.168.430.534 dns0.tun0 # vpn-slice-tun0 SAMODEJNO USTVARJENO
V resolv.conf je bila dodana nova vrstica. Skratka, vpn-slice je nekako določil, kje se nahaja dns strežnik za vpn.
Zdaj se moramo prepričati, da gre Linux za iskanje naslova IP imena domene, ki se konča na evilcorp.com, na korporativni DNS, in če je potrebno kaj drugega, na privzetega.
Kar nekaj časa sem brskal po Googlu in ugotovil, da je taka funkcionalnost na voljo v Ubuntuju takoj po izdelavi. To pomeni možnost uporabe lokalnega strežnika DNS dnsmasq za razreševanje imen.
To pomeni, da lahko zagotovite, da se Linux za naslove IP vedno obrača na lokalni strežnik DNS, ki bo nato, odvisno od imena domene, iskal IP na ustreznem zunanjem strežniku DNS.
Za upravljanje vsega, kar je povezano z omrežji in omrežnimi povezavami, Ubuntu uporablja NetworkManager, grafični vmesnik za izbiro na primer povezav Wi-Fi pa je le sprednji del tega.
Plezati bomo morali v njegovi konfiguraciji.
- Ustvarite datoteko v /etc/NetworkManager/dnsmasq.d/evilcorp
naslov=/.evilcorp.com/192.168.430.534
Bodite pozorni na točko pred evilcorp. Dnsmasq sporoča, da je treba vse poddomene evilcorp.com preiskati v dns podjetja.
- Povejte NetworkManagerju, naj uporabi dnsmasq za razrešitev imen
Konfiguracija omrežnega upravitelja se nahaja v /etc/NetworkManager/NetworkManager.conf Tja morate dodati:
[glavni] dns=dnsmasq
- Znova zaženite NetworkManager
service network-manager restartZdaj, po povezavi z VPN z uporabo openconnect in vpn-slice, bo ip določen normalno, tudi če ne dodate simboličnih naslovov argumentom vpnslice.
Kako dostopati do posameznih storitev prek VPN
Ko sem se uspel povezati z VPN, sem bil dva dni zelo vesel, nato pa se je izkazalo, da če se povežem z VPN zunaj pisarniškega omrežja, potem pošta ne deluje. Simptom je znan, kajne?
Naša pošta se nahaja na mail.publicevilcorp.com, kar pomeni, da ne spada pod pravilo v dnsmasq in se naslov poštnega strežnika išče prek javnega DNS-ja.
No, urad še vedno uporablja DNS, ki vsebuje ta naslov. To sem mislil. Pravzaprav po dodajanju vrstice v dnsmasq
naslov=/mail.publicevilcorp.com/192.168.430.534
situacija se ni prav nič spremenila. ip je ostal isti. Moral sem v službo.
In šele kasneje, ko sem se poglobil v situacijo in malo razumel problem, mi je en pameten povedal, kako ga rešiti. Na poštni strežnik se je bilo treba povezati ne kar tako, ampak prek VPN-ja
Uporabljam vpn-slice za prehod prek VPN do naslovov, ki se začnejo z 192.168.430. In poštni strežnik nima le simboličnega naslova, ki ni poddomena evilcorp, ampak tudi nima naslova IP, ki se začne z 192.168.430. In seveda ne dovoli nikomur iz splošne mreže, da pride k njemu.
Da bo Linux šel prek VPN-ja in do poštnega strežnika, ga morate dodati tudi v vpn-slice. Recimo, da je naslov 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 dvig VPN z enim argumentom
Vse to seveda ni zelo priročno. Da, besedilo lahko shranite v datoteko in ga kopirate in prilepite v konzolo, namesto da bi ga tipkali ročno, vendar še vedno ni zelo prijetno. Za lažji postopek lahko ukaz zavijete v skript, ki se nahaja v PATH. In potem boste morali samo vnesti kodo, prejeto od 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 Če postavite skript v connect~evilcorp~, lahko preprosto pišete v konzolo
connect_evil_corp 567987Toda zdaj morate iz neznanega razloga še vedno imeti odprto konzolo, v kateri se izvaja openconnect
Izvajanje openconnect v ozadju
Na srečo so avtorji openconnect poskrbeli za nas in programu dodali poseben ključ -background, zaradi katerega program po zagonu deluje v ozadju. Če jo zaženete tako, lahko zaprete konzolo po zagonu
#!/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 Zdaj preprosto ni jasno, kam gredo hlodi. Na splošno dnevnikov res ne potrebujemo, a nikoli ne veš. openconnect jih lahko preusmeri v syslog, kjer bodo shranjeni na varnem. ukazu morate dodati stikalo –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 In tako se izkaže, da openconnect deluje nekje v ozadju in nikogar ne moti, vendar ni jasno, kako ga ustaviti. To pomeni, da lahko seveda filtrirate izhod ps z uporabo grep in poiščete proces, katerega ime vsebuje openconnect, vendar je to nekako dolgočasno. Hvala avtorjem, ki so mislili tudi na to. Openconnect ima ključ -pid-file, s katerim lahko ukazate openconnectu, da zapiše svoj identifikator procesa v datoteko.
#!/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-pidZdaj lahko vedno ubijete proces z ukazom
kill $(cat ~/vpn-pid)Če procesa ni, bo kill preklinjal, vendar ne bo vrgel napake. Če datoteke ni, se tudi ne bo zgodilo nič slabega, tako da lahko varno ubijete postopek v prvi vrstici skripta.
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-pidZdaj lahko vklopite računalnik, odprete konzolo in zaženete ukaz ter mu posredujete kodo iz Google Authenticatorja. Konzolo lahko nato pribijete.
Brez rezine VPN. Namesto spremne besede
Izkazalo se je, da je zelo težko razumeti, kako živeti brez rezine VPN. Moral sem veliko brati in googlati. Na srečo se tehnični priročniki in celo man openconnect berejo kot razburljivi romani, potem ko smo toliko časa preživeli s težavo.
Posledično sem ugotovil, da vpn-slice, tako kot izvorni skript, spremeni usmerjevalno tabelo za ločevanje omrežij.
Usmerjevalna miza
Preprosto povedano, to je tabela v prvem stolpcu, ki vsebuje, s čim naj se začne naslov, skozi katerega želi iti Linux, in v drugem stolpcu, skozi kateri omrežni adapter naj gre na tem naslovu. V resnici je govorcev več, a to ne spremeni bistva.
Če si želite ogledati usmerjevalno tabelo, morate zagnati ukaz 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 Tu je vsaka vrstica odgovorna za to, kam morate iti, da pošljete sporočilo na določen naslov. Prvi je opis, kje naj se začne naslov. Da bi razumeli, kako ugotoviti, da 192.168.0.0/16 pomeni, da se mora naslov začeti z 192.168, morate v Googlu poiskati, kaj je maska naslova IP. Za dev je ime adapterja, na katerega je treba poslati sporočilo.
Za VPN je Linux naredil virtualni adapter - tun0. Linija zagotavlja, da skozi njo poteka promet za vse naslove, ki se začnejo z 192.168
192.168.0.0/16 dev tun0 scope link Z ukazom si lahko ogledate tudi trenutno stanje usmerjevalne tabele route -n (Naslovi IP so spretno anonimizirani) Ta ukaz daje rezultate v drugačni obliki in je na splošno zastarel, vendar je njegov rezultat pogosto najden v priročnikih na internetu in morate ga znati prebrati.
Kje naj se IP-naslov za pot začne, je razvidno iz kombinacije stolpcev Destination in Genmask. Tisti deli naslova IP, ki ustrezajo številkam 255 v Genmasku, so upoštevani, tisti, kjer je 0, pa ne. To pomeni, da kombinacija Destination 192.168.0.0 in Genmask 255.255.255.0 pomeni, da če se naslov začne z 192.168.0, bo zahteva do njega šla po tej poti. In če je cilj 192.168.0.0, vendar Genmask 255.255.0.0, bodo zahteve za naslove, ki se začnejo z 192.168, šle po tej poti
Da bi ugotovil, kaj vpn-slice dejansko počne, sem se odločil pogledati stanja tabel pred in po
Pred vklopom VPN je bilo tako
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 klicu openconnect brez vpn-slice je postalo tako
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 tun0In po klicu openconnect v kombinaciji z vpn-slice, kot je ta
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 če ne uporabljate vpn-slice, potem openconnect eksplicitno piše, da je treba do vseh naslovov, razen posebej označenih, dostopati prek vpn.
Točno tukaj:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Tam je zraven takoj označena druga pot, ki jo je treba uporabiti, če se naslov, ki ga poskuša prenesti Linux, ne ujema z nobeno masko iz tabele.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Tukaj je že napisano, da morate v tem primeru uporabiti standardni adapter Wi-Fi.
Menim, da je uporabljena pot VPN, ker je prva v usmerjevalni tabeli.
In teoretično, če odstranite to privzeto pot iz usmerjevalne tabele, potem mora v povezavi z dnsmasq openconnect zagotoviti normalno delovanje.
poskusil sem
route del defaultIn vse je delovalo.
Usmerjanje zahtev na poštni strežnik brez vpn-slice
Imam pa tudi poštni strežnik z naslovom 555.555.555.555, do katerega je prav tako treba dostopati preko VPN-ja. Tudi pot do njega je treba dodati ročno.
ip route add 555.555.555.555 via dev tun0In zdaj je vse v redu. Torej lahko brez vpn-slice, vendar morate dobro vedeti, kaj počnete. Zdaj razmišljam o tem, da bi v zadnjo vrstico izvornega skripta openconnect dodal odstranitev privzete poti in dodal pot za pošiljatelja po povezavi z vpn, samo zato, da je v mojem kolesu manj gibljivih delov.
Verjetno bi bil ta pogovor dovolj, da bi kdo razumel, kako nastaviti VPN. Toda medtem ko sem poskušal razumeti, kaj in kako narediti, sem prebral precej takšnih vodnikov, ki delujejo za avtorja, vendar iz nekega razloga ne delujejo zame, in sem se odločil, da sem dodam vse dele, ki sem jih našel. Česa takega bi bil zelo vesel.
Vir: www.habr.com