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

Artiklis on palju liigset teavet, kuid ilma nendeta ei suudaks ma lahendada probleeme, mis mul VPN seadistamisel ootamatult tekkisid. Arvan, et igaühel, kes püüab seda juhendit rakendada, võivad tekkida probleemid, mida minul ei olnud, ning loodan, et see liigset teavet aitab neid probleeme iseseisvalt lahendada.

Enamiku juhendis kasutatavatest käskudest tuleb teostada sudo kaudu, mis on lühiduse huvides eemaldatud. Palun pidage seda meeles.

Enamik IP-aadresse on läbi teinud tugeva obfuskatsiooni, seega kui näete aadressi nagu 435.435.435.435 — seal peaks olema mingi normaalne IP, mis on spetsiifiline teie juhtumi jaoks.

Mul on Ubuntu 18.04, kuid arvan, et väikeste muudatustega saab juhendit rakendada ka teistele jaotustele. Siiski, selles tekstis tähendab Linux == Ubuntu.

Cisco Connect

Nendel, kes kasutavad Windowsi või MacOS-i, on võimalik meie ettevõtte VPN-i ühenduda läbi Cisco Connect, millele tuleb näidata gateway aadress ja igaühenduse korral sisestada parool, mis koosneb fikseeritud osast ja Google Authenticator'i genereeritud koodist.

Linuxi puhul ei õnnestunud mul Cisco Connect'i käivitada, kuid leidsin soovituse kasutada openconnect'i, mis on tehtud spetsiaalselt Cisco Connect'i asendamiseks.

Openconnect

Idee kohaselt peaks Ubuntu-s olema openconnect'i jaoks spetsiaalne graafiline liides, kuid mul see ei töötanud. Võib-olla on see isegi parem.

Ubuntu-s installitakse openconnect paketihalduri kaudu.

apt install openconnect

Vahetult pärast installimist võib proovida VPN-iga ühendada.

openconnect --user poxvuibr vpn.evilcorp.com

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

openconnect küsib parooli, mis koosneb fikseeritud osast ja Google Authenticatorist saadud koodist, ja proovib seejärel vpn-iga ühenduda. Kui see õnnestub, õnnitleme, võite julgelt vahele jätta vaheosa, kus on palju valu, ja minna punkti juurde, mis käsitleb openconnecti töötamist taustal. Kui ei õnnestunud, siis võib jätkata. Kuigi kui see õnnestus näiteks töökoha külalis-WiFist ühendudes, siis võib-olla on vara rõõmustada, tuleb proovida protseduuri kodust uuesti.

Sertifikaat

Suure tõenäosusega ei käivitu midagi ja openconnecti väljund näeb välja enam-vähem niimoodi:

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

VPN serverilt "vpn.evilcorp.com" saadud sertifikaadi verifitseerimine ebaõnnestus.
Põhjus: allkirjastajat ei leitud
Kuna usaldada seda serverit tulevikus, lisage sellele oma käsureale:
    --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Sisestage 'jah', et aktsepteerida, 'ei', et katkestada; midagi muud, et vaadata: fgets (stdin): Operatsioon käib.

Ühelt poolt on see ebameeldiv, kuna VPN-i ühendust ei toimunud, aga teiselt poolt on selles probleemi parandamise põhimõte selge.

Siin saatis server meile sertifikaadi, mille põhjal on võimalik määrata, et ühendus toimub tõeliselt oma korporatsiooni serveriga, mitte kurja petturiga, aga süsteemile pole see sertifikaat tundmatu. Ja seetõttu ei saa ta kontrollida, kas server on tõeline või mitte. Ja selle tõttu katkestab töö.

Selleks, et openconnect siiski serveriga ühenduks, tuleb talle selgelt öelda, milline sertifikaat peaks tulema VPN-serverilt kasutades võtme --servercert.

Ja et teada saada, millise sertifikaadi server meile saatis, saame seda otse openconnecti väljundist. Siit lausest:

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

