Ettevõtte VPN-iga ühenduse loomine Linuxis, kasutades openconnecti ja vpn-slice'i

Kas soovite Linuxit tööl kasutada, kuid teie ettevõtte VPN ei luba teil seda teha? Siis võib see artikkel aidata, kuigi see pole kindel. Etteruttavalt hoiatan, et ma ei saa võrguhaldusküsimustest hästi aru, mistõttu on võimalik, et tegin kõike valesti. Teisest küljest on võimalik, et saan juhendi kirjutada nii, et see oleks tavainimestele arusaadav, seega soovitan teil seda proovida.

Artikkel sisaldab palju mittevajalikku teavet, kuid ilma selle teadmiseta poleks ma suutnud lahendada VPN-i seadistamisel ootamatult ilmnenud probleeme. Arvan, et kõigil, kes proovivad seda juhendit kasutada, on probleeme, mida minul ei olnud, ja ma loodan, et see lisateave aitab neid probleeme iseseisvalt lahendada.

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

Enamik IP-aadresse on tõsiselt hägustatud, nii et kui näete sellist aadressi nagu 435.435.435.435, peab seal olema tavaline teie juhtumile vastav IP.

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

Cisco Connect

Need, kes kasutavad Windowsi või MacOS-i, saavad meie ettevõtte VPN-iga ühenduse luua Cisco Connecti kaudu, mis peab määrama lüüsi aadressi ja iga kord ühenduse loomisel sisestama parooli, mis koosneb fikseeritud osast ja Google Authenticatori loodud koodist.

Linuxi puhul ei saanud ma Cisco Connecti tööle panna, kuid mul õnnestus googeldada spetsiaalselt Cisco Connecti asendamiseks tehtud openconnecti kasutamise soovitus.

Ava ühendus

Teoreetiliselt on Ubuntul spetsiaalne graafiline liides avatud ühenduse jaoks, kuid see ei töötanud minu jaoks. Võib-olla on see paremuse poole.

Ubuntu puhul installitakse openconnect paketihaldurist.

apt install openconnect

Kohe pärast installimist võite proovida VPN-iga ühenduse luua

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 meelde, koosneb fikseeritud osast ja Google Authenticatori koodist, ning seejärel proovib VPN-iga ühendust luua. Kui see töötab, palju õnne, võite keskkoha, mis on palju valus, ohutult vahele jätta ja liikuda edasi teema juurde, mis puudutab taustal töötavat openconnecti. Kui see ei tööta, võite jätkata. Kuigi kui see töötas näiteks tööl külalis-Wi-Fi kaudu ühenduse loomisel, siis võib olla liiga vara rõõmustada; peaksite proovima protseduuri kodust korrata.

Tunnistus

Suure tõenäosusega 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

Ühest küljest on see ebameeldiv, sest VPN-iga ühendust polnud, kuid teisest küljest on selle probleemi lahendamise viis põhimõtteliselt selge.

Siin saatis server meile sertifikaadi, mille järgi saame kindlaks teha, et ühendus luuakse meie koduettevõtte serveriga, mitte kurja petturiga ja see sertifikaat on süsteemile tundmatu. Seetõttu ei saa ta kontrollida, kas server on tõeline või mitte. Ja nii igaks juhuks lakkab see töötamast.

Openconnecti serveriga ühenduse loomiseks peate talle selgesõnaliselt ütlema, milline sertifikaat peaks VPN-serverist tulema, kasutades klahvi —servercert

Ja saad teada, millise sertifikaadi server meile otse välja prinditud openconnectist välja saatis. Siin on sellest tükist:

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 proovida uuesti ühendust luua

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

Võib-olla nüüd see töötab, siis võite liikuda lõpuni. Kuid isiklikult näitas Ubunta mulle sellisel kujul viigimarja

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 lahendab, kuid te ei saa sinna minna. Aadresse nagu jira.evilcorp.com ei lahendata üldse.

Mis siin juhtus, pole mulle selge. Kuid katse näitab, et kui lisate rea faili /etc/resolv.conf

