Kas soovid tööl Linuxit kasutada, aga sinu ettevõtte VPN ei luba? Siis võib see artikkel abiks olla, kuigi ma pole kindel. Tahan sind ette hoiatada, et ma ei saa võrguadministreerimisest eriti hästi aru, seega on võimalik, et tegin kõik valesti. Teisest küljest on võimalik, et suudan kirjutada juhendi, mis on tavainimestele arusaadav, seega soovitan sul seda proovida.

Artiklis on palju ebavajalikku infot, aga ilma selle teadmiseta poleks ma suutnud lahendada probleeme, mis mul VPN-i seadistamisega ootamatult tekkisid. Arvan, et kõigil, kes seda juhendit rakendavad, tekivad probleemid, mida minul polnud, ja loodan, et see ebavajalik info aitab neil need probleemid iseseisvalt lahendada.

Enamik selles juhendis kasutatud käske tuleb käivitada sudo kaudu, mis on lühiduse huvides eemaldatud. Pidage seda meeles.

Enamik IP-aadresse on tugevalt hägustatud, seega kui näete aadressi nagu 435.435.435.435, peaks seal olema mingi tavaline IP-aadress, mis on teie juhtumile omane.

Mul on Ubuntu 18.04. aprill, aga ma arvan, et juhendit saaks väikeste muudatustega rakendada ka teistele distributsioonidele. Selles tekstis aga Linux == Ubuntu.

Cisco Connect

Need, kes istuvad Windows või macOS saavad meie ettevõtte VPN-iga ühenduse luua Cisco Connecti kaudu, mis nõuab iga ühenduse loomisel lüüsi aadressi määramist ja parooli sisestamist, mis koosneb fikseeritud osast ja Google Authenticatori genereeritud koodist.

Linuxi puhul ei õnnestunud Cisco Connecti käivitada, aga Google'ist sai otsida soovituse kasutada spetsiaalselt Cisco Connecti asendamiseks mõeldud OpenConnecti.

Openconnect

Teoreetiliselt on Ubuntul OpenConnecti jaoks spetsiaalne graafiline liides, aga minu puhul see ei toiminud. Võib-olla ongi see parim lahendus.

Ubuntus installitakse openconnect paketihalduri kaudu.

apt install openconnect

VPN-iga ühenduse loomise võite proovida kohe pärast installimist

openconnect --user poxvuibr vpn.evilcorp.com

vpn.evilcorp.com on fiktiivse VPN-i aadress
poxvuibr — väljamõeldud kasutajanimi

OpenConnect palub teil sisestada parooli, mis, tuletan teile meelde, koosneb fikseeritud osast ja Google Authenticatori koodist ning seejärel proovib see VPN-iga ühendust luua. Kui see töötab, siis palju õnne, võite keskmise osa, mis on väga tülikas, julgelt vahele jätta ja minna edasi punkti, mis käsitleb OpenConnecti taustal töötamist. Kui see ei tööta, siis võite jätkata. Kuigi kui see töötab näiteks tööl külalis-Wi-Fi kaudu ühenduse loomisel, siis võib rõõmustamiseks olla veel vara, peate proovima protseduuri kodust korrata.

Tunnistus

On suur tõenäosus, et midagi ei käivitu ja openconnecti väljund näeb välja umbes selline:

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 progress

Ühelt poolt on see ebameeldiv, kuna VPN-ühendust ei tekkinud, kuid teisalt on selle probleemi lahendamine põhimõtteliselt selge.

Siin saatis server meile sertifikaadi, mille abil saame kindlaks teha, et ühendus on loodud kohaliku korporatsiooni serveriga, mitte kurja petturiga, kuid süsteem seda sertifikaati ei tea. Ja seetõttu ei saa see kontrollida, kas server on ehtne või mitte. Ja seetõttu igaks juhuks see lakkab töötamast.

Selleks, et openconnect serveriga ühenduse saaks luua, peate sellele selgesõnaliselt ütlema, milline sertifikaat peaks VPN-serverist pärinema, kasutades võtit —servercert.

Ja openconnecti väljatrükkidest näete otse, millise sertifikaadi server meile saatis. Siin on sellest artiklist:

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 progress

Selle käsuga saate uuesti ühendust luua

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