Sellise käsuga võite proovida uuesti ühendust luua.

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

Võib-olla nüüd õnnestus, siis võib minna lõpuni. Aga isiklikult näitas mulle Ubuntu sellist sõrme.

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 resolvib, kuid sinna ei pääse. Aadresse nagu jira.evilcorp.com tegelikult üldse ei resolvita.

Mis seal juhtus, pole mulle selge. Kuid eksperiment näitab, et kui lisada /etc/resolv.conf rida

nameserver 192.168.430.534

siis adresse VPN-i sees hakkavad maagiliselt resolvima ja neid saab kasutada, st see, millest DNS adresse lahendamise korraldusi küsib, vaatab just /etc/resolv.conf-i, mitte kusagil mujal.

See, et VPN-iga on ühendus ja see töötab, on võimalik veenduda ka ilma muudatusteta /etc/resolv.conf-is, piisab, kui brauserisse sisestada mitte ressursi sümboolne nimi VPN-is, vaid selle IP-aadress.

Kokkuvõttes selgub kaks probleemi

VPN-i ühendamise ajal ei toimu DNS-i lahendamine
kogu liiklus läheb VPN-i kaudu, mis ei võimalda internetti pääseda

Mida teha, räägin nüüd, kuid kõigepealt natuke automatiseerimist.

Automaatne fikseeritud parooli osa sisestamine

Seni olete tõenäoliselt juba parooli sisestanud vähemalt viis korda ja see protseduur on teid juba kurnanud. Esiteks, kuna parool on pikk, teiseks, kuna sisestamisel peab ajavahemikku järgima.

Probleemi lõplik lahendus ei jõudnud artiklisse, kuid võib teha nii, et fikseeritud parooli osa ei pea korduvalt sisestama.

Oletame, et fikseeritud parooli osa on fixedPassword, ja Google Authenticatori osa 567 987. Kogu parooli openconnect saab edastada standardse sisendiga argumendi abil —passwd-on-stdin.

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

Nüüd saab pidevalt tagasi viimasele sisestatud käsule ja muuta seal ainult Google Authenticatori osa.

Ettevõtte VPN ei luba internetti pääseda.

Tegelikult on see üsna ebamugav, kui habrisse minekuks tuleb kasutada eraldi arvutit. Kopeerimise ja kleepimise puudumine stackoverfow-st võib tõeliselt töö halvatuks muuta, seega tuleb midagi ette võtta.

Peab korraldada nii, et kui on vaja pääseda ressursile sisevõrgust, siis Linux kasutab VPN-i ja kui on vaja pääseda Habrist — siis läheks internetti.

Openconnect käivitamisel ja VPN-iga ühenduse loomisel täidab see spetsiaalse skripti, mis asub /usr/share/vpnc-scripts/vpnc-script. Skript saab sisendiks mitmed muutujad ja teeb VPN-i seadistuse. Kahjuks ei suutnud ma aru saada, kuidas jagada liiklust ettevõtte VPN-i ja ülejäänud interneti vahel originaalskripti abil.

Ilmselt on spetsiaalselt sellistele nagu mina välja töötatud utiliit vpn-slice, mis võimaldab suunata liiklust kahe kanali vahel ilma tantsudeta. Noh, tantsida tuleb, aga šamaaniks olema ei pea.

Liikluse jagamine vpn-slice abil

Esiteks tuleb vpn-slice paigaldada, selle üle tuleb ise aru saada. Kui kommentaarides on küsimusi, kirjutan selle kohta eraldi postituse. Kuid see on tavaline programm Pythonis, nii et keerukusi ei tohiks olla. Paigaldasin selle virtualenv abil.

Ja edaspidi tuleb utiliiti rakendada, kasutades põhiseadet —script, märkides openconnect, mida tuleb kasutada vpn-slice'i asemel.

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

