Kas soovite tööl kasutada Linuxit, kuid ettevõtte VPN ei luba? Siis võib see artikkel aidata, kuid see ei ole kindlasti kindel. Soovin eelnevalt hoiatada, et ma ei mõista võrguadministreerimise küsimustest hästi, seega ei välista, et olen kõik valesti teinud. Teisalt võib juhtuda, et suudan kirjutada juhendi nii, et see oleks tavalistele inimestele arusaadav, nii et soovitan proovida.

Artiklis on palju üleliigset teavet, kuid ilma nende teadmisteta ei oleks ma suutnud lahendada probleeme, mis mul ootamatult seoses VPN-i seadistamisega tekkisid. Arvan, et igaühel, kes püüab seda juhendit rakendada, võivad tekkida probleemid, mida mul ei olnud, ja loodetavasti aitab see üleliigne teave neid probleeme iseseisvalt lahendada.

Enamik juhendis kasutatavaid käske tuleb täita sudo kaudu, mis on lühiduse huvides välja jäetud. Pidage seda meeles.

Enamik IP-aadresse on tugeva obfuskeerimise all, seega kui näete sellist aadressi nagu 435.435.435.435 — peaks seal olema mingi normaalne IP, mis on teie juhtumi jaoks spetsiifiline.

Mul on Ubuntu 18.04, kuid arvan, et mõningate muudatustega saab juhist rakendada ka teistele distributsioonidele. Siiski, see tekst käsitleb Linuxit == Ubuntu.

Cisco Connect

Need, kes kasutavad Windowsi või MacOS-i, saavad meie ettevõtte VPN-iga ühendada läbi Cisco Connect, kuhu tuleb sisestada gateway aadress ja igaühenduse korral sisestada parool, mis koosneb fikseeritud osast ja Google Authenticatori genereeritavast koodist.

Linuxi puhul ei õnnestunud Cisco Connecti käivitada, kuid leidsin soovituse kasutada openconnect'i, mis on loodud just Cisco Connecti asendamiseks.

Openconnect

Ideaaljuhul peaks Ubuntus olema openconnect'i jaoks spetsiaalne graafiline liides, kuid minul see ei töötanud. Võib-olla on see ka parem.

Ubuntus installitakse openconnect paketihalduri kaudu.

apt install openconnect

Otse pärast installimist saab proovida VPN-iga ühenduda.

openconnect --user poxvuibr vpn.evilcorp.com

vpn.evilcorp.com on väljamõeldud VPNi aadress.
poxvuibr on väljamõeldud kasutajanimi.

openconnect palubab küsib parooli, mis koosneb fikseeritud osast ja Google Authenticator'i koodist, ning proovib seejärel vpn-iga ühendust luua. Kui see õnnestub, palju õnne, saate julgelt vaheosa vahele jätta, kus on palju vaeva, ja liikuda otse openconnect'i taustal töötamise punkti juurde. Kui see ei toimi, siis võib jätkata. Kuigi, kui see õnnestus näiteks kontori külaliswifi kaudu, siis võib-olla on varane rõõmustamine — proovige kodus sama protseduuri uuesti.

Sertifikaat

Suure tõenäosusega ei käivitu miski ning openconnect'i väljund näeb välja järgmiselt:

POST https://vpn.evilcorp.com/
Ühendatud 777.777.777.777:443
SSL läbirääkimised vpn.evilcorp.com-iga
Serveri sertifikaadi kontrollimine ebaõnnestus: allkirjaandjat ei leitud

VPN-serveri "vpn.evilcorp.com" sertifikaadi kontrollimine ebaõnnestus.
Põhjus: allkirjaandjat ei leitud
Kuna usaldada seda serverit tulevikus, lisage see võib-olla oma käsureale:
    --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Sisestage 'jah', et aktsepteerida, 'ei', et katkestada; miski muu, et vaadata: fgets (stdin): Operatsioon jätkub praegu.