Võib-olla see nüüd toimib, siis saame edasi liikuda lõppu. Aga isiklikult näitas Ubuntu mulle seda figuuri sellisel kujul.

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

habr.com lahendatakse, aga te ei saa sellele ligi. Aadresse nagu jira.evilcorp.com ei lahendata üldse.

Mis siin juhtus, pole mulle selge. Aga katse näitab, et kui lisada rida faili /etc/resolv.conf

nameserver 192.168.430.534

Siis hakkavad VPN-i sees olevad aadressid maagiliselt lahendama ja saate nende vahel navigeerida, st see, mida otsitakse, millist DNS-i aadresside lahendamiseks otsitakse, otsitakse konkreetselt /etc/resolv.conf failist, mitte kusagilt mujalt.

VPN-ühenduse olemasolu ja toimimist saab kontrollida ilma faili /etc/resolv.conf muutmata. Selleks sisesta brauserisse lihtsalt VPN-i ressursi IP-aadress, mitte selle sümboolne nimi.

Selle tulemusena on kaks probleemi.

• VPN-iga ühenduse loomisel selle DNS-i ei valita
• Kogu liiklus läheb läbi VPN-i, mis ei võimalda teil internetti minna

Ma ütlen teile nüüd, mida teha, aga kõigepealt natuke automatiseerimist.

Parooli fikseeritud osa automaatne sisestamine

Tõenäoliselt olete parooli sisestanud vähemalt viis korda ja see protseduur on teid juba ära väsitanud. Esiteks seetõttu, et parool on pikk ja teiseks seetõttu, et peate selle sisestama kindla aja jooksul.

Probleemi lõplikku lahendust artiklis ei olnud, aga seda on võimalik teha nii, et parooli fikseeritud osa ei pea mitu korda sisestama.

Oletame, et parooli fikseeritud osa on „fixedPassword” ja Google Authenticatori osa on 567 987. Kogu openconnecti parooli saab edastada standardsisendi kaudu argumendi --passwd-on-stdin abil.

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

Nüüd saate pidevalt naasta viimase sisestatud käsu juurde ja muuta ainult sealset Google Authenticatori osa.

Ettevõtte VPN ei võimalda teil internetti pääseda.

See pole üldse mugav, kui pead Habri minekuks kasutama eraldi arvutit. Stackoverfow'st kopeerimise ja kleepimise võimatus võib su töö täielikult halvata, seega pead midagi ette võtma.

Peame selle kuidagi korraldama nii, et kui meil on vaja sisevõrgust ressursile ligi pääseda, läheb Linux VPN-i ja kui meil on vaja Habr-ile ligi pääseda, läheb see internetti.

Pärast VPN-ühenduse loomist ja käivitamist käivitab openconnect spetsiaalse skripti, mis asub kaustas /usr/share/vpnc-scripts/vpnc-script. Skriptile edastatakse sisendiks mõned muutujad ja see konfigureerib VPN-i. Kahjuks ei suutnud ma välja mõelda, kuidas jagada liiklusvooge ettevõtte VPN-i ja ülejäänud Interneti vahel natiivse skripti abil.

Ilmselt töötati vpn-slice utiliit välja spetsiaalselt minusugustele inimestele, mis võimaldab teil suunata liiklust kahe kanali kaudu ilma tamburiiniga tantsimata. Noh, see tähendab, et peate tantsima, aga te ei pea olema šamaan.

Liikluse jagamine vpn-slice'i abil

Esiteks peate installima vpn-slice'i, peate selle ise välja mõtlema. Kui kommentaarides on küsimusi, kirjutan sellest eraldi postituse. Aga see on tavaline Pythoni programm, seega ei tohiks raskusi tekkida. Paigaldasin selle virtualenv abil.

Ja seejärel tuleb utiliit rakendada, kasutades võtit -script, mis näitab, et tavalise skripti asemel tuleb kasutada vpn-slice'i.

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

Funktsioonis —script edastatakse käsuga string, mida tuleb skripti asemel kutsuda. ./bin/vpn-slice — käivitatava faili tee vpn-slice 192.168.430.0/24 — aadresside mask, mida tuleks VPN-i minekuks kasutada. See tähendab, et kui aadress algab numbritega 192.168.430, siis tuleks selle aadressiga ressurssi otsida VPN-ist.