—script antakse string käsk, mida tuleb kutsuda skripti asemel. .\/bin\/vpn-slice — tee täidetava faili vpn-slice juurde 192.168.430.0\/24 — aadresside mask, mida tuleb VPN-i kaudu minna. Siin mõistetakse, et kui aadress algab 192.168.430 — siis tuleb selle aadressiga ressurssi otsida VPN-i seest.

Nüüd peaks olukord olema peaaegu normaalne. Peaaegu. Nüüd saab minna Habri ja sisevõrgu ressursile IP kaudu, kuid ei saa minna sisevõrgu ressursile sümboolsest nimest. Kui kirjutada vastavus sümboolse nime ja aadressi kohta hosts — peaks kõik töötama. Ja tööle jääma seni, kuni IP ei muutu. Linux suudab nüüd minna internetti või sisevõrku sõltuvalt IP-st. Kuid aadressi määramiseks kasutatakse endiselt mitteettevõttelist DNS-i.

Probleem võib samuti ilmneda selliselt – kontoris on kõik korras, aga kodus pääseb ettevõtte sisemistele ressurssidele sisse ainult IP-aadressi kaudu. See on nii, sest kui oled ühendatud ettevõtte Wi-Fi-ga, kasutatakse DNS-i, mis on samuti ettevõttele omane, ja seal lahendatakse VPN-i sümboolsed aadressid, ehkki nendele aadressidele ei pääse ilma VPN-ita juurde.

Faili hosts automaatne modifikatsioon

Kui vpn-slice'ilt viisakalt paluda, võib see pärast VPN-i ülesseadmist külastada selle DNS-i, leida seal vajadusel ressursside sümboolsed nimed ja kirjutada nende IP-aadressid hosts-faili. VPN-i väljalülitamisel eemaldatakse need aadressid hosts-failist. Selleks tuleb sümboolsed nimed vpn-slice'ile argumendina 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 töötama nii kontoris kui ka rannas.

Otsige DNS-i, mille andis VPN, kõigi alamdomeenide aadresse.

Kui aadresse sisese võrgu sees on vähe, siis lähenemine failide hosts automaatse modifikatsiooni kaudu on täiesti toimiv. Kuid kui ressursse on võrgus palju, siis peate pidevalt lisama skripti ridu, nagu zoidberg.test.evilcorp.com - zoidberg on üks testimise platvorme.

Aga nüüd, kui me saame veidi aru, mida see kõik endast kujutab, on seda vajadust võimalik vältida.

Kui pärast VPN-i seadistamist vaadata /etc/hosts, võib seal näha järgmist rida.

192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED

Ja resolv.conf-i lisati uus rida. Ühesõnaga, vpn-slice leidis kuidagi, kus asub VPN-i DNS-server.

Nüüd tuleb teha nii, et Linux uuriks IP-aadressi, mis lõppeb evilcorp.com, ettevõtte DNS-ist, ja kui vaja midagi muud, siis vaikimisi.

Ma otsisin üsna kaua ja avastasin, et selline funktsionaalsus on Ubuntu's vaikimisi olemas. Silmas peetakse võimalust kasutada nime lahendamiseks kohaliku DNS-serveri dnsmasq.

See tähendab, et Linux käib alati IP-aadresside järgi kohaliku DNS-serveri poole, mis omakorda otsib vastavalt domeeninimele IP-aadresse vastaval välisel DNS-serveril.

Ubuntu's NetworkManager is used to manage everything related to networks and network connections, and the graphical interface for selecting, for example, Wi-Fi connections is simply a front end to it.

We will need to explore its configurations.

Create a file in /etc/NetworkManager/dnsmasq.d/evilcorp

address=/.evilcorp.com/192.168.430.534

Note the dot before evilcorp. It signals to dnsmasq that all subdomains of evilcorp.com should be resolved using the corporate DNS.

Tell NetworkManager to use dnsmasq for name resolution.

The network-manager configuration is located at /etc/NetworkManager/NetworkManager.conf. We need to add the following:

[main]
dns=dnsmasq

Restart NetworkManager.

service network-manager restart