Ühelt poolt on see ebameeldiv, kuna VPN-iga ühendust ei saanud, kuid teisalt on põhjus, kuidas seda probleemi lahendada, põhimõtteliselt arusaadav.

Siin server saatis meile sertifikaadi, mille alusel on võimalik kindlaks teha, et ühendus toimub just kohaliku ettevõtte serveriga, mitte kellegi pahatahtliku petisega, ja süsteemile pole see sertifikaat teada. Seetõttu ei suuda ta kontrollida, kas server on autentne või mitte. Ja seetõttu lõpetab ta igaks juhuks tegevuse.

Kuna openconnect peab siiski serveriga ühenduma, tuleb talle selgelt öelda, milline sertifikaat VPN-serverilt peab tulema, kasutades võtit —servercert.

Ja et teada saada, millise sertifikaadi server meile saatis, saame seda otse openconnecti väljatrükist. Just sellest osast:

Et usaldada seda serverit tulevikus, lisage see oma käsureale:
    --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Sisestage 'jah', et aktsepteerida, 'ei', et katkestada; midagi muud, et vaadata: fgets (stdin): Operatsioon käib praegu.

Sellise käsuga saab proovida uuesti ühenduda.

openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com

Võib-olla nüüd toimib, siis võib edasi minna. Aga mulle isiklikult näitas Ubuntu seda sõnumit sellisel kujul.

POST https://vpn.evilcorp.com/
Ühendatud 777.777.777.777:443
SSL-i läbirääkimised vpn.evilcorp.com-ga
Serveri sertifikaadi kontrollimine ebaõnnestus: allkirja leidmata
Ühendatud HTTPS-is vpn.evilcorp.com
XML POST on lubatud
Palun sisestage oma kasutajanimi ja parool.
POST https://vpn.evilcorp.com/
Sai CONNECT vastuse: HTTP/1.1 200 OK
CSTP ühendatud. DPD 300, Keepalive 30
DTLS seadistamine ebaõnnestus; kasutades selle asemel SSL-i
Ühendatud kui 192.168.333.222, kasutades SSL-i
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
RTNETLINK vastused: Fail eksisteerib
/etc/resolvconf/update.d/libc: Hoiatust: /etc/resolv.conf ei ole sümboolne link /run/resolvconf/resolv.conf-ile

/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.com

habr.com lahendab, aga sinna ei saa siseneda. Aadressid nagu jira.evilcorp.com ei lahene üldse.

Mis siin juhtus, ei ole mulle selge. Kuid eksperiment näitab, et kui lisada /etc/resolv.conf faili rida

nameserver 192.168.430.534

siis hakkavad aadressid VPN-i sees maagiliselt lahenduma ja nendega saab liikuda, st et see, mida kasutatakse aadresside lahendamiseks, vaatab just nimelt /etc/resolv.conf, mitte kuskile mujale.

Et VPN-iga ühendus on olemas ja see töötab, saab veenduda ka ilma muudatusteta /etc/resolv.conf, piisab, kui sisestada brauserisse mitte sümboolne ressursi nimi VPN-ist, vaid selle IP-aadress

Kokkuvõttes on kaks probleemi

• VPN-i ühendamisel ei võeta tema DNS-i kasutusele
• kogu liiklus läheb läbi VPN-i, mis ei luba interneti kasutada

Mida teha, räägin nüüd, aga kõigepealt veidi automatiseerimisest.

Automaatne fikseeritud parooli osa sisestamine

Seni olete tõenäoliselt juba oma parooli sisestanud vähemalt viis korda ja see protsess on teid uudistest väsitanud. Esiteks, kuna parool on pikk, ja teiseks, kuna sisestamisel tuleb mahtuda fikseeritud ajavahemikku.

Kahjuks ei jõudnud probleemi lõplik lahendus artiklisse, kuid saate teha nii, et fikseeritud parooli osa ei peaks mitu korda sisestama.

