Lanean Linux erabili nahi duzu, baina zure VPN korporatiboak ez dizu utziko? Orduan, artikulu honek lagun dezake, hori ziur ez den arren. Aldez aurretik ohartarazi nahi dizut ez dudala ondo ulertzen sare-administrazioaren arazoak, beraz, baliteke dena gaizki egin dudala. Bestalde, baliteke gida bat idaztea jende arruntarentzat ulergarria izango den moduan, beraz, probatzea gomendatzen dizuet.
Artikuluak beharrezkoa ez den informazio asko dauka, baina ezagutza hori gabe ezingo nituzke VPN bat konfiguratzean ustekabean agertu zitzaizkidan arazoak konponduko. Nik uste dut gida hau erabiltzen saiatzen den edonork izango dituela nik ez nituen arazoak, eta espero dut informazio gehigarri honek arazo horiek bere kabuz konpontzen lagunduko duela.
Gida honetan erabiltzen diren komando gehienak sudo bidez exekutatu behar dira, laburtasunerako kendu dena. Gogoratu.
IP helbide gehienak oso lausotuta egon dira, beraz, 435.435.435.435 bezalako helbide bat ikusten baduzu, IP normal bat egon behar du bertan, zure kasurako espezifikoak.
Ubuntu 18.04 dut, baina uste dut aldaketa txikiekin gida beste banaketa batzuetan aplika daitekeela. Hala ere, testu honetan Linux == Ubuntu.
Cisco Connect
Windows edo MacOS-en daudenek Cisco Connect-en gure VPN korporatibora konektatu ahal izango dira, atebidearen helbidea zehaztu behar baitu eta, konektatzen zaren bakoitzean, zati finko batez eta Google Authenticator-ek sortutako kodeaz osatutako pasahitza sartu.
Linux-en kasuan, ezin izan nuen Cisco Connect martxan jarri, baina openconnect erabiltzeko gomendio bat Googlen bilatu nuen, Cisco Connect ordezkatzeko bereziki egina.
Openconnect
Teorian, Ubuntuk interfaze grafiko berezi bat du openconnecterako, baina ez zait funtzionatu. Agian onerako da.
Ubuntun, openconnect paketeen kudeatzailetik instalatzen da.
apt install openconnectInstalatu eta berehala, VPN batera konektatzen saia zaitezke
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com fikziozko VPN baten helbidea da
poxvuibr - fikziozko erabiltzaile-izena
openconnect-ek pasahitz bat sartzeko eskatuko dizu, gogorarazten dizut, zati finko batek eta Google Authenticator-eko kode batek osatuta, eta, ondoren, vpn-ra konektatzen saiatuko da. Funtzionatzen badu, zorionak, segurtasunez salta dezakezu erdialdea, hau da, min handia, eta atzealdean openconnect exekutatzen ari den puntura pasa dezakezu. Ez badu funtzionatzen, jarrai dezakezu. Lanean konektatzean, adibidez, gonbidatutako Wi-Fi batetik lanean funtzionatu bazuen ere, baliteke goizegi izatea pozteko; prozedura etxetik errepikatzen saiatu beharko zenuke.
Ziurtagiria
Ezer hasteko probabilitate handia dago, eta openconnect irteerak honelako itxura izango du:
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 progressAlde batetik, hau desatsegina da, VPNarekin konexiorik ez zegoelako, baina, bestetik, arazo hau nola konpondu, printzipioz, argi dago.
Hemen zerbitzariak ziurtagiri bat bidali digu, zeinaren bidez gure jatorrizko korporazioko zerbitzariarekin konexioa egiten ari dela jakin dezakegu, eta ez iruzurgile gaizto batekin, eta ziurtagiri hori ezezaguna da sistemarentzat. Eta, beraz, ezin du egiaztatu zerbitzaria benetakoa den ala ez. Eta horrela, badaezpada, funtzionatzeari uzten dio.
Openconnect zerbitzariarekin konektatzeko, espresuki esan behar diozu VPN zerbitzaritik zein ziurtagiri etorri behar den βservercert gakoa erabiliz.
Eta zerbitzariak zein ziurtagiri bidali digun zuzenean jakin dezakezu openconnectek inprimatutakotik. Hona hemen pieza honetatik:
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 progressKomando honekin berriro konektatzen saia zaitezke
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comAgian orain funtzionatzen ari da, gero amaierara pasa zaitezke. Baina pertsonalki, Ubunta-k piku bat erakutsi zidan forma honetan
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 konponduko da, baina ezin izango duzu bertara joan. jira.evilcorp.com bezalako helbideak ez dira batere konpontzen.
Hemen zer gertatu den ez dut argi. Baina esperimentuak erakusten du lerroa gehitzen baduzu /etc/resolv.conf
nameserver 192.168.430.534orduan VPN barruko helbideak magikoki konpontzen hasiko dira eta haietatik ibil zaitezke, hau da, helbideak ebazteko DNS-k bilatzen duenak /etc/resolv.conf-en ikusten du zehazki, eta ez beste nonbait.
VPNra konexioa dagoela egiazta dezakezu eta funtzionatzen duela /etc/resolv.conf-en aldaketarik egin gabe; horretarako, sartu arakatzailean ez VPN-ren baliabidearen izen sinbolikoa, baizik eta bere IP helbidea.
Ondorioz, bi arazo daude
- VPN batera konektatzean, bere dn-a ez da jasotzen
- trafiko guztia VPN bidez doa, eta horrek ez du Interneterako sarbidea onartzen
Orain esango dizut zer egin, baina lehenik automatizazio pixka bat.
Pasahitzaren zati finkoa automatikoki sartzea
Oraingoz, ziurrenik gutxienez bost aldiz sartu duzu pasahitza eta prozedura honek dagoeneko nekatu egin zaitu. Lehenik eta behin, pasahitza luzea delako, eta bigarrenik, sartzerakoan denbora-tarte finko batean egokitu behar duzulako
Arazoaren azken irtenbidea ez zen artikuluan sartu, baina pasahitzaren zati finkoa ez dela askotan sartu behar ziurtatu dezakezu.
Demagun pasahitzaren zati finkoa fixedPassword dela, eta Google Authenticator-eko zatia 567. Pasahitz osoa openconnect-era pasa daiteke sarrera estandarraren bidez --passwd-on-stdin argumentua erabiliz.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinOrain, etengabe sartutako azken komandora itzul zaitezke eta bertan Google Authenticator-en zati bat bakarrik alda dezakezu.
VPN korporatibo batek ez dizu Interneten nabigatzen uzten.
Oro har, ez da oso deserosoa Habr-era joateko beste ordenagailu bat erabili behar duzunean. Stackoverfow-tik kopiatu-itsatsi ezinak, oro har, lana geldiarazi dezake, beraz, zerbait egin behar da.
Nolabait antolatu behar dugu, barne saretik baliabide batera sartu behar duzunean, Linux VPNra joan dadin, eta Habr-era joan behar duzunean, Internetera.
openconnect-ek, vpn-rekin abiarazi eta konexio bat ezarri ondoren, script berezi bat exekutatzen du, eta /usr/share/vpnc-scripts/vpnc-script-en dago. Aldagai batzuk script-era pasatzen dira sarrera gisa, eta VPN konfiguratzen du. Zoritxarrez, ezin izan nuen asmatu trafiko-fluxuak nola banatu VPN korporatiboaren eta Interneten gainerakoen artean jatorrizko script bat erabiliz.
Antza denez, vpn-slice utilitatea ni bezalako jendearentzat bereziki garatu zen, eta horrek bi kanaletatik trafikoa bidaltzeko aukera ematen du panderoarekin dantzatu gabe. Tira, hau da, dantza egin beharko duzu, baina ez duzu xamana izan behar.
Trafikoa bereiztea vpn-slice erabiliz
Lehenik eta behin, vpn-slice instalatu beharko duzu, zuk zeuk asmatu beharko duzu. Iruzkinetan galderarik badago, aparteko mezu bat idatziko dut honi buruz. Baina hau Python programa arrunt bat da, beraz, ez luke inolako zailtasunik izan behar. Virtualenv erabiliz instalatu dut.
Ondoren, erabilgarritasuna aplikatu behar da, -script etengailua erabiliz, irekitzeko adieraziz script estandarraren ordez, vpn-slice erabili behar duzula.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 " vpn.evilcorp.com --script script-aren ordez deitu behar den komando batekin kate bat pasatzen zaio. ./bin/vpn-slice - vpn-slice fitxategi exekutagarriaren bidea 192.168.430.0/24 - vpn-n joan beharreko helbideen maskara. Hemen, helbidea 192.168.430-rekin hasten bada, helbide hau duen baliabidea VPN barruan bilatu behar dela esan nahi dugu.
Egoerak orain ia normala izan beharko luke. Ia. Orain Habr-era joan zaitezke eta enpresa barruko baliabidera joan zaitezke ip bidez, baina ezin zara enpresa barruko baliabidera joan izen sinbolikoarekin. Ostalarietan izen sinbolikoaren eta helbidearen arteko bat etortzea zehazten baduzu, denak funtzionatu beharko luke. Eta lan egin ip-a aldatu arte. Linuxek Internetera edo intranetera sar dezake orain, IParen arabera. Baina ez-korporazioko DNS erabiltzen da oraindik helbidea zehazteko.
Arazoa forma honetan ere ager daiteke - lanean dena ondo dago, baina etxean barneko baliabide korporatiboen IP bidez soilik sar zaitezke. Izan ere, Wi-Fi korporatiboa konektatzen zarenean, DNS korporatiboa ere erabiltzen da eta bertan VPNko helbide sinbolikoak ebazten dira, nahiz eta oraindik ezinezkoa den helbide batera joatea VPN bat erabili gabe.
Hosts fitxategiaren aldaketa automatikoa
vpn-slice adeitsu galdetzen bazaio, VPNa igo ondoren, bere DNSra joan daiteke, bertan beharrezko baliabideen IP helbideak aurki ditzakete izen sinbolikoen arabera eta sar ditzake ostalarietan. VPNa itzali ondoren, helbide hauek ostalarietatik kenduko dira. Horretarako, izen sinbolikoak pasa behar dizkiozu argumentu gisa vpn-sliceri. Horrela.
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 Orain dena funtzionatu beharko luke bai bulegoan eta baita hondartzan ere.
Bilatu VPNak emandako DNSn azpidomeinu guztien helbideak
Sarean helbide gutxi badaude, ostalarien fitxategia automatikoki aldatzeko planteamenduak nahiko ondo funtzionatzen du. Baina sarean baliabide asko badaude, zoidberg.test.evilcorp.com bezalako lerroak etengabe gehitu beharko dituzu gidoiari zoidberg da proba-bankuetako baten izena.
Baina orain pixka bat ulertzen dugunean zergatik ezabatu daitekeen behar hori.
VPNa igo ondoren /etc/hosts-en begiratzen baduzu, lerro hau ikus dezakezu
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOSORTU
Eta lerro berri bat gehitu zen resolv.conf-era. Laburbilduz, vpn-slice-k nolabait zehaztu zuen non dagoen vpn-ren dns zerbitzaria.
Orain ziurtatu behar dugu evilcorp.com-en amaitzen den domeinu-izen baten IP helbidea ezagutzeko, Linux korporazioko DNSra doala, eta beste zerbait behar bada, lehenetsitakora.
Denbora dezente Googlen bilatu nuen eta aurkitu nuen funtzionaltasun hori Ubuntun eskuragarri dagoela. Horrek esan nahi du tokiko DNS zerbitzaria dnsmasq erabiltzeko gaitasuna izenak ebazteko.
Hau da, ziurta dezakezu Linux tokiko DNS zerbitzarira doala IP helbideetarako, eta, aldi berean, domeinu-izenaren arabera, dagokion kanpoko DNS zerbitzarian IP-a bilatuko du.
Sareekin eta sareko konexioekin zerikusia duen guztia kudeatzeko, Ubuntuk NetworkManager erabiltzen du, eta hautatzeko interfaze grafikoa, adibidez, Wi-Fi konexioak frontend bat besterik ez da.
Bere konfigurazioan igo beharko dugu.
- Sortu fitxategi bat /etc/NetworkManager/dnsmasq.d/evilcorp-en
helbidea=/.evilcorp.com/192.168.430.534
Erreparatu evilcorp-en aurrean dagoen puntuari. Dnsmasq-i evilcorp.com-en azpidomeinu guztiak dn korporatiboan bilatu behar direla adierazten du.
- Esan NetworkManager-i izenak ebazteko dnsmasq erabiltzeko
Sare-kudeatzailearen konfigurazioa /etc/NetworkManager/NetworkManager.conf helbidean dago gehitu behar duzu:
[nagusia] dns=dnsmasq
- Berrabiarazi Network Manager
service network-manager restartOrain, VPN batera konektatu ondoren openconnect eta vpn-slice erabiliz, ip-a normalean zehaztuko da, vpnslice-ren argumentuei helbide sinbolikoak gehitzen ez badituzu ere.
Nola sartu banakako zerbitzuetara VPN bidez
VPNra konektatzea lortu ondoren, oso pozik egon nintzen bi egunez, eta orduan gertatu zen bulegoko saretik kanpo VPNra konektatzen banaiz gero, posta-ak ez duela funtzionatzen. Sintoma ezaguna da, ezta?
Gure posta mail.publicevilcorp.com helbidean dago, hau da, ez dago dnsmasq-en araupean eta posta-zerbitzariaren helbidea DNS publikoaren bidez bilatzen da.
Beno, bulegoak DNS erabiltzen jarraitzen du, helbide hau daukana. Horixe pentsatu nuen. Izan ere, dnsmasq-i lerroa gehitu ondoren
helbidea=/mail.publicevilcorp.com/192.168.430.534
egoera ez da batere aldatu. ip berdin geratu zen. Lanera joan behar nuen.
Eta beranduago, egoeran sakondu eta arazoa pixka bat ulertu nuenean, pertsona inteligente batek esan zidan nola konpondu. Beharrezkoa zen posta zerbitzariarekin konektatzea ez horrela bakarrik, VPN bidez baizik
vpn-slice erabiltzen dut VPN bidez 192.168.430-rekin hasten diren helbideetara joateko. Eta posta zerbitzariak evilcorp-en azpidomeinua ez den helbide sinboliko bat izateaz gain, ez du 192.168.430-rekin hasten den IP helbiderik ere. Eta noski ez du onartzen sare orokorreko inor beregana etortzen.
Linux VPNtik eta posta zerbitzarira pasatzeko, vpn-slice-n ere gehitu behar duzu. Demagun posta elektronikoaren helbidea 555.555.555.555 dela
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 VPN argumentu batekin igotzeko gidoia
Hori guztia, noski, ez da oso erosoa. Bai, testua fitxategi batean gorde dezakezu eta kontsolan kopiatu eta itsatsi dezakezu eskuz idatzi beharrean, baina oraindik ez da oso atsegina. Prozesua errazteko, komandoa PATH-en kokatuko den script batean bildu dezakezu. Eta gero, Google Authenticator-etik jasotako kodea bakarrik sartu beharko duzu
#!/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 Connect~evilcorp~-en gidoia jartzen baduzu, kontsolan idatzi besterik ez duzu egin
connect_evil_corp 567987Baina orain oraindik irekita mantendu behar duzu openconnect martxan dagoen kontsola arrazoiren batengatik
Openconnect martxan atzealdean
Zorionez, openconnect-en egileek arduratu gintuzten eta programari -background-ari gako berezi bat gehitu zioten, abian jarri ondoren programa atzeko planoan funtzionatzen duena. Horrela exekutatzen baduzu, abiarazi ondoren kontsola itxi dezakezu
#!/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 Orain ez dago argi nora doazen erregistroak. Orokorrean, ez dugu erregistrorik behar, baina ez dakizu inoiz. openconnect-ek syslog-era birbideratu ditzake, non seguru eta seguru gordeko diren. βsyslog etengailua gehitu behar diozu komandoari
#!/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 Eta, beraz, ondorioztatzen da openconnect atzeko planoan nonbait funtzionatzen duela eta ez duela inor molestatzen, baina ez dago argi nola gelditu. Hau da, noski, ps irteera grep erabiliz iragazi dezakezu eta bere izenak openconnect daukan prozesu bat bilatu dezakezu, baina hori nolabait neketsua da. Eskerrik asko hau pentsatu duten egileei ere. Openconnect-ek -pid-fitxategi bat du, eta horrekin openconnect-ek bere prozesu-identifikatzailea fitxategi batean idazteko agindu diezaiokezu.
#!/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-pidOrain beti akabatu dezakezu prozesu bat komandoarekin
kill $(cat ~/vpn-pid)Prozesurik ez badago, hiltzeak madarikatu egingo du, baina ez du errorerik botako. Fitxategia ez badago, ez da ezer txarrik gertatuko, beraz, prozesua segurtasunez akabatu dezakezu scriptaren lehen lerroan.
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-pidOrain ordenagailua piztu, kontsola ireki eta komandoa exekutatu dezakezu, Google Authenticator-eko kodea pasatuz. Ondoren, kontsola iltzatu daiteke.
VPN zatirik gabe. Ondorengo baten ordez
Oso zaila izan zen VPN-slice gabe nola bizitzea ulertzea. Asko irakurri eta Googlen ibili behar izan nuen. Zorionez, arazo batekin hainbeste denbora igaro ondoren, eskuliburu teknikoak eta baita man openconnect ere eleberri zirraragarriak bezala irakurtzen dira.
Ondorioz, jakin nuen vpn-slicek, jatorrizko script-ak bezala, bideratze-taula aldatzen duela sareak bereizteko.
Bideratze taula
Besterik gabe, lehen zutabeko taula bat da, Linux-ek pasa nahi duen helbidea zeinekin hasi behar den eta bigarren zutabean zein sare-moldagailu igaro behar den helbide honetan. Izan ere, hiztun gehiago daude, baina horrek ez du funtsa aldatzen.
Bideratze-taula ikusteko, ip route komandoa exekutatu behar duzu
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 Hemen, lerro bakoitza helbide batera mezu bat bidaltzeko nora joan behar duzun ardura da. Lehenengoa helbidea non hasi behar den deskribapena da. 192.168.0.0/16 helbideak 192.168-rekin hasi behar duela nola zehaztu jakiteko, IP helbide maskara zer den bilatu behar duzu. Dev ondoren mezua bidali behar zaion egokitzailearen izena dago.
VPNrako, Linuxek egokitzaile birtual bat egin zuen - tun0. Lineak bertatik 192.168tik hasten diren helbide guztietarako trafikoa bertatik igarotzen dela bermatzen du
192.168.0.0/16 dev tun0 scope link Bideratze-taularen egungo egoera ere ikus dezakezu komandoa erabiliz ibilbidea -n (IP helbideak modu egokian anonimizatuta daude) Komando honek beste forma bateko emaitzak sortzen ditu eta, oro har, zaharkituta dago, baina bere irteera sarritan Interneteko eskuliburuetan aurkitzen da eta irakurtzeko gai izan behar duzu.
Ibilbide baten IP helbidea non hasi behar den Helmuga eta Genmask zutabeen konbinaziotik uler daiteke. Genmask-en 255 zenbakiei dagozkien IP helbidearen zatiak hartzen dira kontuan, baina 0 dagoenak ez. Hau da, Destination 192.168.0.0 eta Genmask 255.255.255.0 konbinatzeak esan nahi du helbidea 192.168.0-rekin hasten bada, hari egindako eskaera bide horretatik joango dela. Eta helmuga 192.168.0.0 baina Genmask 255.255.0.0 bada, 192.168rekin hasten diren helbideetarako eskaerak bide horretatik joango dira.
vpn-slice benetan zer egiten duen jakiteko, taulen egoerak aurretik eta ondoren aztertzea erabaki nuen.
VPNa aktibatu aurretik horrela izan zen
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 wlp3s0Openconnect vpn-slice gabe deitu ondoren honela bihurtu zen
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 tun0Eta vpn-slice-rekin konbinatuta openconnect deitu ondoren
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 tun0Ikusten da vpn-slice erabiltzen ez baduzu, orduan openconnect-ek esplizituki idazten duela helbide guztiak, berariaz adierazitakoak izan ezik, vpn bidez sartu behar direla.
Hementxe:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Bertan, ondoan, berehala adierazten da beste bide bat, erabili beharrekoa Linux-ek pasatzen saiatzen ari den helbidea taulako edozein maskara bat ez badator.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Dagoeneko hemen idatzita dago kasu honetan Wi-Fi egokitzaile estandar bat erabili behar duzula.
Uste dut VPN bidea erabiltzen dela bideratze-taulan lehenengoa delako.
Eta, teorikoki, bide lehenetsi hau bideratze-taulatik kentzen baduzu, orduan dnsmasq openconnect-ekin batera funtzionamendu normala ziurtatu beharko luke.
saiatu nintzen
route del defaultEta dena funtzionatu zuen.
Eskaerak posta zerbitzari batera bideratzea vpn-slice gabe
Baina posta zerbitzari bat ere badut 555.555.555.555 helbidea duena, VPN bidez ere sartu behar dena. Bertara joateko bidea ere eskuz gehitu behar da.
ip route add 555.555.555.555 via dev tun0Eta orain dena ondo dago. Beraz, vpn-slice gabe egin dezakezu, baina ondo jakin behar duzu zer egiten ari zaren. Orain pentsatzen ari naiz jatorrizko openconnect script-aren azken lerroan gehitu behar den ibilbide lehenetsia kentzeko eta postarako bide bat gehitzeko vpn-ra konektatu ondoren, nire bizikletan zati mugikor gutxiago egon dadin.
Seguruenik, hitz hau nahikoa izango litzateke norbaitek VPN bat nola konfiguratu ulertzeko. Baina zer eta nola egin ulertzen saiatzen ari nintzela, egilearentzat funtzionatzen duten gida dezente irakurri ditut, baina arrazoiren batengatik ez zaizkit balio, eta aurkitu ditudan pieza guztiak hemen gehitzea erabaki dut. Oso pozik egongo nintzateke horrelako zerbaitengatik.
Iturria: www.habr.com