Ĉu vi volas uzi Linukson ĉe la laboro, sed via kompania VPN ne permesos vin? Tiam ĉi tiu artikolo povas helpi, kvankam ĉi tio ne estas certa. Mi ŝatus averti vin anticipe, ke mi ne bone komprenas problemojn pri retaj administradoj, do eblas, ke mi faris ĉion malbone. Aliflanke, eblas, ke mi povas skribi gvidilon tiel, ke ĝi estos komprenebla por ordinaraj homoj, do mi konsilas al vi provi ĝin.
La artikolo enhavas multajn nenecesajn informojn, sed sen ĉi tiu scio mi ne estus povinta solvi la problemojn, kiuj neatendite aperis al mi kun agordo de VPN. Mi pensas, ke ĉiu, kiu provos uzi ĉi tiun gvidilon, havos problemojn, kiujn mi ne havis, kaj mi esperas, ke ĉi tiuj kromaj informoj helpos solvi ĉi tiujn problemojn memstare.
La plej multaj el la komandoj uzataj en ĉi tiu gvidilo devas esti rulitaj per sudo, kiu estis forigita por koncizeco. Memoru.
Plej multaj IP-adresoj estis severe malklarigitaj, do se vi vidas adreson kiel 435.435.435.435, devas esti iu normala IP tie, specifa por via kazo.
Mi havas Ubuntu 18.04, sed mi pensas, ke kun etaj ŝanĝoj la gvidilo povas esti aplikata al aliaj distribuoj. Tamen, en ĉi tiu teksto Linukso == Ubuntu.
Cisco Connect
Tiuj, kiuj estas en Vindozo aŭ MacOS, povas konektiĝi al nia kompania VPN per Cisco Connect, kiu devas specifi la enirejon-adreson kaj, ĉiufoje kiam vi konektas, enigi pasvorton konsistantan el fiksa parto kaj kodo generita de Google Authenticator.
En la kazo de Linukso, mi ne povis funkcii Cisco Connect, sed mi sukcesis guglo rekomendon uzi openconnect, faritan specife por anstataŭigi Cisco Connect.
Openconnect
En teorio, Ubuntu havas specialan grafikan interfacon por openconnect, sed ĝi ne funkciis por mi. Eble estas por pli bone.
En Ubuntu, openconnect estas instalita de la pakaĵmanaĝero.
apt install openconnectTuj post instalado, vi povas provi konektiĝi al VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com estas la adreso de fikcia VPN
poxvuibr - fikcia uzantnomo
openconnect petos vin enigi pasvorton, kiu, mi memorigu vin, konsistas el fiksa parto kaj kodo de Google Authenticator, kaj tiam ĝi provos konektiĝi al la vpn. Se ĝi funkcias, gratulon, vi povas sekure transsalti la mezon, kiu estas multe da doloro, kaj pluiri al la punkto pri openconnect kuranta en la fono. Se ĝi ne funkcias, tiam vi povas daŭrigi. Kvankam se ĝi funkciis dum konekto, ekzemple, de gasto Wi-Fi ĉe la laboro, tiam eble estas tro frue por ĝoji; vi devus provi ripeti la proceduron de hejme.
Atestilo
Estas alta probablo, ke nenio komenciĝos, kaj la eligo de openconnect aspektos kiel ĉi tio:
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 progressUnuflanke, ĉi tio estas malagrabla, ĉar ne estis konekto al la VPN, sed aliflanke, kiel ripari ĉi tiun problemon estas, principe, klara.
Ĉi tie la servilo sendis al ni atestilon, per kiu ni povas determini, ke la konekto estas farita al la servilo de nia denaska korporacio, kaj ne al malbona fraŭdo, kaj ĉi tiu atestilo estas nekonata al la sistemo. Kaj tial ŝi ne povas kontroli ĉu la servilo estas reala aŭ ne. Kaj do, ĉiaokaze, ĝi ĉesas funkcii.
Por ke openconnect konektiĝu al la servilo, vi devas eksplicite diri al ĝi, kiu atestilo devas veni de la VPN-servilo uzante la ŝlosilon —servercert.
Kaj vi povas ekscii, kiun atestilon sendis al ni la servilo rekte de kio openconnect presis. Jen el ĉi tiu peco:
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 ĉi tiu komando vi povas provi konekti denove
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comEble nun ĝi funkcias, tiam vi povas pluiri ĝis la fino. Sed persone, Ubunta montris al mi figon en ĉi tiu formo
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 solvos, sed vi ne povos iri tien. Adresoj kiel jira.evilcorp.com tute ne estas solvitaj.
Kio okazis ĉi tie ne estas klara al mi. Sed eksperimento montras, ke se vi aldonas la linion al /etc/resolv.conf
nameserver 192.168.430.534tiam la adresoj ene de la VPN komencos magie solvi kaj vi povas trairi ilin, tio estas, kion DNS serĉas por solvi adresojn aspektas specife en /etc/resolv.conf, kaj ne aliloke.
Vi povas kontroli, ke ekzistas konekto al la VPN kaj ĝi funkcias sen fari ajnajn ŝanĝojn al /etc/resolv.conf; por fari tion, nur enigu en la retumilon ne la simbolan nomon de la rimedo de la VPN, sed ĝian IP-adreson.
Kiel rezulto, estas du problemoj
- Konektante al VPN, ĝia dns ne estas reprenita
- la tuta trafiko pasas tra VPN, kiu ne permesas aliron al Interreto
Mi diros al vi, kion fari nun, sed unue iom da aŭtomatigo.
Aŭtomata enigo de la fiksita parto de la pasvorto
Ĝis nun, vi plej verŝajne jam enigis vian pasvorton almenaŭ kvin fojojn kaj ĉi tiu proceduro jam lacigis vin. Unue, ĉar la pasvorto estas longa, kaj due, ĉar enirante vi devas konveni en fiksita tempoperiodo
La fina solvo de la problemo ne estis inkluzivita en la artikolo, sed vi povas certigi, ke la fiksita parto de la pasvorto ne devas esti enmetita multfoje.
Ni supozu, ke la fiksita parto de la pasvorto estas fixedPassword, kaj la parto de Google Authenticator estas 567 987. La tuta pasvorto povas esti pasita al openconnect per norma enigo uzante la --passwd-on-stdin argumenton.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinNun vi povas konstante reveni al la lasta enigita komando kaj ŝanĝi tie nur parton de Google Authenticator.
Korporacia VPN ne permesas al vi navigi la Interreton.
Ĝenerale, ne estas tre maloportune kiam vi devas uzi apartan komputilon por iri al Habr. La nekapablo kopii-alglui de stackoverfow ĝenerale povas paralizi laboron, do io devas esti farita.
Ni devas iel organizi ĝin, por ke kiam vi bezonas aliri rimedon de la interna reto, Linukso iru al la VPN, kaj kiam vi devas iri al Habr, ĝi iru al Interreto.
openconnect, post lanĉo kaj establado de konekto kun vpn, efektivigas specialan skripton, kiu troviĝas en /usr/share/vpnc-scripts/vpnc-script. Iuj variabloj estas transdonitaj al la skripto kiel enigo, kaj ĝi agordas la VPN. Bedaŭrinde, mi ne povis eltrovi kiel disigi trafikfluojn inter kompania VPN kaj la resto de la Interreto per denaska skripto.
Ŝajne, la vpn-slice ilo estis evoluigita speciale por homoj kiel mi, kiu permesas vin sendi trafikon tra du kanaloj sen danci per tamburino. Nu, tio estas, vi devos danci, sed vi ne devas esti ŝamano.
Trafika apartigo uzante vpn-tranĉaĵon
Unue, vi devos instali vpn-slice, vi devos mem eltrovi tion. Se estas demandoj en la komentoj, mi skribos apartan afiŝon pri tio. Sed ĉi tio estas regula Python-programo, do ne devus esti malfacilaĵoj. Mi instalis per virtualenv.
Kaj tiam la ilo devas esti aplikita, uzante la -script-ŝaltilon, indikante malfermikonekti, ke anstataŭ la norma skripto, vi devas uzi 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 estas transdonita ĉeno kun komando, kiu devas esti vokita anstataŭ la skripto. ./bin/vpn-slice - vojo al la vpn-slice rulebla dosiero 192.168.430.0/24 - masko de adresoj al iri en vpn. Ĉi tie, ni volas diri, ke se la adreso komenciĝas per 192.168.430, tiam la rimedo kun ĉi tiu adreso devas esti serĉita ene de la VPN
La situacio devus nun esti preskaŭ normala. Preskaŭ. Nun vi povas iri al Habr kaj vi povas iri al la intrakompania rimedo per ip, sed vi ne povas iri al la intrakompania rimedo per simbola nomo. Se vi specifas kongruon inter la simbola nomo kaj adreso en gastigantoj, ĉio devus funkcii. Kaj laboru ĝis la ip ŝanĝiĝos. Linukso nun povas aliri la Interreton aŭ la intrareton, depende de la IP. Sed ne-kompania DNS ankoraŭ estas uzata por determini la adreson.
La problemo ankaŭ povas manifestiĝi en ĉi tiu formo - ĉe la laboro ĉio estas en ordo, sed hejme vi nur povas aliri internajn kompaniajn rimedojn per IP. Ĉi tio estas ĉar kiam vi estas konektita al kompania Wi-Fi, la kompania DNS ankaŭ estas uzata, kaj simbolaj adresoj de la VPN estas solvitaj en ĝi, malgraŭ tio, ke estas ankoraŭ neeble iri al tia adreso sen uzi VPN.
Aŭtomata modifo de la gastiga dosiero
Se vpn-slice estas ĝentile demandata, tiam post levi la VPN, ĝi povas iri al sia DNS, trovi tie la IP-adresojn de la necesaj rimedoj per iliaj simbolaj nomoj kaj enigi ilin en gastigantoj. Post malŝalto de la VPN, ĉi tiuj adresoj estos forigitaj de gastigantoj. Por fari tion, vi devas pasi simbolajn nomojn al vpn-slice kiel argumentoj. Kiel tio.
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 Nun ĉio devus funkcii kaj en la oficejo kaj sur la strando.
Serĉu la adresojn de ĉiuj subdomajnoj en la DNS donita de la VPN
Se estas malmultaj adresoj ene de la reto, tiam la aliro aŭtomate modifi la gastigajn dosierojn funkcias sufiĉe bone. Sed se estas multaj rimedoj en la reto, tiam vi konstante bezonos aldoni liniojn kiel zoidberg.test.evilcorp.com al la skripto zoidberg estas la nomo de unu el la testbenkoj.
Sed nun, kiam ni komprenas iomete, kial ĉi tiu bezono povas esti forigita.
Se, post levi la VPN, vi rigardas en /etc/hosts, vi povas vidi ĉi tiun linion
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOKREITA
Kaj nova linio estis aldonita al resolv.conf. Mallonge, vpn-slice iel determinis kie troviĝas la dns-servilo por la vpn.
Nun ni devas certigi, ke por ekscii la IP-adreson de domajna nomo finiĝanta en evilcorp.com, Linukso iras al la kompania DNS, kaj se io alia necesas, tiam al la defaŭlta.
Mi Guglos dum sufiĉe da tempo kaj trovis, ke tia funkcieco haveblas en Ubuntu el la skatolo. Ĉi tio signifas la kapablon uzi la lokan DNS-servilon dnsmasq por solvi nomojn.
Tio estas, vi povas certigi, ke Linukso ĉiam iras al la loka DNS-servilo por IP-adresoj, kiuj siavice, depende de la domajna nomo, serĉos la IP sur la responda ekstera DNS-servilo.
Por administri ĉion rilate al retoj kaj retkonektoj, Ubuntu uzas NetworkManager, kaj la grafika interfaco por elekti, ekzemple, Wi-Fi-konektoj estas nur antaŭa fino al ĝi.
Ni devos grimpi en ĝia agordo.
- Kreu dosieron en /etc/NetworkManager/dnsmasq.d/evilcorp
adreso=/.evilcorp.com/192.168.430.534
Atentu la punkton antaŭ evilcorp. Ĝi signalas al dnsmasq, ke ĉiuj subdomajnoj de evilcorp.com estu serĉataj en la kompania dns.
- Diru al NetworkManager uzi dnsmasq por nomsolvado
La agordo de reto-manaĝero troviĝas en /etc/NetworkManager/NetworkManager.conf Vi devas aldoni tie:
[ĉefa] dns=dnsmasq
- Rekomencu NetworkManager
service network-manager restartNun, post konektiĝi al VPN per openconnect kaj vpn-slice, la ip estos determinita normale, eĉ se vi ne aldonas simbolajn adresojn al la argumentoj al vpnslice.
Kiel aliri individuajn servojn per VPN
Post kiam mi sukcesis konekti al la VPN, mi estis tre feliĉa dum du tagoj, kaj tiam montriĝis, ke se mi konektas al la VPN de ekster la oficeja reto, tiam poŝto ne funkcias. La simptomo estas konata, ĉu ne?
Nia poŝto situas en mail.publicevilcorp.com, kio signifas, ke ĝi ne falas sub la regulo en dnsmasq kaj la poŝtservila adreso estas serĉata per publika DNS.
Nu, la oficejo ankoraŭ uzas DNS, kiu enhavas ĉi tiun adreson. Tion mi pensis. Fakte, post aldoni la linion al dnsmasq
adreso=/mail.publicevilcorp.com/192.168.430.534
la situacio tute ne ŝanĝiĝis. ip restis la sama. Mi devis iri labori.
Kaj nur poste, kiam mi pliprofundiĝis en la situacion kaj iomete komprenis la problemon, unu saĝa persono diris al mi kiel solvi ĝin. Necesis konekti al la poŝtservilo ne nur tiel, sed per VPN
Mi uzas vpn-slice por trairi la VPN al adresoj, kiuj komenciĝas per 192.168.430. Kaj la poŝtservilo ne nur havas simbolan adreson, kiu ne estas subdomajno de evilcorp, ĝi ankaŭ ne havas IP-adreson, kiu komenciĝas per 192.168.430. Kaj kompreneble li ne permesas al iu ajn el la ĝenerala reto veni al li.
Por ke Linukso trairu la VPN kaj al la poŝtservilo, vi devas aldoni ĝin ankaŭ al vpn-slice. Ni diru, ke la adreso de la sendinto estas 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 Skripto por levi VPN kun unu argumento
Ĉio ĉi, kompreneble, ne estas tre oportuna. Jes, vi povas konservi la tekston al dosiero kaj kopii-glui ĝin en la konzolon anstataŭ tajpi ĝin mane, sed ĝi ankoraŭ ne estas tre agrabla. Por faciligi la procezon, vi povas envolvi la komandon en skripto, kiu troviĝos en PATH. Kaj tiam vi nur bezonos enigi la kodon ricevitan de 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 vi metas la skripton en connect~evilcorp~ vi povas simple skribi en la konzolo
connect_evil_corp 567987Sed nun vi ankoraŭ devas teni malfermita la konzolo en kiu openconnect funkcias ial
Funkcias openconnect en la fono
Feliĉe, la aŭtoroj de openconnect zorgis pri ni kaj aldonis specialan ŝlosilon al la programo -fono, kiu igas la programon funkcii en la fono post lanĉo. Se vi kuras ĝin tiel, vi povas fermi la konzolon post lanĉo
#!/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 Nun simple ne estas klare, kien la ŝtipoj iras. Ĝenerale, ni ne vere bezonas protokolojn, sed vi neniam scias. openconnect povas redirekti ilin al syslog, kie ili estos sekuraj kaj sekuraj. vi devas aldoni la -syslog-ŝaltilon al la komando
#!/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 Kaj do, rezultas, ke openconnect funkcias ie en la fono kaj ne ĝenas iun, sed ne klaras kiel haltigi ĝin. Tio estas, vi povas, kompreneble, filtri la ps-eligon per grep kaj serĉi procezon, kies nomo enhavas openconnect, sed ĉi tio estas iel teda. Dankon al la aŭtoroj, kiuj pensis ankaŭ pri tio. Openconnect havas ŝlosilon -pid-dosiero, per kiu vi povas instrukcii openconnect skribi ĝian procezidentigilon al dosiero.
#!/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-pidNun vi ĉiam povas mortigi procezon per la komando
kill $(cat ~/vpn-pid)Se ne ekzistas procezo, mortigo malbenos, sed ne ĵetos eraron. Se la dosiero ne estas tie, tiam ankaŭ nenio malbona okazos, do vi povas sekure mortigi la procezon en la unua linio de la skripto.
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-pidNun vi povas ŝalti vian komputilon, malfermi la konzolon kaj ruli la komandon, pasigante al ĝi la kodon de Google Authenticator. La konzolo tiam povas esti najlita malsupren.
Sen VPN-tranĉaĵo. Anstataŭ postparolo
Montriĝis tre malfacile kompreni kiel vivi sen VPN-tranĉo. Mi devis legi kaj guglo multe. Feliĉe, post pasigi tiom da tempo kun problemo, teknikaj manlibroj kaj eĉ man openconnect legas kiel ekscitaj romanoj.
Kiel rezulto, mi eksciis, ke vpn-slice, kiel la denaska skripto, modifas la enrutigan tabelon al apartaj retoj.
Voja tablo
Simple, ĉi tio estas tabelo en la unua kolumno, kiu enhavas per kio komenciĝu la adreso, kiun Linukso volas trairi, kaj en la dua kolumno, kiun retadaptilon trapasi ĉe ĉi tiu adreso. Fakte, estas pli da parolantoj, sed tio ne ŝanĝas la esencon.
Por vidi la enrutigan tabelon, vi devas ruli la komandon 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 Ĉi tie, ĉiu linio respondecas pri kie vi devas iri por sendi mesaĝon al iu adreso. La unua estas priskribo de kie la adreso devus komenciĝi. Por kompreni kiel determini, ke 192.168.0.0/16 signifas, ke la adreso devas komenciĝi per 192.168, vi devas guglo, kio estas IP-adresmasko. Post dev estas la nomo de la adaptilo al kiu la mesaĝo estu sendita.
Por VPN, Linukso faris virtualan adaptilon - tun0. La linio certigas, ke trafiko por ĉiuj adresoj komencantaj per 192.168 trairas ĝin
192.168.0.0/16 dev tun0 scope link Vi ankaŭ povas rigardi la nunan staton de la vojtabelo uzante la komandon itinero -n (IP-adresoj estas lerte anonimigitaj) Ĉi tiu komando produktas rezultojn en malsama formo kaj estas ĝenerale malrekomendita, sed ĝia eligo ofte troviĝas en manlibroj en la Interreto kaj vi devas povi legi ĝin.
Kie la IP-adreso por itinero devus komenci, povas esti komprenita de la kombinaĵo de la Destination kaj Genmask-kolumnoj. Tiuj partoj de la IP-adreso, kiuj respondas al la numeroj 255 en Genmask, estas konsiderataj, sed tiuj, kie estas 0, ne. Tio estas, la kombinaĵo de Destino 192.168.0.0 kaj Genmask 255.255.255.0 signifas, ke se la adreso komenciĝas per 192.168.0, tiam la peto al ĝi iros laŭ ĉi tiu vojo. Kaj se Destino 192.168.0.0 sed Genmask 255.255.0.0, tiam petoj al adresoj kiuj komenciĝas per 192.168 iros laŭ ĉi tiu vojo.
Por ekscii, kion efektive faras vpn-slice, mi decidis rigardi la statojn de la tabeloj antaŭ kaj post
Antaŭ ŝalti la VPN ĝi estis tiel
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 wlp3s0Post vokado de openconnect sen vpn-slice ĝi fariĝis tiel
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 tun0Kaj post vokado de openconnect en kombinaĵo kun vpn-slice tiel
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 tun0Oni povas vidi, ke se vi ne uzas vpn-slice, tiam openconnect eksplicite skribas, ke ĉiuj adresoj, krom tiuj specife indikitaj, devas esti alireblaj per vpn.
Ĉi tie:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Tie, apud ĝi, tuj estas indikita alia vojo, kiun oni devas uzi se la adreso, kiun Linukso provas trapasi, ne kongruas kun iu masko de la tabelo.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Estas jam skribite ĉi tie, ke ĉi-kaze vi devas uzi norman WiFi-adaptilon.
Mi kredas, ke la VPN-vojo estas uzata ĉar ĝi estas la unua en la vojtabelo.
Kaj teorie, se vi forigas ĉi tiun defaŭltan vojon de la vojtabelo, tiam kune kun dnsmasq openconnect devus certigi normalan funkciadon.
mi provis
route del defaultKaj ĉio funkciis.
Sendante petojn al poŝtservilo sen vpn-slice
Sed mi ankaŭ havas poŝtservilon kun la adreso 555.555.555.555, kiu ankaŭ devas esti alirebla per VPN. La vojo al ĝi ankaŭ devas esti aldonita permane.
ip route add 555.555.555.555 via dev tun0Kaj nun ĉio estas en ordo. Do vi povas fari sen vpn-slice, sed vi devas bone scii, kion vi faras. Mi nun pensas aldoni al la lasta linio de la denaska openconnect skripto la forigon de la defaŭlta itinero kaj aldoni itineron por la retpoŝto post konekto al la vpn, nur por ke estu malpli da moviĝantaj partoj en mia biciklo.
Verŝajne, ĉi tiu postparolo sufiĉus por ke iu komprenu kiel agordi VPN. Sed dum mi provis kompreni kion kaj kiel fari, mi legis multe da tiaj gvidiloj, kiuj funkcias por la aŭtoro, sed ial ne funkcias por mi, kaj mi decidis aldoni ĉi tie ĉiujn pecojn, kiujn mi trovis. Mi tre ĝojus pri io tia.
fonto: www.habr.com