A doni të përdorni Linux në punë, por VPN-i i korporatës nuk lejon? Atëherë ky artikull mund t'ju ndihmojë, edhe pse nuk është e sigurt. Dua ta paralajmëroj që nuk kam njohuri të mëdha në administrimin e rrjeteve, prandaj është e mundur që mund të kem bërë gjithçka gabim. Nga ana tjetër, nuk përjashtohet që të jem në gjendje të shkruaj një udhëzues që do të jetë i kuptueshëm për njerëzit e zakonshëm, prandaj rekomandoj ta provoni.
Artikulli ka shumë informacione të panevojshme, por pa këto njohuri nuk do të mundja të zgjidhja problemet që papritur më shfaqeshin me konfigurimin e VPN-it. Mendoj se çdo person që do të përpiqet të zbatojë këtë udhëzues do të ketë probleme që unë nuk i kam pasur, dhe shpresoj se këto informacione të panevojshme do t'i ndihmojnë ata të zgjidhin këto probleme vetë.
Shumica e komandave të përdorura në udhëzues duhet të ekzekutohen përmes sudo, i cili është hequr për shkak të shkurtimit. Kini parasysh.
Shumica e adresave IP janĂ« maskuar fort, prandaj nĂ«se shihni njĂ« adresĂ« si 435.435.435.435 â duhet tĂ« jetĂ« ndonjĂ« adresĂ« IP normale, specifike pĂ«r rastin tuaj.
Kam unë Ubuntu 18.04, por mendoj se me disa përmirësime varianti mund të aplikohet edhe në distribucione të tjera. Megjithatë, në këtë tekst Linux == Ubuntu.
Cisco Connect
Ata që janë në Windows ose MacOS mund të lidhen me VPN-in tonë korporativ përmes Cisco Connect, për të cilin është e nevojshme të jepet adresa e portës dhe çdo herë që lidhen të fusin një fjalëkalim, që përbëhet nga një pjesë fikse dhe një kod që gjenerohet nga Google Authenticator.
Në rastin e Linuxit, nuk arrita të krijoj Cisco Connect, por udhëzimi për të përdorur openconnect, i krijuar pikërisht për të zëvendësuar Cisco Connect, arriti ta gjej.
Openconnect
Në teori, në Ubuntu ekziston një ndërfaqe grafike speciale për openconnect, por nuk më punoi. Ndoshta është më mirë kështu.
Në Ubuntu, openconnect instalojë nga menaxheri i paketave.
apt install openconnectMenjëherë pas instalimit, mund të provoni të lidheni me VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com është adresa e një VPN-i imagjinar
poxvuibr â emri i njĂ« pĂ«rdoruesi imagjinar
openconnect do tĂ« kĂ«rkojĂ« tĂ« jepni njĂ« fjalĂ«kalim, i cili, pĂ«r tâiu rikujtuar, pĂ«rbĂ«het nga njĂ« pjesĂ« fikse dhe njĂ« kod nga Google Authenticator, pastaj do tĂ« pĂ«rpiqet tĂ« lidhet me vpn. NĂ«se ka funksionuar, urime, mund tĂ« kaloni tĂ« mesmen, qĂ« ka shumĂ« dhimbje dhe tĂ« kaloni nĂ« pikĂ«n rreth funksionit tĂ« openconnect nĂ« sfond. NĂ«se nuk ka funksionuar, atĂ«herĂ« mund tĂ« vazhdoni. MegjithatĂ«, nĂ«se ka funksionuar me lidhjen, p.sh., nga njĂ« Wi-Fi i rastit nĂ« punĂ«, ndoshta Ă«shtĂ« herĂ«t pĂ«r tĂ« festuar, duhet ta provoni pĂ«rsĂ«ri nga shtĂ«pia.
Certifikata
Me shumë mundësi, asgjë nuk do të startojë, dhe të dhënat nga openconnect do të duken kështu:
POST https://vpn.evilcorp.com/
Lidhur me 777.777.777.777:443
Negocimi SSL me vpn.evilcorp.com
Verifikimi i certifikatës së serverit ka dështuar: nënshkruesi nuk u gjet
Certifikata nga serveri VPN "vpn.evilcorp.com" dështoi verifikimin.
Arsyeja: nënshkruesi nuk u gjet
Për ta besuar këtë server në të ardhmen, ndoshta shtoni këtë në komandën tuaj:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Shkruani 'po' për të pranuar, 'jo' për të abortuar; ndonjë gjë tjetër për të parë: fgets (stdin): Operacioni tani në progresNga njëra anë, kjo është e pakëndshme, sepse nuk u arrit lidhja me VPN, por nga ana tjetër është e qartë se si ta zgjidhni këtë problem.
Ky server na ka dërguar një certifikat, i cili mund të përcaktojë se po lidhemi me serverin e kompanisë, dhe jo me ndonjë mashtrues të keq, por ky certifikat nuk i është i njohur sistemit. Dhe prandaj ai nuk mund ta verifikojë nëse serveri është i vërtetë apo jo. Prandaj, për çdo rast, ai ndalon funksionimin.
PĂ«r tĂ« bĂ«rĂ« qĂ« openconnect tĂ« lidhet me serverin, duhet tĂ« i thuash nĂ« mĂ«nyrĂ« tĂ« qartĂ« cilin certifikat duhet tĂ« marrĂ« nga serveri VPN me pĂ«rdorimin e çelĂ«sit âservercert.
Dhe për të mësuar se cilin certifikat na dërgoi serveri, mund ta njohim direkt nga ajo që shkroi openconnect. Ja nga kjo pjesë:
Për ta besuar këtë server në të ardhmen, mbase shtoni këtë në linjën tuaj të komandës:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Shkruani 'yes' për të pranuar, 'no' për të anuluar; çdo gjë tjetër për të parë: fgets (stdin): Operacioni tani është në zhvillim.Me një komandë të tillë mund të provoni të lidheni përsëri.
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comNdoshta tani ka funksionuar, atëherë mund të kaloni në fund. Por personalisht, Ubuntu nuk e pranoi këtë në këtë formë.
POST https://vpn.evilcorp.com/
Konektuar në 777.777.777.777:443
Negociata SSL me vpn.evilcorp.com
Verifikimi i certifikatës së serverit dështoi: nënshkruesi nuk u gjet
Konektuar në HTTPS në vpn.evilcorp.com
XML POST aktivizuar
Ju lutemi 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, Mbajtja gjallë 30
Konfigurimi i DTLS dështoi; duke përdorur SSL në vend
Konektuar si 192.168.333.222, duke përdorur SSL
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
RTNETLINK jep përgjigje: Skedari ekziston
/etc/resolvconf/update.d/libc: Parabola: /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ë respektohet, por nuk do të mund të aksesosh atë. Adresa si jira.evilcorp.com nuk respektohet fare.
ĂfarĂ« ndodhi kĂ«tu, nuk e kuptoj. Por eksperimenti tregon se nĂ«se shton nĂ« /etc/resolv.conf rreshtin
nameserver 192.168.430.534atëherë adresat brenda VPN do të fillojnë të respektohen magjikisht dhe do të mund të aksesohen, që do të thotë se ajo që kërkon se si të respektohen adresat DNS, shikon pikërisht në /etc/resolv.conf, dhe jo diku tjetër.
Se lidhja me VPN është dhe funksionon, mund të konfirmohet edhe pa ndryshime në /etc/resolv.conf, mjafton të vendosni në shfletues një adresë IP në vend të emrit simbolik të burimit nga vpn.
Kështu që rezulton se ka dy probleme
- kur lidhemi me VPN, DNS-i i saj nuk njihet
- i gjithë trafiku kalon përmes VPN, e cila nuk lejon të shkojmë në internet
ĂfarĂ« duhet tĂ« bĂ«j do ta tregoj tani, por sĂ« pari pak automatizim.
Hyrja automatike e pjesës fikse të fjalëkalimit
Derisa tani, ka shumë mundësi që të keni futur fjalëkalimin të paktën pesë herë dhe kjo procedurë tashmë ju ka lodhur? Së pari, sepse fjalëkalimi është i gjatë, së dyti, sepse duhet të përfshihet në një interval të caktuar kohor.
Zgjidhja përfundimtare e problemit nuk është përfshirë në artikull, por mund të bëhet që pjesa fikse e fjalëkalimit të mos nevojitet të futet shumë herë.
TĂ« supozojmĂ«, pjesa fikse e fjalĂ«kalimit Ă«shtĂ« â fixedPassword, dhe pjesa nga Google Authenticator Ă«shtĂ« 567 987. E gjithĂ« fjalĂ«kalimi mund tĂ« dĂ«rgohet nĂ«pĂ«rmjet 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 te komanda e fundit të futur dhe të ndryshoni vetëm pjesën nga Google Authenticator.
VPN korporativ nuk lejon që të shfrytëzohet interneti.
Në përgjithësi, nuk është shumë e përshtatshme kur për të hyrë në Habr duhen përdorur kompjuterë të veçantë. Mungesa e mundësisë për të kopjuar dhe ngjitur nga StackOverflow mund të paralizojë punën, prandaj është e domosdoshme të bësh diçka.
Duhet tĂ« organizohet njĂ« mĂ«nyrĂ« qĂ« kur nevojitet tĂ« hyhet nĂ« burimin nga rrjeti i brendshĂ«m, Linux tĂ« kalojĂ« nĂ« VPN, dhe kur tĂ« hyhet nĂ« Habr â tĂ« kalojĂ« nĂ« internet.
Openconnect pas nisjes dhe vendosjes së lidhjes me VPN, ekzekuton një skenar të veçantë, i cili ndodhet në /usr/share/vpnc-scripts/vpnc-script. Në skenar të hyjnë disa variabla, dhe ai bën konfigurimin e VPN. Fatkeqësisht, nuk arrita të kuptoj se si të ndaja trafikët mes VPN-së korporatë dhe pjesës tjetër të internetit me anë të skenarit origjinal.
Duket se për njerëz si unë është zhvilluar utilita vpn-slice, e cila lejon dërgimin e trafikës përmes dy kanaleve pa bërë shumë punë. Pra, do të jetë e nevojshme të punohet, por nuk është e domosdoshme të jesh shaman.
Ndarja e trafikës me anë të vpn-slice
Së pari do t'ju duhet të instaloni vpn-slice, dhe do të duhet të merremi vetë me këtë. Nëse do të ketë pyetje në komentet, do të shkruaj një post të veçantë për këtë. Por është një program normal në Python, kështu që nuk duhet të ketë vështirësi. Unë e kam instaluar me ndihmën e virtualenv.
Pastaj, duhet tĂ« pĂ«rdorni utilitarin, duke pĂ«rdorur çelĂ«sin âscript pĂ«r tĂ« treguar openconnect, qĂ« nĂ« vend tĂ« skriptĂ«s standarde duhet 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 dĂ«rgohet njĂ« varg me komandĂ«n qĂ« duhet tĂ« thirret nĂ« vend tĂ« skriptĂ«s. ./bin/vpn-slice â rruga pĂ«r skedarin ekzekutiv vpn-slice 192.168.430.0/24 â maska e adresave, pĂ«r tĂ« cilat duhet tĂ« kaloni nĂ« vpn. KĂ«tu, ka tĂ« bĂ«jĂ« me faktin se nĂ«se adresa fillon me 192.168.430 â atĂ«herĂ« burimin me kĂ«tĂ« adresĂ« duhet ta kĂ«rkoni brenda vpn.
Tani situata duhet tĂ« jetĂ« gati normale. Gati. Tani mund tĂ« hyni nĂ« habr dhe mund tĂ« hyni nĂ« burimin e brendshĂ«m nĂ«pĂ«rmjet IP, por nuk mund tĂ« hyni nĂ« burimin e brendshĂ«m me emrin simbolik. NĂ«se pĂ«rcaktoni pĂ«rputhshmĂ«rinĂ« midis emrit simbolik dhe adresĂ«s nĂ« hosts â gjithçka duhet tĂ« funksionojĂ«. Dhe do tĂ« funksionojĂ«, derisa IP tĂ« ndryshojĂ«. Linux tani mund tĂ« lidhet me internetin ose me rrjetin e brendshĂ«m nĂ« varĂ«si tĂ« IP. Por pĂ«r tĂ« pĂ«rcaktuar adresĂ«n, pĂ«rsĂ«ri pĂ«rdoret DNS korporativ.
Problemi gjithashtu mund tĂ« shfaqet nĂ« kĂ«tĂ« mĂ«nyrĂ« â nĂ« punĂ« gjithçka Ă«shtĂ« nĂ« rregull, por nĂ« shtĂ«pi mund tĂ« hyni nĂ« burimet e brendshme vetĂ«m pĂ«rmes IP. Ky Ă«shtĂ« sepse kur jeni tĂ« lidhur me Wi-Fi korporativ, atĂ«herĂ« DNS pĂ«rdoret gjithashtu korporativ, dhe nĂ« tĂ« emrat simbolik nga VPN mund tĂ« zgjidhen, pavarĂ«sisht se kalimi pĂ«rmes njĂ« adrese tĂ« tillĂ« pa pĂ«rdorimin e VPN mbetet i pamundur.
Modifikimi automatik i skedarit hosts
Nëse vpn-slice e kërkon me mirësjellje, ai mund të shkojë në DNS pas ngritjes së VPN-së, të gjejë aty adresat IP të burimeve të nevojshme sipas emrave të tyre figurativë dhe t'i shkruajë ato në hosts. Pas fikjes së VPN-së, këto adresa do të hiqen nga hosts. Për këtë, duhet të kaloni emrat figurativë në vpn-slice si argumente. Ja si.
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 subdomain-eve në DNS që VPN-ja siguroi.
Nëse janë pak adresa brenda rrjetit, atëherë qasja me modifikimin automatik të skedarit hosts është krejtësisht funksionale. Por nëse ka shumë burime në rrjet, do t'ju nevojitet të shtoni vazhdimisht në skenarin rreshta si zoidberg.test.evilcorp.com, zoidberg është emri i një nga qëndrat testuese.
Por tani, kur kuptojmë pak më shumë se çfarë ndodh, kjo nevojë mund të eliminohet.
Nëse pas ngritjes së VPN-së shikoni në /etc/hosts, mund të shihni një rresht të tillë
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
Po ashtu, një rresht i ri u shtua në resolv.conf. Në përmbledhje, vpn-slice dikushrrinisht përcaktoi se ku ndodhet serveri DNS për vpn.
Tani duhet të bëjmë që për të mësuar adresën ip të emrit të domainit që përfundon me evilcorp.com, Linux të shkojë në DNS-në korporative, dhe nëse na duhet diçka tjetër, atëherë në default.
Kam kërkuar mjaft gjatë dhe kam zbuluar se një funksionalitet i tillë është i pranishëm në Ubuntu nga kutia. Bëhet fjalë për mundësinë për të përdorur një server lokal DNS si dnsmasq për zgjidhjen e emrave.
Pra, mund të bëjmë që Linux gjithmonë të kërkojë adresat ip në serverin lokal DNS, i cili nga ana e tij, në varësi të emrit të domainit, do të kërkojë ip në serverin përkatës të jashtëm DNS.
PĂ«r menaxhimin e gjithçkaje tĂ« lidhur me rrjetet dhe lidhjet rrjetĂ«, nĂ« Ubuntu pĂ«rdoret NetworkManager, dhe ndĂ«rfaqja grafike pĂ«r tĂ« zgjedhur, pĂ«r shembull, lidhjen Wi-Fi â Ă«shtĂ« thjesht njĂ« front pĂ«r tĂ«.
Na duhet të shfletojmë në konfigurimet e tij.
- Krijoni një skedar në /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Kujdesi për pikën përpara evilcorp. Ajo sinjalizon dnsmasq-në që të gjitha subdomainet e evilcorp.com duhet të kërkohen pikërisht në DNS-në korporative.
- Të themi NetworkManager-it që për zgjidhjen e emrave duhet të përdorim dnsmasq
Konfigurimi i network-manager ndodhet në /etc/NetworkManager/NetworkManager.conf Duhet të shtohet aty:
[main]
dns=dnsmasq
- Rinovoni NetworkManager-in
shërbimi network-manager restartTani, pas lidhjes me VPN nëpërmjet kombinimit openconnect dhe vpn-slice, ip do të identifikohet normalisht, 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 që arrita të lidhëm me vpn, isha shumë i lumtur për dy ditë, pastaj mësova se nëse lidhem me vpn jo nga rrjeti i zyrës, e-maili nuk funksionon. Simptoma është e njohur, apo jo?
E-maili ynë ndodhet në mail.publicevilcorp.com, dhe prandaj nuk bën pjesë nën rregullin në dnsmasq dhe adresa e serverit të e-mailit kërkohet përmes DNS publik.
Mirëpo, në zyrë ende përdoret DNS, ku kjo adresë ekziston. Pra, kështu e mendoja. Në realitet, pas shtimit në dnsmasq të rreshtit
address=/mail.publicevilcorp.com/192.168.430.534
situata nuk u ndryshua fare. ip mbeti i njëjtë. Më duhej të shkoja në punë.
Dhe vetëm më pas, kur u thellova në situatë dhe pak e kuptova problemin, një person i zgjuar më dha një këshillë se si ta zgjidhja. Duhej të lidhesha me serverin e e-mailit jo thjesht kështu, por përmes vpn.
Unë përdor vpn-slice për të kaluar përmes VPN në adresat që fillojnë me 192.168.430. Dhe për serverin e postës, jo vetëm që adresa e saj simbolike nuk është një subdomen i evilcorp, por adresa e saj IP gjithashtu nuk fillon me 192.168.430. Dhe sigurisht, ai nuk lejon askënd të hyjë nga rrjeti i përgjithshëm.
Për të lejuar Linux-in të kalojë përmes VPN dhe në serverin e postës, duhet ta shtoni atë në vpn-slice. Le të themi se adresa e postës ë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 Skripti për të ngitur VPN me një argument
Kjo, sigurisht, nuk është shumë e përshtatshme. Po, mund të ruani tekstin në një skedar dhe ta kopjoni në konsolë, në vend që ta shkruani me dorë, por sërish është pak e këndshme. Për të lehtësuar procesin, mund ta mbështjellni komandën në një skriptë, e cila do të ndodhet në PATH. Dhe atëherë do të nevojitet vetëm të futni 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 vendosni skriptin në connect~evilcorp~, atëherë do të mund të shkruani thjesht në konsolë.
connect_evil_corp 567987Por tani gjithsesi do të duhet të mbani hapur konsolën në të cilën është nisur openconnect.
Nisja e openconnect në sfond
Fatkeq autoret e openconnect kujdesĂ«n pĂ«r ne dhe shtuan njĂ« çelĂ«s tĂ« veçantĂ« nĂ« program âbackground, i cili bĂ«n qĂ« programi tĂ« punojĂ« nĂ« sfond pas nisjes. NĂ«se e filloni kĂ«shtu, atĂ«herĂ« konsolĂ«n mund ta mbyllni 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 vetĂ«m nuk Ă«shtĂ« e qartĂ« se ku shkojnĂ« logĂ«t. LogĂ«t nĂ« tĂ« vĂ«rtetĂ« nuk na nevojiten shumĂ«, por asnjĂ«herĂ« nuk dihet. Openconnect mund t'i drejtojĂ« ato nĂ« syslog, ku do tĂ« ruhet nĂ« mĂ«nyrĂ« tĂ« sigurt. Duhet ta shtojmĂ« 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, rezulton qĂ« openconnect punon diku aty nĂ« sfond dhe nuk shqetĂ«son askĂ«nd, por si ta ndalosh Ă«shtĂ« e paqartĂ«. Sigurisht, mund tĂ« filtroni daljen e ps me grep dhe tĂ« kĂ«rkoni procesin qĂ« ka openconnect nĂ« emrin e tij, por kjo Ă«shtĂ« disi e komplikuar. Faleminderit autorĂ«ve qĂ« kanĂ« menduar edhe pĂ«r kĂ«tĂ«. NĂ« openconnect ka njĂ« çelĂ«s âpid-file, me tĂ« cilin mund tĂ« udhĂ«zoni openconnect tĂ« shkruajĂ« identifikuesin e procesit tĂ« tij 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 ta ndaloni procesin me komandën
kill $(cat ~/vpn-pid)Nëse procesi nuk ekziston, kill do të bëjë një zhurmë, por nuk do të hedhë një gabim. Nëse skedari nuk ekziston, asgjë e keqe nuk do të ndodhë, pra mund të vrasim procesin në rreshtin e parë të skriptit.
vrit $(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 të ndizni kompjuterin, hapni konsolën dhe ekzekutoni komandën, duke i kaluar asaj kodin nga Google Authenticator. Më pas, konsolën mund ta merrni.
Pa vpn-slice. Në vend të pasthënies.
Të kuptosh si të jetosh pa vpn-slice doli shumë e vështirë. Duhej të lexoja shumë dhe të gjuaja në Google. Fatmirësisht, kur kalova kaq shumë kohë me problemin, manualet teknike dhe madje edhe man openconnect lexoheshin si romane intriguese.
Në fund, munda të zbuloj se vpn-slice, si dhe skripti i tij origjinal, modifikon tabelën e rrugëve për të ndarë rrjetet.
Tabela e rrugëve
Kjo, thjesht e thënë, është një tabelë në të cilën kolona e parë përmban nga çfarë duhet të fillojë adresa që Linux dëshiron të kalojë, dhe në kolonën e dytë përmes cilit adapter rrjeti duhet të kalojë në këtë adresë. Në të vërtetë ka më shumë kolona, por kjo nuk e ndryshon thelbin.
Për të parë tabelën e rrugëve, 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 tregon se ku duhet të kalosh për të dërguar një mesazh në një adresë të caktuar. E para vjen përshkrimi i asaj me çfarë duhet të fillojë adresa. Për të kuptuar se si të përcaktohet që 192.168.0.0/16 tregon se adresa duhet të fillojë me 192.168 duhet të kërkosh në Google se çfarë është maska e IP adresës. Pas dev gjendet emri i adapterit në të cilin duhet të dërgohet mesazhi.
PĂ«r VPN, Linux krijoi njĂ« adapter virtual â tun0. Rreshti qĂ« siguron qĂ« trafik pĂ«r tĂ« gjitha adresat qĂ« fillojnĂ« me 192.168 tĂ« kalojĂ« pĂ«rmes tij Ă«shtĂ«
192.168.0.0/16 dev tun0 scope link Po ashtu, mund të shohësh gjendjen aktuale të tabelës së rrugëve duke përdorur komandën route -n (IP adresat janë anonimizuar mjeshtërisht) Kjo komandë jep rezultate në një format tjetër dhe është dekurajuar, por dalja e saj shpesh shfaqet në manuale në internet dhe duhet të dish ta lexosh.
Pjesa e parë e adresës IP për rrugën mund të kuptohet nga kombinimi i kolonave Destination dhe Genmask. Pjesët e adresës IP që përputhen me numrat 255 në Genmask merren parasysh, ndërsa ato që kanë 0 jo. Kështu, kombinimi Destination 192.168.0.0 dhe Genmask 255.255.255.0 do të thotë që nëse adresa fillon me 192.168.0, kërkesa për të do të shkojë përmes kësaj rruge. Ndërsa nëse Destination është 192.168.0.0 dhe Genmask 255.255.0.0, atëherë kërkesat për adresat që fillojnë me 192.168 do të ndjekin këtë rrugë.
Për të kuptuar se çfarë bën me të vërtetë vpn-slice, vendosa të shikoj gjendjen e tabelave para dhe pas.
Para aktivizimit të VPN-së ishte kështu.
route -n
Tabela e routing-ut të kernelit të IP
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, tani është kështu.
rreth -n
Tabela e routing të Kernel IP
Destinacion 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 tun0Dhe pas thirrjes openconnect në kombinim me vpn-slice kështu
Tabela e routing të Kernel IP
Destinacion Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0
222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0
333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0
192.168.430.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.430.534 0.0.0.0 255.255.255.255 UH 0 0 0 tun0ĂshtĂ« e qartĂ« se nĂ«se nuk pĂ«rdoret vpn-slice, openconnect shprehimisht shkruan se pĂ«r tĂ« gjitha adresat, pĂ«rveç atyre qĂ« janĂ« specifikuar veçmas, duhet tĂ« kaloni pĂ«rmes vpn.
KĂ«tu:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Menjëherë është specifikuar një rrugë tjetër që duhet të përdoret, nëse adresa, për të cilën përpiqet të kalojë Linux, 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 është thënë se në këtë rast duhet të kaloni përmes adaptorit standard të Wi-Fi.
Mendoj se rruge për VPN përdoret sepse është e para në tabelën e rrugëve.
Dhe teorikisht, nëse hiqet kjo rrugë defaut nga tabela e rrugëve, atëherë në kombinim me dnsmasq, openconnect duhet të sigurojë funksionimin normal.
Kam provuar
route del defaultDhe çdo gjë funksionoi.
Rrugëtimi i kërkesave për serverin e postës pa vpn-slice
Por unë kam gjithashtu një server poƥte me adresën 555.555.555.555, për të cilin gjithashtu duhet të kaloj përmes vpn. Rruga për të gjithashtu duhet të shtohet manualisht.
ip route add 555.555.555.555 via dev tun0Dhe tani çdo gjë është në rregull. Pra, mund të kaloj pa vpn-slice, por tani duhet të di mirë se çfarë po bëj. Po mendoj të mos e shtoj në rreshtin e fundit të skriptit të paracaktuar të openconnect heqjen e rrugës defaut dhe shtimin e rrugës për postën pas lidhjes me vpn, thjesht që pjesët në lëvizje në biçikletën time të bëhen më pak.
Ndoshta, dikujt për të kuptuar se si të konfiguroni VPN, ka mjaftuar kjo epilog. Por unë, ndërsa përpiqesha të kuptoja se çfarë dhe si të bëj, lexova mjaft shumë udhëzime të tilla që funksionojnë për autorin, por për një arsye apo tjetër nuk funksionojnë për mua dhe vendosa të shtoja këtu të gjitha copëzat që gjetëm. Unë do të isha shumë i lumtur për diçka të tillë.
Burimi: habr.com