Nüüd peaks olukord olema peaaegu normaalne. Peaaegu. Nüüd saate minna Habr-i ja IP-aadressi järgi ettevõttesisese ressursi juurde, aga sümboolse nime järgi ettevõttesisese ressursi juurde ei saa. Kui registreerite sümboolse nime ja aadressi vastavuse hostides, peaks kõik toimima. Ja toimima kuni IP-aadressi muutumiseni. Linux saab nüüd minna internetti või ettevõttesisesesse võrku, olenevalt IP-aadressist. Aga aadressi määramiseks kasutatakse endiselt mitte-ettevõtte DNS-i.

Probleem võib avalduda ka sel viisil - tööl on kõik korras, aga kodus pääsete ettevõtte ressurssidele ligi ainult IP kaudu. Seda seetõttu, et kui olete ühendatud ettevõtte WiFi-ga, kasutatakse ka ettevõtte DNS-i ja VPN-i sümboolsed aadressid lahendatakse selles, hoolimata asjaolust, et te ei pääse ikkagi sellisele aadressile juurde ilma VPN-i kasutamata.

Hosts-faili automaatne muutmine

Kui küsida vpn-slice'ilt viisakalt, saab see pärast VPN-i loomist minna oma DNS-i, leida vajalike ressursside IP-aadressid nende sümboolsete nimede järgi ja sisestada need hosts'i. Pärast VPN-i väljalülitamist kustutatakse need aadressid hosts'ist. Selleks tuleb vpn-slice'ile argumentidena sümboolsed nimed edastada. Näiteks 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 toimima nii kontoris kui ka rannas.

Otsi kõigi VPN-i antud DNS-i alamdomeenide aadresse

Kui võrgus on vähe aadresse, on hosts-faili automaatse muutmise lähenemisviis üsna toimiv. Aga kui võrgus on palju ressursse, peate skriptile pidevalt lisama ridu nagu zoidberg.test.evilcorp.com. Zoidberg on ühe testimisstendi nimi.

Aga nüüd, kui me natuke aru saame, mis on mis, saab selle vajaduse kõrvaldada.

Kui pärast VPN-i käivitamist vaadata faili /etc/hosts, on näha järgmine rida

192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOMAATSELT LOODUD

Ja resolv.conf faili lisati uus rida. Lühidalt, vpn-slice tegi kuidagi kindlaks, kus asub VPN-i DNS-server.

Nüüd peame selle nii tegema, et domeeninime IP-aadressi, mis lõpeb evilcorp.com-iga, teadasaamiseks läheb Linux ettevõtte DNS-i ja kui on vaja midagi muud, siis vaikeseadesse.

Guugeldasin tükk aega ja avastasin, et selline funktsionaalsus on Ubuntus kohe olemas. See tähendab võimalust kasutada nimede lahendamiseks kohalikku DNS-serverit dnsmasq.

See tähendab, et on võimalik teha nii, et Linux otsib IP-aadresse alati kohalikust DNS-serverist, mis omakorda, olenevalt domeeninimest, otsib IP-aadressi vastavalt väliselt DNS-serverilt.

Ubuntu kasutab NetworkManagerit kõige võrkude ja võrguühendustega seonduva haldamiseks ning graafiline liides näiteks WiFi-ühenduse valimiseks on vaid selle esiots.

Peame selle konfiguratsiooniga nokitsema.

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

aadress=/.evilcorp.com/192.168.430.534

Pane tähele punkti enne sõna "evilcorp". See annab dnsmasq-ile märku, et ettevõtte DNS-is tuleks otsida kõiki evilcorp.com alamdomeene.

1. Paluge NetworkManageril nimede lahendamiseks kasutada dnsmasq-i

Võrguhalduri konfiguratsioon asub failis /etc/NetworkManager/NetworkManager.conf. Sinna tuleb lisada:

[peamine]
dns=dnsmasq

1. Taaskäivita NetworkManager

service network-manager restart

Nüüd, pärast VPN-iga ühenduse loomist openconnecti ja vpn-slice'i kombinatsiooni abil, määratakse IP-aadress tavapäraselt, isegi kui te ei lisa vpnslice'i argumentidele sümboolseid aadresse.

Kuidas VPN-i kaudu üksikutele teenustele juurde pääseda

Pärast seda, kui mul õnnestus VPN-iga ühenduda, olin kaks päeva väga õnnelik, aga siis selgus, et kui VPN-iga ühenduda väljastpoolt kontorivõrku, siis e-post ei tööta. Tuttav sümptom, kas pole?