Now, after connecting to VPN using the openconnect and vpn-slice bundle, the IP will be properly identified, even if symbolic addresses are not added to the vpnslice arguments.

How to access separate services over VPN

After successfully connecting to the VPN, I was very happy for a couple of days, but then I found out that if I connect to the VPN not from the office network, email doesn’t work. The symptom is familiar, isn’t it?

Our email is located at mail.publicevilcorp.com, which means it doesn't fall under the rule in dnsmasq, and the address of the mail server is searched through public DNS.

But in the office, DNS is still used, which has this address. That’s what I thought. In reality, after adding the line in dnsmasq,

address=/mail.publicevilcorp.com/192.168.430.534

the situation didn't change at all. The IP remained the same. I had to go to work.

Only later, when I delved into the situation and figured out the problem a bit, a smart person told me how to resolve it. It was necessary to connect to the mail server not just directly, but through VPN.

I use vpn-slice to go through the VPN for addresses that start with 192.168.430. The mail server not only has a symbolic address that's not a subdomain of evilcorp, but it also has an IP address that doesn't start with 192.168.430. And of course, it doesn’t allow anyone in from the general network.

To ensure Linux can access the mail server through VPN, it needs to be added to vpn-slice as well. Suppose the address of the mail server is 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

Script to establish VPN with a single argument.

Kõik see pole muidugi väga mugav. Jah, tekst võib salvestada faili ja kleepida konsooli ning mitte käsitsi sisestada, aga see pole siiski kuigi meeldiv. Protsessi lihtsustamiseks võib käsu panna skripti, mis asub PATH-is. Ja siis tuleb vaid sisestada Google Authenticatorist saadud kood.

#!/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 panna skript connect~evilcorp~ kausta, siis võib lihtsalt konsoolis kirjutada.

connect_evil_corp 567987

Aga nüüd tuleb konsool, kus openconnect töötab, ikkagi mingil põhjusel lahti hoida.

Openconnecti taustal käivitamine.

Käesolevalt on openconnect autorid meie jaoks hoolitsenud ja lisanud programmi spetsiaalse võtme —background, mis teeb nii, et programm töötab pärast käivitamist taustal. Kui käivitada seda nii, siis võib pärast käivitamist konsooli 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 aga arusaamatu, kuhu logid lähevad. Logid pole meile tingimata vajalikud, aga kes teab. Openconnect võib suunata need syslogi, kus need saavad olla tervena ja turvaliselt. Selle jaoks tuleb käsklusse lisada võti —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 juhtub, et openconnect töötab kuskil taustal ja ei sega kedagi, aga kuidas seda peatada, ei ole arusaadav. Loomulikult võib ps väljundit filtreerida ja otsida protsessi, mille nimi sisaldab openconnecti, aga see on kuidagi tülikas. Aitäh autoritele, kes sellele samuti mõtlesid. Openconnectil on võtme —pid-file, millega saab nõustada openconnectit oma protsessi ID faili kirjutama.

#!/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 kurjustab, aga viga ei viska. Kui faili pole, siis samuti ei juhtu midagi hullu, seega võib julgelt protsessi esimeses skripti real lõpetada.

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 saab arvuti sisse lülitada, avada konsooli ja käivitada käsk, edastades sellele Google Authenticatorist saadud koodi. Konsooli võib siis lõpetada.

Ilma vpn-sliceta. Järelsõnana.

Mõista, kuidas elada ilma vpn-sliceta, osutus väga keeruliseks. Pidin palju lugema ja googeldama. Õnneks, kui palju aega probleemiga veetsin, loetakse tehnilised juhised ja isegi man openconnect nagu põnevaid romaane.

Lõpuks selgitasin välja, et vpn-slice, nagu ka kohandatud skript, muudab võrgud jagades marsruudingu tabelit.

Marsruudingu tabel