Oletame, et fikseeritud parooli osa on fixedPassword ja Google Authenticator'i osa on 567 987. Kogu parooli, openconnect, saab edastada tavalise sisendiga, kasutades argumenti —passwd-on-stdin.

echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdin

Nüüd saab pidevalt naasta viimati sisestatud käsu juurde ja vahetada seal ainult Google Authenticator'i osa.

Korporatiivne VPN ei luba internetti surfata.

Üldiselt ei ole väga mugav, et Habrisse minemiseks peab kasutada eraldi arvutit. Stack Overflow'ist kopeerimise võimaluse puudumine võib töö täielikult seiskada, seega tuleb midagi teha.

Peab kuidagi organiseerima, et kui on vaja ressursse sisemisest võrgust külastada, siis Linux kasutaks VPN-i, ja kui on vaja Habrisse siseneda — siis internetti.

OpenConnect, pärast käivitamist ja VPN-iga ühenduse loomist, käivitab spetsiaalse skripti, mis asub aadressil /usr/share/vpnc-scripts/vpnc-script. Skripti sisendiks on mõned muutujad, mille põhjal ta seadistab VPN-i. Kahjuks ei suutnud ma aru saada, kuidas jagada liiklust firma VPN-i ja muu interneti vahel sisseehitatud skripti abil.

Ilmselt on just selliste jaoks nagu mina välja töötatud tööriist vpn-slice, mis võimaldab suunata liiklust kahe kanali kaudu ilma liigse vaevata. Noh, tantsida tuleb, aga šamaan olema ei pea.

Liikluse jagamine vpn-slice'i abil

Esiteks tuleb installida vpn-slice, selle osas tuleb iseseisvalt hakkama saada. Kui kommentaarides tekib küsimusi, kirjutan selle kohta eraldi postituse. Kuid see on tavaline programm Pythonis, seega ei tohiks raskusi olla. Mina installisin selle virtualenvi abil.

Seejärel tuleb tööriista rakendada, kasutades lippu —script, määrates openconnect, et kasutada vpn-slice standardse skripti asemel.

echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin 
--script "./bin/vpn-slice 192.168.430.0/24  " vpn.evilcorp.com 

—scripti antakse string käsust, mis tuleb kutsuda välja skripti asemel. ./bin/vpn-slice — tee täidetava faili vpn-slice juurde, 192.168.430.0/24 — aadresside mask, mille kaudu tuleb vpn-is minna. Siin mõeldakse, et kui aadress algab 192.168.430 — siis tuleb seda aadressi otsida vpn-i seest.

Nüüd peaks olukord olema peaaegu normaalne. Peaaegu. Nüüd on võimalik pääseda Habrisse ja sisevõrgu ressurssidesse IP kaudu, kuid ei saa sisevõrgu ressurssidesse siseneda sümboolse nime kaudu. Kui määrate hosts failis sümboolse nime ja aadressi vastavuse, peaks kõik toimima. Ja see töötab, kuni IP muutub. Linux oskab nüüd internetti pääseda või sisevõrku siseneda sõltuvalt IP-st. Kuid aadressi määramiseks kasutatakse endiselt mitte-korporatiivset DNS-i.

Probleem võib esineda ka sellisel kujul — tööl on kõik normaalne, aga kodus pääseb sisevõrgu ressurssidesse vaid IP kaudu. See on tingitud sellest, et kui oled ühendatud ettevõtte Wi-Fi-iga, kasutatakse DNS-i, mis on samuti ettevõtte oma, ja seal lahendatakse VPN-i kaudu sümboolseid aadresse, kuigi sellise aadressi kaudu ilma VPN-ita pääseda ei saa.

Hosts faili automaatne muutmine

Kui vpn-slice viisakalt paluda, võib ta pärast VPN-i loomist minna tema DNS-i, leida sealt vajalike ressursside IP-aadresse nende sümboolsate nimede järgi ja kirjutada need hosts-faili. VPN-i väljalülitamisel need aadressid hosts-ist eemaldatakse. Selleks tuleb edastada sümboolseid nimesid vpn-slice'ile argumentidena. Nii.

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 