Meie meil asub aadressil mail.publicevilcorp.com, mis tähendab, et see ei kuulu dnsmasq reegli alla ja meiliserveri aadressi otsitakse avaliku DNS-i kaudu.

Noh, kontor kasutab endiselt DNS-i, millel on see aadress. Ma arvasingi nii. Tegelikult, pärast rea lisamist dnsmasq-i

aadress=/mail.publicevilcorp.com/192.168.430.534

Olukord pole üldse muutunud. IP jäi samaks. Pidin tööle minema.

Ja hiljem, kui ma olukorda süvenesin ja probleemist veidi aru sain, ütles üks tark inimene mulle, kuidas seda lahendada. Oli vaja meiliserveriga ühendust luua mitte niisama, vaid VPN-i kaudu.

Ma kasutan vpn-slice'i, et minna VPN-i kaudu aadressidele, mis algavad numbritega 192.168.430. Ja meiliserveril on mitte ainult sümboolne aadress, mis ei ole evilcorpi alamdomeen, vaid ka IP-aadress, mis ei alga numbritega 192.168.430. Ja loomulikult ei lase see kedagi üldisest võrgust sisse.

Selleks, et Linux saaks VPN-i kaudu meiliserverisse minna, peate selle vpn-lõiku lisama. Oletame, et meiliaadress 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 

Skript VPN-i käivitamiseks ühe argumendiga

Muidugi pole see kõik eriti mugav. Jah, saate teksti faili salvestada ja käsitsi tippimise asemel konsooli kopeerida ja kleepida, kuid see pole ikkagi eriti meeldiv. Protsessi lihtsustamiseks võite käsu mähkida skripti, mis asub PATH-is. Ja siis peate sisestama ainult Google Authenticatorilt 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 paned skripti connect~evilcorp~ kausta, siis saad lihtsalt konsoolis kirjutada

connect_evil_corp 567987

Aga nüüd pean ma mingil põhjusel konsooli, kus openconnect töötab, ikkagi avatuna hoidma.

Käivita openconnect taustal

Õnneks hoolitsesid openconnecti autorid meie eest ja lisasid programmile spetsiaalse võtme -background, mis paneb programmi pärast käivitamist taustal töötama. Kui käivitate selle nii, saate 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 pole lihtsalt selge, kuhu logid lähevad. Me ei vaja logisid tegelikult, aga mine tea. openconnect saab need suunata syslogi, kus need salvestatakse puutumata ja turvaliselt. See on vajalik käsule --syslog võtme lisamiseks.

#!/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 selgubki, et openconnect töötab kuskil taustal ega sega kedagi, aga pole selge, kuidas seda peatada. See tähendab, et muidugi saab ps-i väljundit grep-iga filtreerida ja otsida protsessi, mille nimes on openconnect, aga see on kuidagi tüütu. Tänud autoritele, kes selle peale mõtlesid. OpenConnectil on võti —pid-file, millega saab OpenConnectile anda käsu kirjutada oma protsessi identifikaator 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 saate protsessi alati käsuga tappa

kill $(cat ~/vpn-pid)

Kui protsessi pole, siis "kill" kaebab, aga ei viska viga. Kui faili pole, siis ei juhtu ka midagi hullu, seega võid protsessi skripti esimesel real ohutult 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 saate arvuti sisse lülitada, konsooli avada ja käsu käivitada, edastades sellele Google Authenticatori koodi. Seejärel saate konsooli sulgeda.

Ilma vpn-lõiketa. Järelsõna asemel.

VPN-slice'ita elamise mõistmine osutus väga keeruliseks. Pidin palju lugema ja guugeldama. Õnneks, pärast nii palju aega probleemiga tegelemiseks, tundusid tehnilised käsiraamatud ja isegi "Man OpenConnect" põnevad romaanid.

Lõpuks sain teada, et vpn-slice, nagu ka natiivne skript, muudab marsruutimistabelit võrkude eraldamiseks.

Marsruutimise tabel

See on lihtsustatult öeldes tabel, mille esimeses veerus on kirjas, millise aadressiga peaks Linux alustama ja teises veerus, millise võrguadapteri kaudu sellel aadressil minna. Tegelikult on veerge rohkem, aga see ei muuda olemust.