nameserver 192.168.430.534

siis hakkavad VPN-is olevad aadressid võluväel lahenema ja saate neist läbi astuda, st see, mida DNS aadresside lahendamiseks otsib, näeb välja konkreetselt failis /etc/resolv.conf, mitte kuskil mujal.

Saate kontrollida, kas VPN-iga on ühendus olemas ja see töötab ilma faili /etc/resolv.conf muutmata; selleks sisestage brauserisse mitte VPN-i ressursi sümboolne nimi, vaid selle IP-aadress

Selle tulemusena on kaks probleemi

  • VPN-iga ühenduse loomisel selle dns-i ei tuvastata
  • kogu liiklus käib VPN-i kaudu, mis ei võimalda juurdepääsu Internetile

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

Parooli fikseeritud osa automaatne sisestamine

Nüüdseks olete suure tõenäosusega juba vähemalt viis korda oma parooli sisestanud ja see protseduur on teid juba ära tüüdanud. Esiteks sellepärast, et parool on pikk ja teiseks sellepärast, et sisestamisel tuleb mahtuda kindlasse ajavahemikku

Probleemi lõplikku lahendust artiklisse ei lisatud, kuid võite veenduda, et parooli fikseeritud osa ei pea mitu korda sisestama.

Oletame, et parooli fikseeritud osa on fikseeritudPassword ja Google Authenticatori osa on 567 987. Kogu parooli saab standardsisendi kaudu edasi anda openconnectile, kasutades argumenti --passwd-on-stdin .

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

Nüüd saate pidevalt naasta viimati sisestatud käsu juurde ja muuta seal ainult osa Google Authenticatorist.

Ettevõtte VPN ei võimalda teil Internetis surfata.

Üldiselt pole see eriti ebamugav, kui peate Habrisse minekuks kasutama eraldi arvutit. Suutmatus stackoverfow'st kopeerida ja kleepida võib üldiselt töö halvata, seega tuleb midagi ette võtta.

Peame selle kuidagi korraldama nii, et kui teil on vaja sisevõrgust ressurssi juurde pääseda, läheb Linux VPN-i ja kui peate minema Habri, siis Internetti.

openconnect käivitab pärast käivitamist ja vpn-ga ühenduse loomist spetsiaalse skripti, mis asub /usr/share/vpnc-scripts/vpnc-script. Mõned muutujad edastatakse skriptile sisendina ja see konfigureerib VPN-i. Kahjuks ei saanud ma aru, kuidas jagada liiklusvooge ettevõtte VPN-i ja ülejäänud Interneti vahel, kasutades natiivset skripti.

Ilmselt töötati spetsiaalselt minusuguste jaoks välja utiliit vpn-slice, mis võimaldab saata liiklust kahe kanali kaudu ilma tamburiiniga tantsimata. Noh, see tähendab, et sa pead tantsima, aga sa ei pea olema šamaan.

Liikluse eraldamine vpn-slice'i abil

Esiteks peate installima vpn-slice'i, selle peate ise välja mõtlema. Kui kommentaarides on küsimusi, siis kirjutan selle kohta eraldi postituse. Kuid see on tavaline Pythoni programm, nii et raskusi ei tohiks tekkida. Installisin kasutades virtualenv.

Ja seejärel tuleb utiliit rakendada, kasutades lülitit -script, mis näitab ühenduse avamiseks, et standardse skripti asemel peate kasutama 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 

--script edastatakse string käsuga, mis tuleb skripti asemel välja kutsuda. ./bin/vpn-slice – vpn-slice käivitatava faili tee 192.168.430.0/24 – vpn-is minevate aadresside mask. Siin peame silmas seda, et kui aadress algab numbriga 192.168.430, siis tuleb selle aadressiga ressurssi otsida VPN-ist