Nüüd peaks kõik töötama nii kontoris kui ka rannas.

Otsida kõigi alamdomeenide aadresse DNS-ist, mille VPN andis

Kui aadresse sisevõrgus on vähe, siis lähenemine hosts-faili automaatse muutmisega on täiesti toimiv. Kuid kui ressursse võrgus on palju, peate pidevalt lisama skripti ridu, nagu zoidberg.test.evilcorp.com, zoidberg — see on üks testimise seise.

Aga nüüd, kui me natuke aru saame, on seda vajadust võimalik kõrvaldada.

Kui pärast VPN-i loomist vaadata /etc/hosts, võib näha sellist rida

192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED

Ja resolv.conf-ile on lisatud uus rida. Ühesõnaga, vpn-slice suudab kuidagi määrata, kus DNS-server VPN-i jaoks asub.

Nüüd tuleb teha nii, et Linux läheks ettevõtte DNS-i, et määrata IP-aadress domeeninime jaoks, mis lõpeb evilcorp.com, ning kui on vaja midagi muud, siis vaikimisi DNS-i.

Olen üsna kaua guugeldanud ja avastanud, et selline funktsionaalsus on Ubuntus välja pakkuda. See tähendab, et on võimalus kasutada nimede resolvamiseks lokaalset DNS-serverit dnsmasq.

Seega on võimalik teha nii, et Linux läheb IP-aadresside pärast alati kohaliku DNS-serveri juurde, mis omakorda, sõltuvalt domeeninimest, otsib IP-d vastavalt välisele DNS-serverile.

Kõigi, mis on seotud võrkude ja võrguühendustega, haldamiseks kasutab Ubuntu NetworkManagerit, ja graafiline liides, näiteks Wi-Fi ühenduse valimiseks on lihtsalt front sellele.

Peame natuke tema konfiguratsioonides ringi vaatama.

1. Loo fail aadressil /etc/NetworkManager/dnsmasq.d/evilcorp

address=/.evilcorp.com/192.168.430.534

Pöörake tähelepanu punktile evilcorp ees. See annab dnsmasq'le märku, et kõik aladomeenid evilcorp.com tuleb otsida just ettevõtte DNS-ist.

1. Ütle NetworkManagerile, et nimede resolveerimiseks tuleb kasutada dnsmasq'i.

network-manageri konfiguratsioon asub veebilehes /etc/NetworkManager/NetworkManager.conf. Peate sinna lisama:

[main]
dns=dnsmasq

1. Taaskäivitage NetworkManager

service network-manager restart

Nüüd, pärast VPN-i ühendamist openconnect'i ja vpn-slice'i abil, määratakse IP korralikult, isegi kui sümboolseid aadresse vpnslice'i argumentidesse ei lisata.

Kuidas minna VPN-i kaudu erinevatesse teenustesse

Pärast VPN-iga ühenduse loomise edukust olin paar päeva väga õnnelik, kuid seejärel selgus, et kui VPN-i ei ühendata kontori võrgust, ei tööta e-post. Tunnetus on tuttav, eks?

Meie e-post on aadressil mail.publicevilcorp.com, mis tähendab, et see ei lähe dnsmasq reegli alla ja postiserveri aadressi otsitakse avaliku DNS-i kaudu.

Aga kontoris kasutatakse ikkagi DNS-i, kus see aadress olemas on. Nii ma arvasin. Tegelikult, pärast dnsmasq-sse rea lisamist

address=/mail.publicevilcorp.com/192.168.430.534

situatsioon ei muutunud. IP jäi samaks. Olin sunnitud tööle minema.

Ja juba hiljem, kui süvenesin olukorda ja natuke lahendasin probleemi, ütles üks tark inimene mulle, kuidas seda lahendada. Pidi ühenduma postiserveriga mitte lihtsalt nii, vaid läbi VPN-i.