Marsruutimistabeli vaatamiseks 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, kuhu minna, et saata sõnum teatud aadressile. Esimene on kirjeldus, millega aadress peaks algama. Selleks, et mõista, kuidas teha kindlaks, et 192.168.0.0/16 tähendab, et aadress peaks algama 192.168-ga, peate Google'ist otsima, mis on IP-aadressi mask. Pärast dev-d on adapteri nimi, kuhu sõnum tuleks saata.

VPN-i jaoks lõi Linux virtuaalse adapteri – tun0. See liin vastutab selle eest, et liiklus kõikidele aadressidele, mis algavad numbriga 192.168, sellest läbi läheks.

192.168.0.0/16 dev tun0 scope link 

Marsruutimistabeli praegust olekut saate vaadata ka käsuga marsruut -n (IP-aadressid on oskuslikult anonümiseeritud) See käsk annab tulemusi teistsugusel kujul ja on üldiselt aegunud, kuid selle väljundit leiab sageli interneti käsiraamatutest ja teil peab olema võimalik seda lugeda.

Seda, millega marsruudi IP-aadress peaks algama, saab aru veergude Destination ja Genmask kombinatsioonist. Arvesse võetakse need IP-aadressi osad, mis vastavad Genmaskis numbritele 255, ja need, kus on 0, mitte. See tähendab, et Destination 192.168.0.0 ja Genmask 255.255.255.0 kombinatsioon tähendab, et kui aadress algab numbritega 192.168.0, siis sellele saadetud päring liigub mööda seda marsruuti. Ja kui Destination 192.168.0.0, aga Genmask 255.255.0.0, siis lähevad ka päringud aadressidele, mis algavad numbritega 192.168, mööda seda marsruuti.

Selleks, et aru saada, mida vpn-slice tegelikult teeb, otsustasin vaadata tabelite olekuid enne ja pärast

Enne VPN-i sisselülitamist oli see 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 kutsumist ilma vpn-slice'ita muutus see selliseks

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 tun0

Ja pärast openconnecti kutsumist koos vpn-slice'iga järgmiselt

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 tun0

On selge, et kui vpn-slice'i ei kasutata, siis openconnect kirjutab selgelt, et kõikidele aadressidele, välja arvatud eraldi määratud aadressidele, tuleb ligi pääseda vpn-i kaudu.

Siin see on:

0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 tun0

Selle kõrval on näidatud teine tee, mida tuleks kasutada, kui aadress, kuhu Linux üritab minna, ei vasta ühelegi tabelis olevale maskile.

0.0.0.0         222.222.222.1   0.0.0.0         UG    600    0        0 wlp3s0

Siin on juba kirjutatud, et sel juhul peate läbima tavalise WiFi-adapteri.

Ma eeldan, et VPN-rada kasutatakse, kuna see on marsruutimistabelis esimene.

Ja teoreetiliselt, kui eemaldate selle vaiketee marsruutimistabelist, peaks openconnect koos dnsmasq-iga tagama normaalse töö.

Ma proovisin

route del default

Ja kõik toimis.

Päringute suunamine meiliserverisse ilma vpn-slice'ita

Aga mul on ka meiliserver aadressil 555.555.555.555, millele tuleb samuti VPN-i kaudu ligi pääseda. Ka marsruut sinna tuleb käsitsi lisada.

ip route add 555.555.555.555 via dev tun0

Ja nüüd on kõik korras. Seega on võimalik ilma vpn-slice'ita hakkama saada, aga sa pead teadma, mida sa teed. Mõtlen nüüd sellele, et lisada natiivse openconnecti skripti viimasele reale vaikimisi marsruudi eemaldamine ja marsruudi lisamine meili saatjale pärast vpn-iga ühenduse loomist, lihtsalt selleks, et mu rattal oleks vähem liikuvaid osi.

Tõenäoliselt piisaks sellest järelsõnast, et keegi aru saaks, kuidas VPN-i seadistada. Aga kui ma üritasin aru saada, mida ja kuidas teha, lugesin päris palju selliseid käsiraamatuid, mis autori jaoks toimisid, aga mingil põhjusel minu jaoks mitte, ja otsustasin siia lisada kõik leitud osad. Oleksin millegi sellisega väga rahul.

Allikas: www.habr.com