A do you want to use Linux at work, but the corporate VPN won't let you? Then this article might help, although that's not certain. I want to warn you in advance that I have a poor understanding of network administration, so it's possible that I've done everything wrong. On the other hand, it's also possible that I can write a guide that will be understandable to ordinary people, so I advise you to give it a try.
The article contains a lot of unnecessary information, but without this knowledge, I wouldn't have been able to solve the problems that unexpectedly arose with my VPN setup. I think that anyone trying to apply this guide will encounter issues that I didn't have, and I hope this extra information will help resolve those problems independently.
Most of the commands used in the guide need to be executed via sudo, which has been removed for brevity. Keep that in mind.
Most IP addresses have undergone severe obfuscation, so if you see an address like 435.435.435.435 â there should be a normal IP specific to your case.
I have Ubuntu 18.04, but I think with some small adjustments, the guide can be applied to other distributions as well. However, in this text, Linux == Ubuntu.
Cisco Connect
Those on Windows or MacOS can connect to our corporate VPN through Cisco Connect, which requires specifying the gateway address and entering a password at each connection consisting of a fixed part and a code generated by Google Authenticator.
In the case of Linux, I couldn't set up Cisco Connect, but I did manage to find a recommendation to use openconnect, which is designed specifically to replace Cisco Connect.
Openconnect
In theory, there is a special graphical interface for openconnect in Ubuntu, but it didn't work for me. Perhaps that's for the best.
In Ubuntu, openconnect is installed from the package manager.
apt install openconnectImmediately after installation, you can try connecting to the VPN.
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com is the address of a fictional VPN.
poxvuibr is the name of a fictional user.
openconnect do t'ju kërkojë të futni një fjalëkalim, i cili, më kujtohet, përbëhet nga një pjesë fiksuese dhe një kod nga Google Authenticator, pastaj do të përpiqet të lidhet me vpn. Nëse ndodhi, ju përgëzoj, mund të kaloni me besim përmes pjesës së mesme ku ka shumë dhimbje dhe të kaloni në pikën për funksionimin e openconnect në sfond. Nëse nuk funksionoi, mund të vazhdoni. Megjithatë, nëse funksionoi gjatë lidhjes, për shembull, nga një Wi-Fi mysafir në punë, mund të jeni të gëzuar dhe ndoshta është herët, duhet të provoni përsëri procedurën nga shtëpia.
Certifikata
Me shumë mundësi, asgjë nuk do të nisë, dhe rezultatet e openconnect do të duken siç vijon:
POST https://vpn.evilcorp.com/
I lidhur me 777.777.777.777:443
Negocimi SSL me vpn.evilcorp.com
Dështimi i verifikimit të certifikatës së serverit: nënshkruesi nuk u gjet
Certifikata nga serveri VPN "vpn.evilcorp.com" dështoi verifikimin.
Arsye: nënshkruesi nuk u gjet
Për të besuar këtë server në të ardhmen, ndoshta shtoni këtë në linjën tuaj të komandës:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Shkruani 'po' për të pranuar, 'jo' për të abortuar; gjithçka tjetër për të parë: fgets (stdin): Operacioni tani është duke u zhvilluarNga njëra anë, kjo është e pakëndshme, sepse lidhja me VPN nuk ndodhi, por nga ana tjetër, si të rregullohet ky problem në parim është e qartë.
Këtu serveri na dërgoi një certifikatë, me anë të së cilës mund të përcaktojmë se lidhja po ndodh pikërisht me serverin e kompanisë sonë, dhe jo me ndonjë mashtrues të keq, por sistemi nuk e njeh këtë certifikatë. Dhe për këtë arsye, nuk mund ta verifikojë nëse serveri është i vërtetë apo jo. Dhe për këtë arsye, për çdo rast, ndalon punën.
Për të bërë që openconnect të lidhet me serverin, është e nevojshme t'i thuash qartë cilën certifikatë duhet të marrë nga serveri VPN duke përdorur çelësin --servercert
Dhe mund ta dimë se cila certifikatë na dërgoi serveri direkt nga ajo që shkroi openconnect. Ja nga ky fragment:
Për të besuar këtë server në të ardhmen, ndoshta shtoni këtë në linjën tuaj të komandës:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Shkruani 'po' për të pranuar, 'jo' për të abortuar; gjithçka tjetër për të parë: fgets (stdin): Operacioni tani është duke u zhvilluarMe këtë komandë mund të provoni të lidheni sërish
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comNdoshta tani ka funksionuar, atëherë mund të kaloni në fund. Por personalisht, Ubuntu më tregoi një gisht kështu.
POST https://vpn.evilcorp.com/
I lidhur me 777.777.777.777:443
Negociata SSL me vpn.evilcorp.com
Verifikimi i certifikatës së serverit dështoi: nënshkruesi nuk u gjet
I lidhur me HTTPS në vpn.evilcorp.com
XML POST aktivizuar
Ju lutem, shkruani emrin tuaj të përdoruesit dhe fjalëkalimin.
POST https://vpn.evilcorp.com/
Mori përgjigje CONNECT: HTTP/1.1 200 OK
CSTP i lidhur. DPD 300, Mbajte 30
Konfigurimi DTLS dështoi; duke përdorur SSL në vend
I lidhur si 192.168.333.222, duke përdorur SSL
NOSSSSSHHHHHHHHDDDDD
3
NOSSSSSHHHHHHHHDDDDD
3
RTNETLINK përgjigjet: Dosja ekziston
/etc/resolvconf/update.d/libc: Paralajmërim: /etc/resolv.conf nuk është një lidhje simbolike me /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 do të zgjidhë, por nuk do të mund të hyni aty. Adresat si jira.evilcorp.com në të vërtetë nuk zgjidhen.
ĂfarĂ« ndodhi kĂ«tu, nuk e kuptoj. Por eksperimentet tregojnĂ« se nĂ«se shtoni nĂ« /etc/resolv.conf rreshtin
nameserver 192.168.430.534atëherë adresat brenda VPN do të fillojnë të zgjidhin magjikisht dhe do të mund të qarkullojnë, që do të thotë se ajo që kërkon të zgjidhë adresat me DNS, shikon saktësisht në /etc/resolv.conf, e jo diku tjetër.
Mund të konfirmoni se ekziston lidhja me VPN dhe funksionon edhe pa rregullime në /etc/resolv.conf, mjafton të futni në shfletues një adresë IP në vend të emrit simbolik të burimit nga vpn.
Kështu që dalin dy probleme
- kur lidheni me VPN nuk merret DNS-i i saj
- e gjithë trafik do të kalojë përmes vpn, i cili nuk lejon qasje në internet
ĂfarĂ« tĂ« bĂ«ni, tani do ta tregoj, por fillimisht pak automatizim.
Futurja automatike e pjesës fikse të fjalëkalimit
Në këtë moment ju me siguri keni futur fjalëkalimin të paktën pesë herë dhe kjo procedurë ju ka lodhur tashmë. Së pari, sepse fjalëkalimi është i gjatë, së dyti sepse kur futni duhet të jeni brenda një periudhe fikse kohore.
Zgjidhja përfundimtare e problemit nuk është përfshirë në artikull, por mund të bëni kështu, për sa kohë që pjesa fikse e fjalëkalimit nuk duhet futur shumë herë.
Le të themi, pjesa fikse e fjalëkalimit është fixedPassword, dhe pjesa nga Google Authenticator 567 987. I gjithë fjalëkalimi tërësisht openconnect mund të dërgohet përmes hyrjes standarde me argumentin --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinTani mund të ktheheni vazhdimisht në komandën e fundit të futur dhe të ndryshoni vetëm pjesën nga Google Authenticator.
VPN e korporatës nuk lejon qasje në internet.
Nuk është shumë e këndshme që për të hyrë në habr duhet të përdorësh një kompjuter të veçantë. Mungesa e mundësisë për të kopjuar dhe ngjitur nga stackoverflow, në të vërtetë mund të paralizojë punën, prandaj duhet të bësh diçka.
Duhet ndonjĂ« mĂ«nyrĂ« pĂ«r ta organizuar qĂ« kur duhet tĂ« hyj nĂ« burim nga rrjeti i brendshĂ«m, Linux tĂ« conectohet nĂ« VPN, dhe kur tĂ« hyj nĂ« Habr â tĂ« hyj nĂ« internet.
Openconnect pas fillimit dhe vendosjes së lidhjes me VPN, ekzekuton një skript të veçantë, që ndodhet në /usr/share/vpnc-scripts/vpnc-script. Skripti merr disa variabla hyrëse dhe bën konfigurimin e VPN. Fatkeqësisht, nuk arrita të kuptoj se si të ndaja rrjedhat e trafikut midis VPN-së korporative dhe internetit të zakonshëm duke përdorur skriptin e natyrshëm.
Duket se për ata si unë është zhvilluar utilitar vpn-slice, i cili lejon të drejtohet trafiku përmes dy kanaleve pa nevojë për hidhërime. Pra, do të thotë se do të duhet të kërcejnë, por nuk është e nevojshme të jesh shaman për këtë.
Ndara e trafikut duke përdorur vpn-slice
Së pari, duhet të instalohet vpn-slice, për këtë do të duhet të merremi me të vetë. Nëse ka pyetje në koment, do të shkruaj një post të veçantë për këtë. Por është një program i zakonshëm në Python, kështu që nuk duhet të ketë vështirësi. E kam instaluar duke përdorur virtualenv.
Dhe mĂ« pas duhet tĂ« aplikohet utilitari, duke pĂ«rdorur çelĂ«sin âscript duke treguar openconnect, qĂ« nĂ« vend tĂ« skriptit standard tĂ« pĂ«rdoret 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 NĂ« âscript kalon njĂ« varg me komandĂ«n qĂ« duhet thirrur nĂ« vend tĂ« skriptit. .\/bin\/vpn-slice â rruga te file ekzekutiv vpn-slice 192.168.430.0\/24 â maska e adresave, pĂ«r tĂ« cilat duhet t'i qasemi nĂ« VPN. KĂ«tu, do tĂ« thotĂ« se nĂ«se adresa fillon me 192.168.430 â atĂ«herĂ« burimi me kĂ«tĂ« adresĂ« duhet kĂ«rkuar brenda VPN.
Tani situata duhet tĂ« jetĂ« gati normale. PjesĂ«risht. Tani mund tĂ« hyjmĂ« nĂ« Habr dhe mund tĂ« hyjmĂ« nĂ« burimin korporativ me IP, por nuk mund tĂ« hyjmĂ« nĂ« burimin korporativ me emrin simbolik. NĂ«se vendosim pĂ«rputhjen midis emrit simbolik dhe adresĂ«s nĂ« hosts â gjithçka duhet tĂ« funksionojĂ«. Dhe do tĂ« funksionojĂ« derisa IP tĂ« ndryshojĂ«. Linux tani di tĂ« hyjĂ« nĂ« internet ose nĂ« rrjetin korporativ varĂ«sisht nga IP. Por pĂ«r pĂ«rcaktimin e adresĂ«s ende pĂ«rdoret DNS jo korporative.
Problemi mund tĂ« shfaqet gjithashtu nĂ« kĂ«tĂ« mĂ«nyrĂ« â nĂ« punĂ« gjithçka Ă«shtĂ« nĂ« rregull, por nĂ« shtĂ«pi mund tĂ« hyni nĂ« burimet brenda kompanike vetĂ«m pĂ«rmes IP-sĂ«. Kjo Ă«shtĂ« pĂ«r shkak se kur jeni tĂ« lidhur me Wi-Fi-nĂ« e kompanisĂ«, DNS pĂ«rdoret gjithashtu nga korporata, dhe atje emrat simbolikĂ« nga VPN rezolvohen, ndonĂ«se kalimi nĂ« njĂ« adresĂ« tĂ« tillĂ« pa pĂ«rdorur VPN mbetet i pamundur.
Modifikimi automatik i skedarit hosts
Nëse vpn-slice e lutni me sjellje të mirë, ai mund, pas ngritjes së VPN, të shkojë në DNS-në e saj, të gjejë adresat IP të burimeve të nevojshme sipas emrave të tyre simbolikë dhe t'i shkruajë ato në hosts. Pas ndalimit të VPN, këto adresa do të fshihen nga hosts. Për këtë, duhet të transferoni emrat simbolikë në vpn-slice si argumente. Kështu.
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 Tani gjithçka duhet të funksionojë si në zyrë ashtu edhe në plazh.
Kërkoni adresat e të gjitha subdomenëve në DNS-në që ofron VPN.
Nëse brenda rrjetit ka pak adresash, qasja me modifikimin automatik të skedarit hosts është plotësisht funksionale. Por nëse ka shumë burime në rrjet, do t'ju nevojitet vazhdimisht të shtoni rreshta në skenarin e tillë si zoidberg.test.evilcorp.com, zoidberg është emri i një prej ambienteve testuese.
Por tani, kur ne kuptojmë pak se cilat janë gjërat, mund ta eliminojmë këtë nevojë.
Nëse, pas ngritjes së VPN, shikoni në \/etc\hosts, mund të shihni një rresht të tillë.
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
Po ashtu, në resolv.conf është shtuar një rresht i ri. Në thelb, vpn-slice në një farë mënyre identifikoi se ku ndodhet serveri DNS për VPN.
Tani duhet ta bëjmë që, për të gjetur adresën IP të një emri domeni që përfundon me evilcorp.com, Linux të shkojë në DNS-në korporative dhe, nëse duhet diçka tjetër, atëherë në të parin standard.
Unë kam kërkuar për një kohë të gjatë dhe kam zbuluar se një funksionalitet i tillë ekziston në Ubuntu nga kutia. E ka fjalën për mundësinë e përdorimit të serverit lokal DNS dnsmasq për rezolvimin e emrave.
Pra, mund të bëni që për adresat IP, Linux gjithmonë të shkojë te serveri lokal DNS, i cili, në varësi të emrit të domenit, do të kërkojë IP-të në përkatësin server DNS të jashtëm.
Për të menaxhuar gjithçka që lidhet me rrjetet dhe lidhjet rrjetës, në Ubuntu përdoret NetworkManager, dhe ndërfaqja grafike për të zgjedhur, për shembull, lidhjet Wi-Fi është thjesht një front për të.
Na nevojitet të shqyrtojmë konfigurimet e tij.
- Krijoni një skedar në /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Kujdesuni për pikën përpara evilcorp. Ajo i sinjalizon dnsmasq-it që të kërkojë të gjitha subdomainet e evilcorp.com pikërisht në DNS-në e kompanisë.
- Tregoni NetworkManager-it se për zgjidhjen e emrave duhet të përdorim dnsmasq.
Konfigurimi i network-manager-it ndodhet në /etc/NetworkManager/NetworkManager.conf. Duhet të shtoni atje:
[main]
dns=dnsmasq
- Rinisni NetworkManager-in.
service network-manager restartTani, pas lidhjes me VPN duke përdorur kombinimin openconnect dhe vpn-slice, ip do të identifikohet në mënyrë të saktë, madje edhe nëse nuk shtoni adresat simbolike në argumentet për vpnslice.
Si të qasemi përmes VPN në shërbime të veçanta.
Pas lidhjes me vpn, isha shumë i lumtur për dy ditë, pastaj kuptova se nëse lidhesha me VPN jo nga rrjeti i zyrës, posta nuk funksiononte. Simptoma është e njohur, a nuk është?
Posta jonë ndodhet në mail.publicevilcorp.com, dhe prandaj nuk përfshihet nën rregullin në dnsmasq dhe adresa e serverit të postes kërkohet përmes DNS-it publik.
Megjithatë, në zyrë akoma përdoret DNS-i, ku kjo adresë ekziston. Kështu mendoja. Në të vërtetë, pas shtimit të Linjës në dnsmasq.
address=/mail.publicevilcorp.com/192.168.430.534
situata nuk ndryshoi. Ip mbeti i njëjtë. Më duhej të shkoja në punë.
Dhe më pas, kur u thella në situatë dhe pak e kuptova problemin, një njeri i mençur më sugjeroi si ta zgjidhja atë. Duhej të lidheshja me serverin e postes jo thjesht, por përmes VPN.
Përdor vpn-slice për të kaluar përmes VPN në adresat që fillojnë me 192.168.430. Ndërsa adresa e serverit të postes jo vetëm që nuk është një subdomain i evilcorp, por gjithashtu adresa e tij ip nuk fillon me 192.168.430. Dhe nga rrjeti i përgjithshëm nuk pëlqen askënd.
Për të bërë që Linux të kalojë përmes VPN dhe në serverin e postes, nevojitet të shtohet në vpn-slice edhe ai. Supozoni se adresën e postes është 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 Scripti për ngritjen e VPN me një argument.
Sigurisht, kjo nuk është shumë e rehatshme. Po, mund ta ruash tekstin në një skedar dhe ta kopjosh në konsolë, në vend që ta shkruash manualisht, por prapë nuk është shumë këndshëm. Për ta lehtësuar procesin, mund të ndërtosh komandën në një skriptë që do të gjendet në PATH. Pastaj do të duhet vetëm të shkruash kodin e marrë nga 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 Nëse e vendos skriptën në connect~evilcorp~, mund të shkruash thjesht në konsolë.
connect_evil_corp 567987Por tani prapë do të duhet të mbash hapur konsolën ku është nisur openconnect.
Nisja e openconnect në sfond.
FatmirĂ«sisht, autorĂ«t e openconnect na kanĂ« menduar dhe kanĂ« shtuar njĂ« çelĂ«s tĂ« veçantĂ« nĂ« program âbackground, i cili bĂ«n qĂ« programi tĂ« punojĂ« nĂ« sfond pas nisjes. NĂ«se e nis kĂ«shtu, mund ta mbyllĂ«sh konsolĂ«n pas nisjes.
#!/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 Tani Ă«shtĂ« vetĂ«m e paqartĂ« se ku shkojnĂ« log-Ă«t. Log-Ă«t nĂ« pĂ«rgjithĂ«si nuk na duhen shumĂ«, por kush e di. Openconnect mund t'i drejtojĂ« ato nĂ« syslog, ku do tĂ« ruhen nĂ« integritet dhe siguri. Duhet ta shtosh kĂ«tĂ« nĂ« komandĂ« me çelĂ«sin â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 Dhe kĂ«shtu, duket se openconnect punon diku nĂ« sfond dhe nuk shqetĂ«son askĂ«nd, por si ta ndalosh Ă«shtĂ« e paqartĂ«. Mund ta filtrosh sigurisht daljen e procesit duke pĂ«rdorur ps dhe grep, por kjo Ă«shtĂ« disi e lodhshme. Faleminderit autorĂ«ve qĂ« e menduan edhe kĂ«tĂ«. NĂ« openconnect ka njĂ« çelĂ«s âpid-file, me ndihmĂ«n e tĂ« cilit mund tĂ« udhĂ«zosh openconnect tĂ« shkruajĂ« identifikatorin e procesit nĂ« njĂ« skedar.
#!/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-pidTani gjithmonë mund të vrasësh procesin me komandën.
kill $(cat ~/vpn-pid)Nëse procesi nuk ekziston, kill do të ankohesh, por nuk do të hedhë një gabim. Nëse skedari nuk ekziston, asgjë e keqe nuk do të ndodhi, kështu që mund ta vrasësh process-in në rreshtin e parë të skriptës.
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-pidTani mund ta ndizni kompjuterin, të hapni konsolën dhe të nisni komandën, duke i kaluar kodin nga Google Authenticator. Konsolën më pas mund ta vrasësh.
Pa vpn-slice. Në vend të epilogut.
Të kuptosh si të jetosh pa vpn-slice ka qenë shumë e vështirë. Iu desh të lexoj shumë dhe të kërkoj në Google. Me fat, kur kalove aq shumë kohë me problemin, manualet teknike dhe madje edhe man openconnect lexohen si romane emocionuese.
Në fund arrita të kuptoj se vpn-slice, si skripti origjinal, modifikon tabelën e-routing për të ndarë rrjetet.
Tabelë e-routing
Kjo, thjesht, është një tabelë në kolonen e parë që përmban se nga duhet të fillojë adresa për të cilën dëshiron të kalojë Linux, dhe në kolonën e dytë përmes cilit adapter rrjeti duhet të kalojë për këtë adresë. Në të vërtetë ka më shumë kolona, por kjo nuk ndryshon thelbin.
Për të parë tabelën e-routing, duhet të ekzekutoni komandën 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 Këtu, çdo rresht përgjigjet për atë se ku duhet të kalojë për të dërguar një mesazh për një adresë të caktuar. E para është përshkrimi se nga duhet të fillojë adresa. Për të kuptuar se si të përcaktoni që 192.168.0.0/16 do të thotë që adresa duhet të fillojë me 192.168, duhet të kërkoni në Google se çfarë është maska e adresës ip. Pas dev ndodhet emri i adapterit në të cilin duhet të dërgohet mesazhi.
Për VPN, Linux krijoi një adapter virtual - tun0. Rreshti që siguron që trafiku për të gjitha adresat që fillojnë me 192.168 kalon përmes tij është
192.168.0.0/16 dev tun0 scope link Po ashtu, mund të shikoni gjendjen aktuale të tabelës së-routing me komandën route -n (adresat IP janë talentuar me anomimizim) Kjo komandë jep rezultate në një format tjetër dhe është shumë e vjetër, por shpesh e gjejmë në manualet në internet dhe duhet të dimë ta lexojmë.
Nga çfarë duhet të fillojë adresa IP për rrugën mund të kuptohet nga kombinimi i kolonave Destination dhe Genmask. Ato pjesë të adresës IP, për të cilat në Genmask ka numra 255, merren parasysh, ndërsa ato ku ka 0 - jo. Pra, kombinimi Destination 192.168.0.0 dhe Genmask 255.255.255.0 do të thotë se nëse adresa fillon me 192.168.0, atëherë kërkesa për të do të kalojë përmes kësaj rruge. Ndërsa nëse Destination është 192.168.0.0, por Genmask 255.255.0.0, atëherë kërkesat për adresat që fillojnë me 192.168 do të kalojnë përmes kësaj rruge.
Për të kuptuar se çfarë bën në të vërtetë vpn-slice, vendosa të shikoj për ndasitë e tabelave para dhe pas
Para aktivizimit të VPN-së ishte kështu
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 wlp3s0Pas thirrjes së openconnect pa vpn-slice, erdhi kështu
rruga -n
Tabela e rutave të kernelit IP
Destinacioni Portë Maske e gjeneratës Flamuj Metric Ref PërdorimiIface
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 tun0Dhe pas thirrjes së openconnect në kombinim me vpn-slice e tillë
Tabela e rutave të kernelit IP
Destinacioni Portë Maske e gjeneratës Flamuj Metric Ref PërdorimiIface
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ĂshtĂ« evidente se nĂ«se nuk pĂ«rdoret vpn-slice, openconnect eksplicitisht shkruan se pĂ«r tĂ« gjitha adresat, pĂ«rveç atyre tĂ« specifikuara veçmas, duhet tĂ« kalojmĂ« pĂ«rmes vpn.
Ja këtu:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Aty pranë tregohet një rrugë tjetër, e cila duhet të përdoret, nëse adresa që përpiqet të kalojë Linux-i nuk përputhet me asnjë maskë nga tabela.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Këtu tashmë është shkruar se në një rast të tillë duhet të kalojmë përmes adapterit standard të Wi-Fi.
Mendoj se rrugën për VPN e përdorin sepse ajo është e para në tabelën e rutave.
Dhe te teorikisht, nëse heq këtë rrugë të paracaktuar nga tabela e rutave, në kombinim me dnsmasq openconnect duhet të sigurojë funksionimin normal.
Kam provuar
rruga fshij parazgjedhurDhe gjithçka funksionoi.
Rruga e kërkesave për serverin e postës pa vpn-slice
Por kam gjithashtu një server të postës me adresë 555.555.555.555, për të cilin duhet gjithashtu të kalojmë përmes vpn. Rruga për të duhet gjithashtu të shtohet manualisht.
ip rruga shto 555.555.555.555 përmes dev tun0Dhe tani gjithçka është normale. Pra, mund të kalojmë pa vpn-slice, por tashmë duhet të dimë mirë se çfarë bëjmë. Tani po mendoj të shtoj në rreshtin e fundit të skriptit origjinal të openconnect fshirjen e rrugës parazgjedhur dhe shtimin e rrugës për serverin e postës pas lidhjes me vpn, thjesht, që pjesët lëvizëse në biçikletën time të jenë pak më të pakta.
Ndoshta disa njerëz do të ishin të kënaqur me këtë pasthënie për të kuptuar se si të konfiguroni VPN-in. Por derisa përpiqesha të kuptoja se çfarë dhe si duhet të bëja, lexova shumë udhëzime të tilla, të cilat funksiononin për autorin, por për arsye të panjohura nuk funksiononin për mua, prandaj vendosa të shtoja këtu të gjitha copët që kam gjetur. Do të isha shumë i lumtur për një gjë të tillë.
Burimi: habr.com