Ma kasutan vpn-slice'i, et VPN-i kaudu sirvida aadresse, mis algavad 192.168.430. Algselt ei ole mitte ainult postiserveri sümboolne aadress evilcorp alamdomeen, vaid ka selle IP-aadress ei alga 192.168.430. Ja loomulikult ei luba ta kedagi oma üldvõrgustikku.

Kuna Linux peab postiserverisse ja VPN-i ühenduma, tuleb lisada see vpn-slice'i. Oletame, et postiserveri aadress on 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 

VPN-i käivitamise skript ühe argumendiga

Kõik see on muidugi pigem ebamugav. Jah, teksti võib salvestada faili ja kopeerida terminali, mitte sisestada käsitsi, kuid see pole ikkagi meeldiv. Protsessi lihtsustamiseks saab käsu mähkida skripti, mis asub PATH-is. Siis peab sisestama ainult Google Authenticatorist saadud koodi.

#!/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 

Kui skript panna connect~evilcorp~ kausta, saab lihtsalt kirjutada terminalis

connect_evil_corp 567987

Kuid nüüd peab siiski hoidma avatud terminali, kus openconnect on käivitunud.

openconnect'i taustal käivitamine

Õnneks on openconnecti autorid meie eest hoolitsenud ja lisanud programmile spetsiaalse võtme —background, mis võimaldab programmil pärast käivitamist taustal töötada. Kui selle nii käivitada, saab konsooli pärast käivitamist sulgeda.

#!/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  

Nüüd on vaid arusaamatu, kuhu logid lähevad. Logisid me tegelikult eriti ei vaja, aga kes teab. Openconnect võib need suunata syslog'i, kus nad säilivad puutumatuna ja turvaliselt. Seda tuleks lisada käsu võtmena —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  

Ja nii ongi, et openconnect töötab kusagil seal taustal ja ei sega kedagi, kuid kuidas seda peatada, ei ole selge. Loomulikult saab filtreerida ps väljundit grepiga ja otsida protsessi, mille nimes on openconnect, kuid see on natuke tüütu. Aitäh autoritele, kes on ka sellele mõelnud. Openconnect'is on võtme —pid-file, millega saab openconnect'ile öelda, et see kirjutaks oma protsessi ID faili.

#!/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-pid

Nüüd saab protsessi alati lõpetada käsuga

kill $(cat ~/vpn-pid)

Kui protsessi pole, siis kill protesteerib, kuid ei viska tõrget. Kui faili pole, siis ei juhtu ka midagi hirmsat, nii et võib julgelt protsessi esimeses skripti real tappa.

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-pid

Nüüd võite arvuti sisse lülitada, avada konsooli ja käivitada käsk, edastades sellele koodi Google Authenticatorist. Konsooli saab hiljem kinni panna.

Ilma vpn-slice'ita. Ilma järelsõnata

Mõista, kuidas elada ilma vpn-slice'ita, osutus väga keeruliseks. Pidin palju lugema ja guugeldama. Õnneks, kui olin probleemiga nii kaua tegelenud, loeti tehnilisi juhendeid ja isegi man openconnect'i nagu kaasahaaravaid romaane.

Tulemuseks selgitasin, et vpn-slice, nagu ka originaalskript, muudab marsruuditaine, et võrke jagada.

Marsruuditabel

See on lihtsustatult öeldes selline tabel, mille esimeses veerus on see, kust peaks algama aadress, millega Linux tahab minna, ja teises, millise võrguaadapti kaudu seda aadressi läbida. Tegelikult on veerge rohkem, kuid see ei muuda sisu.

Marsruuditabeli nägemiseks peate käivitama käsu 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 

Siin vastutab iga rida selle eest, kuidas minna, et saata sõnum teatud aadressile. Esimesena käib kirjeldus, kust aadress peaks algama. Selleks, et mõista, mis tähendab 192.168.0.0/16, tuleks otsida, mis on IP-aadressi mask. Pärast dev järgneb adaptori nimi, kuhu sõnum saata.