Nüüd peaks olukord olema peaaegu normaalne. Peaaegu. Nüüd saate minna Habrisse ja ettevõttesisesesse ressurssi saate minna ip-ga, kuid te ei saa minna ettevõttesisesesse ressurssi sümboolse nimega. Kui määrate hostides sümboolse nime ja aadressi vaste, peaks kõik toimima. Ja tööta, kuni ip muutub. Olenevalt IP-st pääseb Linux nüüd Internetti või sisevõrku. Kuid aadressi määramiseks kasutatakse endiselt ettevõttevälist DNS-i.

Probleem võib avalduda ka sellisel kujul – tööl on kõik hästi, aga kodus pääsed ligi ainult ettevõtte sisemistele ressurssidele IP kaudu. Selle põhjuseks on asjaolu, et ettevõtte Wi-Fi-ga ühenduse loomisel kasutatakse ka ettevõtte DNS-i ja selles lahendatakse VPN-i sümboolsed aadressid, hoolimata asjaolust, et ilma VPN-i kasutamata on sellisele aadressile siiski võimatu minna.

Hostifaili automaatne muutmine

Kui vpn-slice'i viisakalt küsida, siis pärast VPN-i tõstmist saab see minna oma DNS-i, leida sealt sümboolsete nimede järgi vajalike ressursside IP-aadressid ja sisestada need hostidesse. Pärast VPN-i väljalülitamist eemaldatakse need aadressid hostidest. Selleks tuleb vpn-slice'ile argumentidena anda sümboolsed nimed. Nagu 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.

Otsige VPN-i antud DNS-ist kõigi alamdomeenide aadresse

Kui võrgus on vähe aadresse, töötab hostifaili automaatne muutmine üsna hästi. Kuid kui võrgus on palju ressursse, peate pidevalt lisama ridu nagu zoidberg.test.evilcorp.com. Zoidberg on ühe katsestendi nimi.

Aga nüüd, kui me natukene mõistame, miks seda vajadust saab kõrvaldada.

Kui pärast VPN-i tõstmist vaatate faili /etc/hosts, näete seda rida

192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOMAATNE LOOD

Ja faili resolv.conf lisati uus rida. Lühidalt, vpn-slice määras kuidagi kindlaks, kus vpn-i dns-server asub.

Nüüd peame veenduma, et evilcorp.com-iga lõppeva domeeninime IP-aadressi väljaselgitamiseks läheb Linux ettevõtte DNS-i ja kui on vaja midagi muud, siis vaikimisi.

Googeldasin päris tükk aega ja leidsin, et Ubuntus on selline funktsionaalsus karbist väljas saadaval. See tähendab võimalust kasutada nimede lahendamiseks kohalikku DNS-serverit dnsmasq.

See tähendab, et saate veenduda, et Linux läheb IP-aadresside otsimiseks alati kohalikku DNS-serverisse, mis omakorda, sõltuvalt domeeninimest, otsib IP-d vastava välise DNS-serveri kaudu.

Kõige võrkude ja võrguühendustega seonduva haldamiseks kasutab Ubuntu NetworkManagerit ning graafiline liides näiteks Wi-Fi ühenduste valimiseks on vaid selle esiots.

Peame selle konfiguratsioonis ronima.

  1. Looge fail kaustas /etc/NetworkManager/dnsmasq.d/evilcorp

address=/.evilcorp.com/192.168.430.534

Pöörake tähelepanu evilcorpi ees olevale punktile. See annab dnsmasq-ile märku, et kõiki saidi evilcorp.com alamdomeene tuleks otsida ettevõtte DNS-ist.

  1. Öelge NetworkManagerile, et ta kasutaks nimede lahendamiseks dnsmasqi

Võrguhalduri konfiguratsioon asub failis /etc/NetworkManager/NetworkManager.conf Peate sinna lisama:

[main] dns=dnsmasq

  1. Taaskäivitage NetworkManager

service network-manager restart

Nüüd, pärast VPN-iga ühenduse loomist openconnecti ja vpn-slice'i abil, määratakse IP tavaliselt, 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 ühendus luua, olin kaks päeva väga õnnelik ja siis selgus, et kui ühendan VPN-iga väljaspool kontorivõrku, siis post ei tööta. Sümptom on tuttav, kas pole?