Seda võib lihtsustatult defineerida kui tabelit, mille esimeses veerus on aadressi algus, mille kaudu Linux soovib minna, ja teises, millise võrguadapteri kaudu seda aadressi järgida. Tegelikult on veerge rohkem, kuid see ei muuda asja olemust.

Marsruudingu tabeli vaatamiseks tuleb käivitada käsk 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, millest aadress algama peab. Selleks, et mõista, kuidas määrata, et 192.168.0.0/16 tähendab, et aadress peab algama 192.168-iga, tuleb googeldada, mis on IP-aadressi mask. Pärast dev asub adapteri nimi, kuhu sõnum saata.

VPN-i jaoks lõi Linux virtuaalse adapteri - tun0. Rida, mis tagab, et kõik aadressid, mis algavad 192.168, lähevad selle kaudu, on

192.168.0.0/16 dev tun0 scope link

Samuti saab marsruudingu tabeli hetkeseisu vaadata käsuga route -n (IP-aadressid on oskuslikult anonüümsed) See käsk tagastab tulemusi teises vormingus ja on üldiselt aegunud, kuid selle väljundit kohtab sageli juhendites ja tuleb osata seda lugeda.

IP-aadressi algust marsruudi jaoks saab mõista veergude Destination ja Genmask kombinatsioonist. Need IP-aadressi osad, mille Genmaskis on numbrid 255, arvestatakse, ja need, kus on 0 - ei arvestata. Seega kombinatsioon Destination 192.168.0.0 ja Genmask 255.255.255.0 tähendab, et kui aadress algab 192.168.0, siis läheb päring sellele marsruudile. Kui aga Destination on 192.168.0.0 ja Genmask 255.255.0.0, siis selle marsruudi kaudu lähevad päringud aadressidele, mis algavad 192.168.

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

Enne VPN-i sisselülitamist oli see nii

route -n 

Kernel IP marsruudi tabel
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-slice'ita nägi see välja nii

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 openconnect'i ja vpn-slice'i kutset on see nii

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 näha, et kui vpn-slice'i ei kasutata, siis openconnect ütleb selgelt, et kõik aadressid, välja arvatud eraldi määratud, tuleb läbida 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 märgitud veel üks tee, mida tuleb kasutada, kui aadress, millega Linux üritab minna, ei vasta ühele maskile tabelis.

0.0.0.0         222.222.222.1   0.0.0.0         UG    600    0        0 wlp3s0

Siin on juba kirjutatud, et sellisel juhul tuleb minna läbi tavandard WiFi.

Ma arvan, et VPN-i teed kasutatakse, kuna see on marsruuditabelis esimene.

Teoreetiliselt, kui see vaikimisi tee marsruuditabelist eemaldada, siis koos dnsmasq'iga peaks openconnect tagama normaalse töö.

Ma proovisin

route del default

Ja kõik töötas.

Küsimuste marsruutimine postiserverisse ilma vpn-slice'ita

Aga mul on veel postiserver aadressiga 555.555.555.555, millele peab samuti minema VPN kaudu. Marsruut sinna tuleb ka käsitsi lisada.

ip route add 555.555.555.555 via dev tun0

Ja nüüd on kõik normaalne. Nii et vpn-slice'ita on tõesti võimalik hakkama saada, aga juba peab hästi teadma, mida teed. Ma mõtlen praegu, et kas lisada viimasesse openconnect'i skripti vaikimisi marsruudi eemaldamine ja postiserveri marsruudi lisamine pärast VPN-iga ühendamist, lihtsalt et mu jalgrattal oleksid liikuvad osad vähem.

Võib-olla piisaks kellelegi, et mõista, kuidas VPN-i seadistada, sellest järelmärkusest. Kuid mina, samal ajal püüdes aru saada, mida ja kuidas teha, lugesin üsna palju selliseid juhendeid, mis töötavad autori jaoks, kuid mingil põhjusel mitte minu jaoks, ja otsustasin siia lisada kõik leitud tükikesed. Ma oleksin sellistest asjadest väga rõõmus olnud.

Allikas: habr.com