VPN jaoks on Linux loonud virtuaalse adapteri — tun0. Rida, mis tagab, et kõik aadressid, mis algavad 192.168, voolavad läbi selle, on

192.168.0.0/16 dev tun0 scope link 

Samuti saab vaadata praegust marsruuditabeli seisundit käsu abil route -n (IP-aadressid on oskuslikult anonüümsed) See käsk annab tulemused teises vormis ja on tegelikult vananenud, kuid selle väljundit kohatakse sageli juhendites internetis ning tuleb osata seda lugeda.

IP-aadressi marsruudi algust saab mõista siht-kohtade ja Genmaski kombinatsiooni kaudu. Need IP-aadressi osad, millele Genmaskis vastavad numbrid 255, arvestatakse, ning need, kus on 0 — mitte. Seega sihtkoht 192.168.0.0 ja Genmask 255.255.255.0 tähendab, et kui aadress algab 192.168.0, siis päring toimub selle marsruudi kaudu. Kui sihtkoht on 192.168.0.0, aga Genmask 255.255.0.0, siis selle marsruudi kaudu liikuvad päringud aadressidele, mis algavad 192.168.

Selleks, et mõista, mida vpn-slice tegelikult teeb, otsustasin vaadata tabelite olekuid enne ja pärast.

Enne VPN-i sisselülitamist oli olukord selline

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 wlp3s0

Pärast openconnecti käivitamist ilma vpn-sliceta nägi see välja selline

route -n

Kernel IP routing table
Sihtkoht       Lüliti         Genmask         Lipud Meetod Viide Kasutaja 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 tun0

Ja pärast openconnect'i käivitamist koos vpn-slice'iga, on see nii.

Kernel IP routing table
Sihtkoht       Lüliti         Genmask         Lipud Meetod Viide Kasutaja 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 tun0

On näha, et kui vpn-slice'i ei kasutada, siis openconnect ütleb otseselt, et kõikidele aadressidele, välja arvatud eraldi näidatud, tuleb minna vpn'i kaudu.

Siin:

0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 tun0

Seal on kohe kõrval näidatud veel üks tee, mida tuleb kasutada, kui aadress, mille kaudu Linux püüab minna, ei vasta ühele maskidest tabelis.

0.0.0.0         222.222.222.1   0.0.0.0         UG    600    0        0 wlp3s0

Siin on juba öeldud, et sellisel juhul tuleb minna läbi tavalise wifi-adapteri.

Ma arvan, et VPN-i tee kasutatakse, kuna see on marsruudi tabelis esimene.

Ja teoreetiliselt, kui eemaldada see vaikimisi tee marsruudi tabelist, siis koos dnsmasq-iga peaks openconnect tagama normaalse töö.

Ma proovisin

route del default

Ja kõik töötas.

Soodustused päringute suunamiseks meiliserverisse ilma vpn-slice'ita

Aga mul on veel meiliserver aadressiga 555.555.555.555, kuhu tuleb samuti minna läbi vpn. Marsruut selle juurde peab ka käsitsi lisama.

ip route add 555.555.555.555 via dev tun0

Ja nüüd kõik on korras. Nii et vpn-slice'ita saab ka hakkama, aga peab teadma, mida teed. Mõtlen nüüd, kas viimasel real originaalskripti openconnect'i puhul lisada vaikimisi marsruudi kustutamine ja marsruudi lisamine meiliserverisse pärast vpn-iga ühendamist, lihtsalt selleks, et mu jalgratta liikuvad osad oleksid vähem.

Võib-olla piisab kellegile VPN-i seadistamise mõistmiseks sellest järelsõnast. Kuid samal ajal kui ma püüdsin aru saada, mida ja kuidas teha, lugesin piisavalt palju selliseid juhendeid, mis töötavad autori jaoks, kuid mingil põhjusel ei töötanud minu jaoks, ja otsustasin siia lisada kõik leitud tükid. Oleksin sellisest abist väga rõõmus.

Allikas: habr.com