Meie kirjad asuvad saidil mail.publicevilcorp.com, mis tähendab, et see ei kuulu dnsmasqi reegli alla ja meiliserveri aadressi otsitakse avaliku DNS-i kaudu.

Noh, kontor kasutab endiselt DNS-i, mis sisaldab seda aadressi. Seda ma arvasin. Tegelikult pärast rea lisamist dnsmasq

address=/mail.publicevilcorp.com/192.168.430.534

olukord pole sugugi muutunud. ip jäi samaks. Ma pidin tööle minema.

Ja alles hiljem, kui ma olukorda süvenesin ja probleemist natukenegi aru sain, rääkis üks tark inimene, kuidas seda lahendada. Meiliserveriga oli vaja ühenduda mitte niisama, vaid VPN-i kaudu

Kasutan VPN-i läbimiseks vpn-slice'i aadressidele, mis algavad numbriga 192.168.430. Ja meiliserveril pole mitte ainult sümboolset aadressi, mis ei ole evilcorpi alamdomeen, vaid sellel pole ka IP-aadressi, mis algab numbriga 192.168.430. Ja loomulikult ei luba ta kellelgi üldvõrgust enda juurde tulla.

Selleks, et Linux läheks läbi VPN-i ja meiliserverisse, peate selle lisama ka vpn-slice'i. Oletame, et postitaja 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 

Skript VPN-i tõstmiseks ühe argumendiga

Kõik see pole muidugi eriti mugav. Jah, saate käsitsi teksti sisestamise asemel teksti faili salvestada ja konsooli kopeerida-kleepida, kuid see pole siiski väga meeldiv. Protsessi hõlbustamiseks saate käsu mähkida skripti, mis asub teekonnas PATH. Ja siis peate 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 panete skripti kausta connect~evilcorp~, saate lihtsalt konsooli kirjutada

connect_evil_corp 567987

Nüüd aga tuleb konsooli, milles openconnect töötab, millegipärast lahti hoida

Openconnecti käivitamine taustal

Õnneks võtsid openconnecti autorid meie eest hoolt ja lisasid programmi -taustale spetsiaalse võtme, mis paneb programmi peale käivitamist taustal tööle. Kui käivitate selle nii, saate 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 pole lihtsalt selge, kuhu palgid lähevad. Üldiselt me ​​palke tegelikult ei vaja, aga kunagi ei tea. openconnect saab need ümber suunata syslogi, kus neid hoitakse turvaliselt. peate käsule lisama lüliti –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 selgub, et openconnect töötab kuskil taustal ega häiri kedagi, kuid pole selge, kuidas seda peatada. See tähendab, et saate ps-väljundit loomulikult grep-i abil filtreerida ja otsida protsessi, mille nimi sisaldab openconnect, kuid see on kuidagi tüütu. Aitäh ka autoritele, kes selle peale mõtlesid. Openconnectil on võti -pid-fail, mille abil saate anda openconnectile käsu oma protsessi identifikaatorit faili kirjutada.

#!/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 käsuga protsessi alati tappa

kill $(cat ~/vpn-pid)

Kui protsessi pole, siis kill kirub, aga viga ei viska. Kui faili pole, siis ei juhtu ka midagi hullu, nii et saate skripti esimesel real protsessi 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, avada konsooli ja käivitada käsu, edastades sellele Google Authenticatori koodi. Seejärel saab konsooli naelutada.

Ilma VPN-lõiguta. Järelsõna asemel

Selgus, et väga raske on aru saada, kuidas elada ilma VPN-lõiguta. Pidin palju lugema ja googeldama. Õnneks loevad tehnilised juhendid ja isegi man openconnect pärast probleemiga nii palju aega veetmist põnevate romaanidena.

Selle tulemusena sain teada, et vpn-slice, nagu ka native skript, muudab marsruutimistabelit võrkude eraldamiseks.

Marsruutimistabel

