Vulete aduprà Linux à u travagliu, ma a vostra VPN corporativa ùn vi permette micca? Allora stu articulu pò aiutà, ancu s'ellu ùn hè micca sicuru. Vogliu avvistà in anticipu chì ùn aghju micca capitu bè i prublemi di amministrazione di a rete, cusì hè pussibule chì aghju fattu tuttu male. Per d 'altra banda, hè pussibile chì possu scrive una guida in tale manera chì serà cumprinsibile à a ghjente ordinaria, cusì vi cunsigliu di pruvà.
L'articulu cuntene assai infurmazioni innecessarii, ma senza questa cunniscenza ùn saria micca pussutu risolve i prublemi chì m'hà apparsu inaspettatamente cù a creazione di una VPN. Pensu chì qualcunu chì prova à aduprà sta guida avarà prublemi chì ùn aghju micca avutu, è speru chì sta infurmazione extra aiutarà à risolve questi prublemi per sè stessu.
A maiò parte di i cumandamenti utilizati in questa guida deve esse eseguitu via sudo, chì hè stata eliminata per brevità. Tenite in mente.
A maiò parte di l'indirizzi IP sò stati severamente offuscati, perchè se vede un indirizzu cum'è 435.435.435.435, ci deve esse qualchì IP normale, specificu à u vostru casu.
Aghju Ubuntu 18.04, ma pensu chì cù cambiamenti minori a guida pò esse applicata à altre distribuzioni. Tuttavia, in questu testu Linux == Ubuntu.
Cisco Connect
Quelli chì sò in Windows o MacOS ponu cunnette à a nostra VPN corporativa via Cisco Connect, chì deve specificà l'indirizzu di u gateway è, ogni volta chì vi cunnetta, inserite una password custituita da una parte fissa è un codice generatu da Google Authenticator.
In u casu di Linux, ùn pudia micca esse Cisco Connect in esecuzione, ma aghju riesciutu à google una raccomandazione per utilizà openconnect, fatta apposta per rimpiazzà Cisco Connect.
Openconnect
In teoria, Ubuntu hà una interfaccia gràfica speciale per openconnect, ma ùn hà micca travagliatu per mè. Forse hè per u megliu.
In Ubuntu, openconnect hè stallatu da u gestore di pacchetti.
apt install openconnectImmediatamente dopu a stallazione, pudete pruvà à cunnette à una VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com hè l'indirizzu di una VPN fittizia
poxvuibr - nome d'utilizatore fittizio
openconnect vi dumandu di inserisce una password, chì, lasciami ricurdà, hè custituita da una parte fissa è un codice da Google Authenticator, è dopu pruvà à cunnette à u VPN. Se funziona, felicitazioni, pudete saltà in modu sicuru u mediu, chì hè assai dulore, è passà à u puntu nantu à l'openconnect in sfondate. Se ùn viaghja micca, pudete cuntinuà. Ancu s'ellu hà travagliatu quandu a cunnessione, per esempiu, da un ospite Wi-Fi à u travagliu, allora pò esse troppu prestu per rallegra; duvete pruvà à ripetiri a prucedura da casa.
Certificatu
Ci hè una alta probabilità chì nunda ùn principiarà, è l'output openconnect serà simile à questu:
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 progressPer una banda, questu hè dispiacevule, perchè ùn ci era micca cunnessione cù a VPN, ma da l'altra banda, cumu per risolve stu prublema hè, in principiu, chjaru.
Quì u servitore ci hà mandatu un certificatu, da quale pudemu stabilisce chì a cunnessione hè stata fatta à u servitore di a nostra corporazione nativa, è micca à un scammer male, è questu certificatu hè scunnisciutu à u sistema. È dunque ùn pò micca verificà se u servitore hè reale o micca. È cusì, in casu, ferma di travaglià.
Per chì openconnect si cunnetta à u servitore, avete bisognu di dì esplicitamente quale certificatu deve vene da u servitore VPN utilizendu a chjave —servercert.
È pudete scopre quale certificatu u servitore ci hà mandatu direttamente da ciò chì openconnect stampatu. Eccu da questu pezzu:
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 progressCù stu cumandamentu pudete pruvà à cunnette torna
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comForsi avà hè travagliatu, allora pudete passà à a fine. Ma personalmente, Ubunta m'hà mostratu un ficu in questa forma
POST https://vpn.evilcorp.com/
Connected to 777.777.777.777:443
SSL negotiation with vpn.evilcorp.com
Server certificate verify failed: signer not found
Connected to HTTPS on vpn.evilcorp.com
XML POST enabled
Please enter your username and password.
POST https://vpn.evilcorp.com/
Got CONNECT response: HTTP/1.1 200 OK
CSTP connected. DPD 300, Keepalive 30
Set up DTLS failed; using SSL instead
Connected as 192.168.333.222, using SSL
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
RTNETLINK answers: File exists
/etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf/etc/resolv.conf
# Generated by NetworkManager
search gst.evilcorpguest.com
nameserver 127.0.0.53/run/resolvconf/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 192.168.430.534
nameserver 127.0.0.53
search evilcorp.com gst.publicevilcorp.comhabr.com risolverà, ma ùn puderete micca andà. Indirizzi cum'è jira.evilcorp.com ùn sò micca risolti in tuttu.
Ciò chì hè accadutu quì ùn hè micca chjaru per mè. Ma l'esperimentu mostra chì si aghjunghje a linea à /etc/resolv.conf
nameserver 192.168.430.534allora l'indirizzi in a VPN cumincianu à risolve magicamente è pudete marchjà per elli, vale à dì, ciò chì DNS cerca per risolve l'indirizzi si vede specificamente in /etc/resolv.conf, è micca in altrò.
Pudete verificà chì ci hè una cunnessione à a VPN è funziona senza fà cambiamenti à /etc/resolv.conf; per fà questu, basta inserisce in u navigatore micca u nome simbolicu di a risorsa da a VPN, ma u so indirizzu IP.
In u risultatu, ci sò dui prublemi
- Quandu si cunnette à una VPN, u so dns ùn hè micca pigliatu
- tuttu u trafficu passa per VPN, chì ùn permettenu micca accessu à Internet
Vi dicu ciò chì deve fà avà, ma prima un pocu automatizazione.
Ingressu automaticu di a parte fissa di a password
Avà, avete probabilmente digià inseritu a vostra password almenu cinque volte è sta prucedura hà digià stancu. Prima, perchè a password hè longa, è in segundu, perchè quandu entra, avete bisognu à adattà in un periodu di tempu fissu
A suluzione finale di u prublema ùn hè micca stata inclusa in l'articulu, ma pudete assicurà chì a parte fissa di a password ùn deve esse inserita parechje volte.
Diciamu chì a parte fissa di a password hè fixedPassword, è a parte di Google Authenticator hè 567 987. A password sana pò esse passata à openconnect via input standard usendu l'argumentu --passwd-on-stdin .
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinAvà pudete vultà constantemente à l'ultimu cumandamentu inseritu è cambià solu una parte di Google Authenticator.
Una VPN corporativa ùn vi permette micca di navigà in Internet.
In generale, ùn hè micca assai inconveniente quandu avete aduprà un urdinatore separatu per andà in Habr. L'incapacità di copià-incollà da stackoverfow pò generalmente paralizà u travagliu, cusì qualcosa deve esse fattu.
Avemu bisognu d'urganizà in modu chì quandu avete bisognu di accede à una risorsa da a reta interna, Linux va à a VPN, è quandu avete bisognu à Habr, anda in Internet.
openconnect, dopu avè lanciatu è stabilisce una cunnessione cù vpn, eseguisce un script speciale, chì si trova in /usr/share/vpnc-scripts/vpnc-script. Certi variàbili sò passati à u script cum'è input, è cunfigurà a VPN. Sfurtunatamente, ùn pudia capisce cumu si sparte u flussu di trafficu trà una VPN corporativa è u restu di l'Internet utilizendu un script nativu.
Apparentemente, l'utilità vpn-slice hè stata sviluppata in particulare per e persone cum'è mè, chì permette di mandà u trafficu per dui canali senza ballà cù un tamburinu. Ebbè, questu hè, avete da ballà, ma ùn avete micca esse un sciamanu.
Separazione di u trafficu cù vpn-slice
Prima, vi tuccherà à stallà vpn-slice, vi tuccherà à capisce stu fora voi stessu. Se ci sò dumande in i cumenti, scriveraghju un post separatu annantu à questu. Ma questu hè un prugramma Python regulare, cusì ùn deve esse micca difficultà. Aghju installatu cù virtualenv.
E poi l'utilità deve esse appiicata, utilizendu u switch -script, indicà per openconnect chì invece di l'script standard, avete bisognu di utilizà vpn-slice.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 " vpn.evilcorp.com --script hè passatu una stringa cù un cumandamentu chì deve esse chjamatu invece di u script. ./bin/vpn-slice - percorsu à u schedariu eseguibile vpn-slice 192.168.430.0/24 - maschera di indirizzi per andà in vpn. Quì, vulemu dì chì se l'indirizzu principia cù 192.168.430, allora a risorsa cù questu indirizzu deve esse cercata in a VPN.
Avà a situazione deve esse quasi normale. Quasi. Avà pudete andà à Habr è pudete andà à a risorsa intra-corporativa per ip, ma ùn pudete micca andà à a risorsa intra-corporativa per nome simbolicu. Se specificate un match trà u nome simbolicu è l'indirizzu in l'ospiti, tuttu deve travaglià. È travaglià finu à chì l'ip cambia. Linux pò avà accede à l'Internet o l'intranet, secondu l'IP. Ma u DNS non corporativu hè sempre usatu per determinà l'indirizzu.
U prublema pò ancu manifestà in questa forma - à u travagliu tuttu hè bè, ma in casa pudete accede solu risorse corporative internu via IP. Questu hè chì quandu site cunnessu à u Wi-Fi corporativu, u DNS corporativu hè ancu utilizatu, è l'indirizzi simbolichi da a VPN sò risolti in questu, malgradu u fattu chì hè sempre impussibile di andà à un tali indirizzu senza utilizà una VPN.
Mudificazione automatica di u schedariu hosts
Se vpn-slice hè dumandatu educatamente, dopu avè risuscitatu a VPN, pò andà à u so DNS, truvate quì l'indirizzi IP di i risorsi necessarii per i so nomi simbolichi è entre in l'ospiti. Dopu avè disattivatu a VPN, questi indirizzi seranu eliminati da l'ospiti. Per fà questu, avete bisognu di passà nomi simbolichi à vpn-slice cum'è argumenti. Cum'è què.
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 Avà tuttu deve travaglià in l'uffiziu è in a spiaggia.
Cerca l'indirizzi di tutti i subdominii in u DNS datu da a VPN
Se ci sò pochi indirizzi in a reta, allora l'approcciu di mudificà automaticamente u schedariu di l'ospiti funziona abbastanza bè. Ma s'ellu ci sò assai risorse nantu à a reta, allora avete sempre bisognu di aghjunghje linee cum'è zoidberg.test.evilcorp.com à u script zoidberg hè u nome di unu di i banchi di teste.
Ma avà chì avemu capitu un pocu perchè sta necessità pò esse eliminata.
Se, dopu avè risuscitatu a VPN, cercate in /etc/hosts, pudete vede sta linea
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATE
È una nova linea hè stata aghjuntu à resolv.conf. In corta, vpn-slice in qualchì modu determinatu induve u servitore dns per u vpn hè situatu.
Avà avemu bisognu di assicurà chì per sapè l'indirizzu IP di un nome di dominiu chì finiscinu in evilcorp.com, Linux va à u DNS corporativu, è se qualcosa altru hè necessariu, allora à u predeterminatu.
Aghju Googled per un bellu pezzu è aghju trovu chì una tale funziunalità hè dispunibule in Ubuntu fora di a scatula. Questu significa a capacità di utilizà u servitore DNS locale dnsmasq per risolve i nomi.
Questu hè, pudete assicurà chì Linux sempre vai à u servitore DNS locale per l'indirizzi IP, chì à u turnu, secondu u nome di duminiu, cercà l'IP in u servitore DNS esternu currispundente.
Per gestisce tuttu ciò chì tocca à e rete è e cunnessione di rete, Ubuntu usa NetworkManager, è l'interfaccia gràfica per selezziunà, per esempiu, e cunnessione Wi-Fi hè solu un front end per questu.
Avemu bisognu di cullà in a so cunfigurazione.
- Crea un schedariu in /etc/NetworkManager/dnsmasq.d/evilcorp
indirizzu =/.evilcorp.com/192.168.430.534
Prestate attenzione à u puntu davanti à evilcorp. Segnale dnsmasq chì tutti i subdominii di evilcorp.com deve esse cercati in u dns corporativu.
- Dì à NetworkManager di utilizà dnsmasq per a risoluzione di nomi
A cunfigurazione di u gestore di a rete si trova in /etc/NetworkManager/NetworkManager.conf Avete bisognu di aghjunghje quì:
[main] dns=dnsmasq
- Riavvia NetworkManager
service network-manager restartAvà, dopu a cunnessione à una VPN cù openconnect è vpn-slice, l'ip serà determinatu nurmale, ancu s'ellu ùn aghjunghje micca indirizzi simbolichi à l'argumenti à vpnslice.
Cumu accede à i servizii individuali via VPN
Dopu avè riisciutu à cunnette à a VPN, eru assai cuntentu per dui ghjorni, è dopu hè stata chì si cunnetta à a VPN da fora di a reta di l'uffiziu, u mail ùn funziona micca. U sintumu hè familiar, ùn hè micca?
U nostru mail hè situatu in mail.publicevilcorp.com, chì significa chì ùn hè micca sottumessu à a regula in dnsmasq è l'indirizzu di u servitore di mail hè cercatu per mezu di u DNS publicu.
Ebbè, l'uffiziu usa sempre DNS, chì cuntene stu indirizzu. Hè ciò chì aghju pensatu. In fatti, dopu aghjunghje a linea à dnsmasq
indirizzu =/mail.publicevilcorp.com/192.168.430.534
a situazione ùn hà micca cambiatu in tuttu. ip restava u listessu. Aviu avutu à andà à travaglià.
È solu dopu, quandu aghju sfondatu in a situazione è hà capitu u prublema un pocu, una persona intelligente m'hà dettu cumu risolve. Era necessariu di cunnette cù u servitore di mail micca solu cusì, ma attraversu VPN
Aduprà vpn-slice per passà a VPN à l'indirizzi chì cumincianu cù 192.168.430. È u servitore di mail ùn hè micca solu un indirizzu simbolicu chì ùn hè micca un subdomain di evilcorp, ùn hà ancu un indirizzu IP chì principia cù 192.168.430. È di sicuru ùn permette à nimu di a reta generale di vene à ellu.
Per chì Linux passa per a VPN è à u servitore di mail, avete bisognu di aghjunghje ancu à vpn-slice. Diciamu chì l'indirizzu di u mailer hè 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 Scrittura per crià VPN cun un argumentu
Tuttu chistu, sicuru, ùn hè micca assai còmuda. Iè, pudete salvà u testu in un schedariu è copià-incollà in a cunsola invece di scrive a manu, ma ùn hè micca assai piacevule. Per fà u prucessu più faciule, pudete imbulighjà u cumandamentu in un script chì serà situatu in PATH. È tandu vi tuccherà solu à entre u codice ricevutu da Google Authenticator
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com Se mette u script in connect~evilcorp~ pudete simpricimenti scrive in a cunsola
connect_evil_corp 567987Ma avà avete sempre à mantene a cunsola in quale openconnect funziona aperta per qualchì ragione
Running openconnect in fondo
Fortunatamente, l'autori di l'openconnect hà pigliatu cura di noi è aghjunghjenu una chjave speciale à u prugramma -background, chì face u travagliu di u prugramma in u fondu dopu u lanciu. Se l'eseguite cusì, pudete chjude a cunsola dopu u lanciu
#!/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 Avà ùn hè micca chjaru induve i logs vanu. In generale, ùn avemu micca veramente bisognu di logs, ma ùn sapete mai. openconnect pò reindirizzà à syslog, induve seranu guardati sicuru è sicuru. avete bisognu di aghjunghje u -syslog switch à u cumandimu
#!/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 È cusì, risulta chì l'openconnect travaglia in un locu in u sfondate è ùn disturba à nimu, ma ùn hè micca chjaru cumu si ferma. Questu hè, pudete, sicuru, filtrà l'output ps cù grep è cercate un prucessu chì u nome cuntene openconnect, ma questu hè in qualchì manera tediosa. Grazie à l'autori chì anu pensatu ancu à questu. Openconnect hà una chjave -pid-file, cù quale pudete urdinà à openconnect per scrive u so identificatore di prucessu à un schedariu.
#!/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-pidAvà pudete sempre tumbà un prucessu cù u cumandamentu
kill $(cat ~/vpn-pid)S'ellu ùn ci hè micca prucessu, uccisione maledicà, ma ùn lanciarà micca un errore. Se u schedariu ùn hè micca quì, allora ùn succede nunda di male, cusì pudete tumbà in modu sicuru u prucessu in a prima linea di u script.
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-pidAvà pudete accende u vostru urdinatore, apre a cunsola è eseguisce u cumandamentu, passendu u codice da Google Authenticator. A cunsola pò esse inchiodata.
Senza VPN-slice. Invece di una postfazione
Hè diventatu assai difficiule à capisce cumu campà senza VPN-slice. Aviu avutu à leghje è google assai. Fortunatamente, dopu avè passatu tantu tempu cù un prublema, i manuali tecnichi è ancu l'omu openconnect leghje cum'è rumanzi eccitanti.
In u risultatu, aghju scupertu chì vpn-slice, cum'è l'script nativu, mudifica a tabella di routing per separà e rete.
Tavola di routing
Per esse simplicemente, questu hè un tavulu in a prima colonna chì cuntene ciò chì l'indirizzu chì Linux vole passà per duverebbe principià, è in a seconda colonna chì adattatore di rete per passà à questu indirizzu. In fatti, ci sò più parlanti, ma questu ùn cambia micca l'essenza.
Per vede a tavola di routing, avete bisognu di eseguisce u cumandamentu di a route ip
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 Quì, ogni linea hè rispunsevuli di induve duvete andà per mandà un missaghju à qualchì indirizzu. U primu hè una descrizzione di induve l'indirizzu deve principià. Per capiscenu cumu per determinà chì 192.168.0.0/16 significa chì l'indirizzu deve principià cù 192.168, avete bisognu di Google ciò chì hè una maschera di indirizzu IP. Dopu à dev ci hè u nome di l'adattatore à quale u messagiu deve esse mandatu.
Per VPN, Linux hà fattu un adattatore virtuale - tun0. A linea assicura chì u trafficu per tutti l'indirizzi chì cumincianu cù 192.168 passa per ellu
192.168.0.0/16 dev tun0 scope link Pudete ancu vede u statu attuale di a tabella di routing usendu u cumandamentu percorsu -n (L'indirizzi IP sò abilmente anonimizati) Stu cumanda pruduce risultati in una forma diversa è hè generalmente deprecated, ma a so pruduzzioni hè spessu trovata in manuali in Internet è avete bisognu di pudè leghje.
Induve l'indirizzu IP per una strada deve principià pò esse capitu da a cumminazione di e colonne di Destinazione è Genmask. Quelli parti di l'indirizzu IP chì currispondenu à i numeri 255 in Genmask sò cunsiderati, ma quelli induve ci hè 0 ùn sò micca. Questu hè, a cumminazione di a Destinazione 192.168.0.0 è Genmask 255.255.255.0 significa chì se l'indirizzu principia cù 192.168.0, allora a dumanda à questu andà per sta strada. È se a Destinazione 192.168.0.0 ma Genmask 255.255.0.0, e dumande à l'indirizzi chì cumincianu cù 192.168 andaranu per questa strada.
Per capisce ciò chì vpn-slice faci veramente, aghju decisu di guardà i stati di e tavule prima è dopu.
Prima di accende a VPN era cusì
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 wlp3s0Dopu avè chjamatu openconnect senza vpn-slice hè diventatu cusì
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È dopu avè chjamatu openconnect in cumminazione cù vpn-slice cum'è questu
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 tun0Pò esse vistu chì, se ùn utilizate micca vpn-slice, allora openconnect scrive esplicitamente chì tutti l'indirizzi, eccettu quelli specificamente indicati, deve esse accessu via vpn.
Giustu quì:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Quì, accantu à questu, un altru percorsu hè subitu indicatu, chì deve esse usatu se l'indirizzu chì Linux prova di passà ùn currisponde à alcuna maschera da a tavula.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Hè digià scrittu quì chì in questu casu avete bisognu di utilizà un adattatore Wi-Fi standard.
Credu chì u percorsu VPN hè utilizatu perchè hè u primu in a tabella di routing.
E teoricamente, se sguassate stu percorsu predeterminatu da a tabella di routing, allora in cunjunzione cù dnsmasq openconnect deve assicurà u funziunamentu normale.
Aghju pruvatu
route del defaultÈ tuttu hà travagliatu.
Instradamentu di e dumande à un servitore di mail senza vpn-slice
Ma aghju ancu un servitore di mail cù l'indirizzu 555.555.555.555, chì deve ancu esse accessu via VPN. U percorsu à questu deve ancu esse aghjuntu manualmente.
ip route add 555.555.555.555 via dev tun0È avà tuttu hè bè. Allora pudete fà senza vpn-slice, ma avete bisognu di sapè bè ciò chì fate. Avà pensu à aghjunghje à l'ultima linea di u script openconnect nativu a rimuzione di a strada predeterminata è aghjunghje una strada per u mailer dopu a cunnessione à a VPN, solu per chì ci sò menu parti in muvimentu in a mo bicicletta.
Probabilmente, questa postfazione seria abbastanza per qualcunu per capisce cumu fà una VPN. Ma mentre ch'e aghju pruvatu à capisce ciò chì è cumu fà, aghju lettu assai di tali guide chì travaglianu per l'autore, ma per una certa ragione ùn sò micca travagliatu per mè, è aghju decisu di aghjunghje quì tutti i pezzi chì aghju trovu. Saria assai cuntentu di qualcosa cusì.
Source: www.habr.com