Lihtsamalt öeldes on see tabel esimeses veerus, mis sisaldab aadressi, mida Linux soovib läbida, algama ja teises veerus, millist võrguadapterit sellel aadressil läbida. Tegelikult on kõlareid rohkem, kuid 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 peate mõnele aadressile sõnumi saatmiseks minema. Esimene on kirjeldus selle kohta, kust aadress peaks algama. Et aru saada, kuidas teha kindlaks, et 192.168.0.0/16 tähendab, et aadress peaks algama 192.168-ga, tuleb googeldada, mis on IP-aadressi mask. Pärast dev on selle adapteri nimi, millele sõnum tuleb saata.

VPN-i jaoks tegi Linux virtuaalse adapteri - tun0. Liin tagab, et kõigi 192.168-ga algavate aadresside liiklus läbib seda

192.168.0.0/16 dev tun0 scope link 

Samuti saate käsu abil vaadata marsruutimistabeli hetkeseisu marsruut -n (IP-aadressid muudetakse nutikalt anonüümseks) See käsk annab tulemusi teistsugusel kujul ja on üldiselt aegunud, kuid selle väljundit leidub sageli Internetis olevates juhendites ja teil peab olema võimalus seda lugeda.

Kust marsruudi IP-aadress peaks algama, saab aru veergude Destination ja Genmask kombinatsioonist. Arvesse lähevad need IP-aadressi osad, mis vastavad Genmaski numbritele 255, aga need, kus on 0, mitte. See tähendab, et kombinatsioon sihtkohast 192.168.0.0 ja Genmask 255.255.255.0 tähendab, et kui aadress algab numbriga 192.168.0, siis päring sellele edastatakse seda marsruuti mööda. Ja kui sihtkoht on 192.168.0.0, aga Genmask 255.255.0.0, siis päringud aadressidele, mis algavad numbriga 192.168, lähevad sellel marsruudil

Et välja selgitada, 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 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 ilma vpn-sliceta helistamist 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 helistamist koos sellise vpn-slicega

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 sa vpn-slice'i ei kasuta, siis openconnect kirjutab selgesõnaliselt, et kõikidele aadressidele, välja arvatud konkreetselt märgitud, tuleb pääseda vpn kaudu.

Siin samas:

0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 tun0

Seal kõrval on kohe näidatud teine ​​tee, mida tuleb kasutada juhul, kui aadress, mida Linux üritab läbida, 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 kirjas, et sel juhul tuleb kasutada tavalist Wi-Fi adapterit.

Usun, et VPN-i teed kasutatakse, kuna see on marsruutimistabelis esimene.

Ja teoreetiliselt, kui eemaldada see vaiketee marsruutimistabelist, peaks koos dnsmasq openconnectiga tagama normaalse töö.

ma proovisin

route del default

Ja kõik töötas.

Taotluste suunamine meiliserverisse ilma vpn-slice'ita

Aga mul on ka meiliserver aadressiga 555.555.555.555, millele tuleb samuti VPN kaudu ligi pääseda. Marsruut sinna juurde tuleb ka käsitsi lisada.

ip route add 555.555.555.555 via dev tun0

Ja nüüd on kõik hästi. Nii et saate ilma vpn-slice'ita hakkama, kuid peate hästi teadma, mida teete. Nüüd mõtlen sellele, et lisada natiivse openconnecti skripti viimasele reale vaikemarsruudi eemaldamine ja postitaja marsruudi lisamine pärast vpn-ga ühenduse loomist, et mu jalgrattas oleks vähem liikuvaid osi.

Tõenäoliselt piisaks sellest järelsõnast, et keegi saaks aru, kuidas VPN-i seadistada. Kuid samal ajal, kui ma üritasin aru saada, mida ja kuidas teha, lugesin ma päris palju selliseid juhendeid, mis autorile sobivad, aga minu jaoks millegipärast ei tööta, ja otsustasin siia lisada kõik leitud tükid. Mul oleks millegi sellise üle väga hea meel.

Allikas: www.habr.com

Lisa kommentaar