Dëshironi të përdorni Linux në punë, por VPN e korporatës nuk ju lejon? Atëherë ky artikull mund të ndihmojë, megjithëse kjo nuk është e sigurt. Do të doja t'ju paralajmëroja paraprakisht se nuk i kuptoj mirë çështjet e administrimit të rrjetit, kështu që ka mundësi që të bëra gjithçka gabim. Nga ana tjetër, ka mundësi që të shkruaj një udhëzues në atë mënyrë që të jetë i kuptueshëm për njerëzit e zakonshëm, ndaj ju këshilloj ta provoni.

Artikulli përmban shumë informacione të panevojshme, por pa këtë njohuri nuk do të kisha mundur të zgjidhja problemet që m'u shfaqën papritur me vendosjen e një VPN. Mendoj se kushdo që do të përpiqet të përdorë këtë udhëzues do të ketë probleme që unë nuk i kam pasur dhe shpresoj se ky informacion shtesë do të ndihmojë në zgjidhjen e këtyre problemeve vetë.

Shumica e komandave të përdorura në këtë udhëzues duhet të ekzekutohen përmes sudo, e cila është hequr për shkurtësi. Mbani parasysh.

Shumica e adresave IP janë turbulluar rëndë, kështu që nëse shihni një adresë si 435.435.435.435, duhet të ketë një IP normale atje, specifike për rastin tuaj.

Unë kam Ubuntu 18.04, por mendoj se me ndryshime të vogla udhëzuesi mund të zbatohet në shpërndarjet e tjera. Megjithatë, në këtë tekst Linux == Ubuntu.

Cisco Connect

Ata që janë në Windows ose MacOS mund të lidhen me VPN-në tonë të korporatës nëpërmjet Cisco Connect, e cila duhet të specifikojë adresën e portës dhe, sa herë që lidheni, të futni një fjalëkalim të përbërë nga një pjesë fikse dhe një kod i krijuar nga Google Authenticator.

Në rastin e Linux-it, nuk munda ta aktivizoja Cisco Connect, por arrita të kërkoja në google një rekomandim për të përdorur openconnect, i bërë posaçërisht për të zëvendësuar Cisco Connect.

Hap lidhjen

Në teori, Ubuntu ka një ndërfaqe të veçantë grafike për openconnect, por nuk funksionoi për mua. Ndoshta është për mirë.

Në Ubuntu, openconnect është instaluar nga menaxheri i paketave.

apt install openconnect

Menjëherë pas instalimit, mund të provoni të lidheni me një VPN

openconnect --user poxvuibr vpn.evilcorp.com

vpn.evilcorp.com është adresa e një VPN fiktive
poxvuibr - emër përdoruesi fiktiv

openconnect do t'ju kërkojë të vendosni një fjalëkalim, i cili, më lejoni t'ju kujtoj, përbëhet nga një pjesë fikse dhe një kod nga Google Authenticator, dhe më pas do të përpiqet të lidhet me vpn. Nëse funksionon, urime, mund të kaloni me siguri mesin, që është shumë dhimbje, dhe të kaloni në pikën rreth funksionimit të openconnect në sfond. Nëse nuk funksionon, atëherë mund të vazhdoni. Edhe pse nëse funksionoi gjatë lidhjes, për shembull, nga një Wi-Fi i ftuar në punë, atëherë mund të jetë shumë herët për t'u gëzuar; duhet të përpiqeni të përsërisni procedurën nga shtëpia.

certifikatë

Ekziston një probabilitet i lartë që asgjë të mos fillojë dhe dalja e openconnect do të duket diçka si kjo:

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 progress

Nga njëra anë, kjo është e pakëndshme, sepse nuk kishte asnjë lidhje me VPN, por nga ana tjetër, si ta rregulloni këtë problem është, në parim, e qartë.

Këtu serveri na dërgoi një certifikatë, me anë të së cilës ne mund të përcaktojmë se lidhja është duke u bërë me serverin e korporatës sonë amtare, dhe jo me një mashtrues të lig, dhe kjo certifikatë është e panjohur për sistemin. Dhe për këtë arsye ajo nuk mund të kontrollojë nëse serveri është i vërtetë apo jo. Dhe kështu, për çdo rast, ai ndalon së punuari.

Në mënyrë që openconnect të lidhet me serverin, duhet t'i tregoni në mënyrë eksplicite se cila certifikatë duhet të vijë nga serveri VPN duke përdorur çelësin —servercert

Dhe mund të zbuloni se cilën certifikatë na dërgoi serveri drejtpërdrejt nga ajo që printoi openconnect. Ja nga kjo pjesë:

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 progress

Me këtë komandë mund të provoni të lidheni përsëri

openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com

Ndoshta tani po funksionon, atëherë mund të vazhdoni deri në fund. Por personalisht, Ubunta më tregoi një fik në këtë formë

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.com

habr.com do të zgjidhet, por nuk do të mund të shkoni atje. Adresat si jira.evilcorp.com nuk zgjidhen fare.

Ajo që ndodhi këtu nuk është e qartë për mua. Por eksperimenti tregon se nëse shtoni rreshtin në /etc/resolv.conf

nameserver 192.168.430.534

atëherë adresat brenda VPN do të fillojnë të zgjidhen në mënyrë magjike dhe ju mund të kaloni nëpër to, domethënë, ajo që kërkon DNS për të zgjidhur adresat duket në mënyrë specifike në /etc/resolv.conf, dhe jo diku tjetër.

Mund të verifikoni që ka një lidhje me VPN dhe funksionon pa bërë asnjë ndryshim në /etc/resolv.conf; për ta bërë këtë, thjesht shkruani në shfletues jo emrin simbolik të burimit nga VPN, por adresën e tij IP.

Si rezultat, ka dy probleme

Kur lidheni me një VPN, dns-ja e tij nuk merret
i gjithë trafiku kalon përmes VPN, i cili nuk lejon hyrjen në internet

Unë do t'ju them se çfarë të bëni tani, por së pari pak automatizim.

Futja automatike e pjesës fikse të fjalëkalimit

Deri tani, ka shumë të ngjarë të keni futur fjalëkalimin tuaj të paktën pesë herë dhe kjo procedurë tashmë ju ka lodhur. Së pari, sepse fjalëkalimi është i gjatë, dhe së dyti, sepse kur futni duhet të përshtateni brenda një periudhe kohore të caktuar

Zgjidhja përfundimtare e problemit nuk u përfshi në artikull, por mund të siguroheni që pjesa fikse e fjalëkalimit nuk duhet të futet shumë herë.

Le të themi se pjesa fikse e fjalëkalimit është fixedPassword, dhe pjesa nga Google Authenticator është 567 987. I gjithë fjalëkalimi mund të kalohet në openconnect nëpërmjet hyrjes standarde duke përdorur argumentin --passwd-on-stdin .

echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdin

Tani mund të ktheheni vazhdimisht te komanda e fundit e futur dhe të ndryshoni vetëm një pjesë të Google Authenticator atje.

Një VPN e korporatës nuk ju lejon të lundroni në internet.

Në përgjithësi, nuk është shumë e papërshtatshme kur duhet të përdorni një kompjuter të veçantë për të shkuar në Habr. Pamundësia për të kopjuar-ngjitur nga stackoverfow në përgjithësi mund të paralizojë punën, kështu që diçka duhet bërë.

Ne duhet ta organizojmë disi atë në mënyrë që kur të duhet të hysh në një burim nga rrjeti i brendshëm, Linux të shkojë në VPN dhe kur të duhet të shkosh në Habr, të shkojë në internet.

openconnect, pasi nis dhe vendos një lidhje me vpn, ekzekuton një skript të veçantë, i cili ndodhet në /usr/share/vpnc-scripts/vpnc-script. Disa variabla i kalohen skriptit si hyrje dhe ai konfiguron VPN-në. Fatkeqësisht, nuk mund të kuptoja se si të ndaja flukset e trafikut midis një VPN të korporatës dhe pjesës tjetër të Internetit duke përdorur një skript vendas.

Me sa duket, mjeti vpn-slice u zhvillua veçanërisht për njerëz si unë, i cili ju lejon të dërgoni trafik përmes dy kanaleve pa kërcyer me një dajre. Epo, domethënë, do të duhet të kërcesh, por nuk duhet të jesh shaman.

Ndarja e trafikut duke përdorur vpn-slice

Së pari, do të duhet të instaloni vpn-slice, do të duhet ta kuptoni vetë këtë. Nëse ka pyetje në komente, unë do të shkruaj një postim të veçantë për këtë. Por ky është një program i rregullt Python, kështu që nuk duhet të ketë ndonjë vështirësi. Kam instaluar duke përdorur virtualenv.

Dhe pastaj programi duhet të aplikohet, duke përdorur çelësin -script, duke treguar për të hapur lidhjen që në vend të skriptit standard, duhet të përdorni 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

--skriptit i kalohet një varg me një komandë që duhet të thirret në vend të skriptit. ./bin/vpn-slice - shtegu drejt skedarit të ekzekutueshëm vpn-slice 192.168.430.0/24 - maskë adresash për të shkuar në vpn. Këtu nënkuptojmë që nëse adresa fillon me 192.168.430, atëherë burimi me këtë adresë duhet të kërkohet brenda VPN

Tani situata duhet të jetë pothuajse normale. Pothuajse. Tani mund të shkoni te Habr dhe mund të shkoni te burimi brenda korporatës me ip, por nuk mund të shkoni te burimi brenda korporatës me emër simbolik. Nëse specifikoni një përputhje midis emrit simbolik dhe adresës në host, gjithçka duhet të funksionojë. Dhe punoni derisa të ndryshojë ip. Linux tani mund të hyjë në internet ose në intranet, në varësi të IP-së. Por DNS jo-korporative përdoret ende për të përcaktuar adresën.

Problemi gjithashtu mund të shfaqet në këtë formë - në punë gjithçka është në rregull, por në shtëpi mund të përdorni vetëm burimet e brendshme të korporatës përmes IP. Kjo sepse kur jeni i lidhur me Wi-Fi të korporatës, përdoret gjithashtu DNS i korporatës dhe adresat simbolike nga VPN zgjidhen në të, pavarësisht se është ende e pamundur të shkosh në një adresë të tillë pa përdorur një VPN.

Modifikimi automatik i skedarit të hosteve

Nëse vpn-slice kërkohet me mirësjellje, atëherë pas ngritjes së VPN-së, ai mund të shkojë në DNS-në e tij, të gjejë aty adresat IP të burimeve të nevojshme me emrat e tyre simbolikë dhe t'i futë ato në host. Pas çaktivizimit të VPN-së, këto adresa do të hiqen nga hostet. Për ta bërë këtë, ju duhet të kaloni emra simbolikë në vpn-slice si argumente. Si kjo.

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 për adresat e të gjitha nëndomaineve në DNS të dhëna nga VPN

Nëse ka pak adresa brenda rrjetit, atëherë qasja e modifikimit automatik të skedarit të hosteve funksionon mjaft mirë. Por nëse ka shumë burime në rrjet, atëherë vazhdimisht do t'ju duhet të shtoni linja si zoidberg.test.evilcorp.com në skenarin zoidberg është emri i një prej grupeve të testimit.

Por tani që e kuptojmë pak pse kjo nevojë mund të eliminohet.

Nëse, pas ngritjes së VPN-së, shikoni në /etc/hosts, mund ta shihni këtë rresht

192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOKRIUAR

Dhe një linjë e re u shtua në resolv.conf. Me pak fjalë, vpn-slice përcaktoi disi se ku ndodhet serveri dns për vpn.

Tani duhet të sigurohemi që për të gjetur adresën IP të një emri domeni që mbaron në evilcorp.com, Linux shkon në DNS të korporatës, dhe nëse nevojitet diçka tjetër, atëherë në atë të paracaktuar.

Kërkova në Google për mjaft kohë dhe zbulova se një funksionalitet i tillë është i disponueshëm në Ubuntu jashtë kutisë. Kjo do të thotë aftësia për të përdorur serverin lokal DNS dnsmasq për të zgjidhur emrat.

Kjo do të thotë, mund të siguroheni që Linux të shkojë gjithmonë te serveri lokal DNS për adresat IP, i cili nga ana tjetër, në varësi të emrit të domenit, do të kërkojë IP-në në serverin përkatës të jashtëm DNS.

Për të menaxhuar gjithçka që lidhet me rrjetet dhe lidhjet e rrjetit, Ubuntu përdor NetworkManager dhe ndërfaqja grafike për zgjedhjen, për shembull, lidhjet Wi-Fi është vetëm një pjesë e përparme e tij.

Ne do të duhet të ngjitemi në konfigurimin e tij.

Krijo një skedar në /etc/NetworkManager/dnsmasq.d/evilcorp

adresa=/.evilcorp.com/192.168.430.534

Kushtojini vëmendje pikës përballë evilcorp. Ai sinjalizon dnsmasq që të gjitha nëndomenet e evilcorp.com duhet të kërkohen në dns të korporatës.

Thuaji NetworkManager të përdorë dnsmasq për zgjidhjen e emrit

Konfigurimi i menaxherit të rrjetit ndodhet në /etc/NetworkManager/NetworkManager.conf Ju duhet të shtoni atje:

[kryesore] dns=dnsmasq

Rinisni NetworkManager

service network-manager restart

Tani, pas lidhjes me një VPN duke përdorur openconnect dhe vpn-slice, ip-ja do të përcaktohet normalisht, edhe nëse nuk shtoni adresa simbolike në argumentet në vpnslice.

Si të aksesoni shërbimet individuale përmes VPN

Pasi arrita të lidhem me VPN, isha shumë i lumtur për dy ditë, dhe më pas doli që nëse lidhem me VPN nga jashtë rrjetit të zyrës, atëherë posta nuk funksionon. Simptoma është e njohur, apo jo?

Posta jonë ndodhet në mail.publicevilcorp.com, që do të thotë se nuk bie nën rregullin në dnsmasq dhe adresa e serverit të postës kërkohet përmes DNS publike.

Epo, zyra ende përdor DNS, i cili përmban këtë adresë. Kështu mendova. Në fakt, pas shtimit të linjës në dnsmasq

adresa=/mail.publicevilcorp.com/192.168.430.534

situata nuk ka ndryshuar fare. ip mbeti i njëjtë. Më duhej të shkoja në punë.

Dhe vetëm më vonë, kur u futa më thellë në situatë dhe e kuptova pak problemin, një person i zgjuar më tha se si ta zgjidhja atë. Ishte e nevojshme të lidheshim me serverin e postës jo vetëm ashtu, 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 serveri i postës jo vetëm që ka një adresë simbolike që nuk është një nëndomain i evilcorp, por gjithashtu nuk ka një adresë IP që fillon me 192.168.430. Dhe sigurisht që ai nuk lejon askënd nga rrjeti i përgjithshëm të vijë tek ai.

Në mënyrë që Linux të kalojë përmes VPN-së dhe te serveri i postës, duhet ta shtoni edhe atë në vpn-slice. Le të themi se adresa e postuesit ë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

Skript për ngritjen e VPN me një argument

E gjithë kjo, natyrisht, nuk është shumë e përshtatshme. Po, mund ta ruani tekstin në një skedar dhe ta kopjoni-ngjisni në tastierë në vend që ta shtypni me dorë, por gjithsesi nuk është shumë e këndshme. Për ta bërë procesin më të lehtë, mund ta mbështillni komandën në një skript që do të vendoset në PATH. Dhe atëherë do t'ju duhet 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~, thjesht mund të shkruani në tastierë

connect_evil_corp 567987

Por tani ju duhet ta mbani ende të hapur tastierën në të cilën openconnect po funksionon për ndonjë arsye

Openconnect po ekzekutohet në sfond

Për fat të mirë, autorët e openconnect u kujdesën për ne dhe shtuan një çelës të veçantë në sfondin e programit, i cili e bën programin të funksionojë në sfond pas nisjes. Nëse e përdorni në këtë mënyrë, mund ta mbyllni tastierë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 thjesht nuk është e qartë se ku shkojnë regjistrat. Në përgjithësi, ne nuk kemi vërtet nevojë për regjistra, por nuk i dihet kurrë. openconnect mund t'i ridrejtojë ato në syslog, ku do të mbahen të sigurta dhe të sigurta. duhet të shtoni në komandë ç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 se openconnect po funksionon diku në sfond dhe nuk shqetëson askënd, por nuk është e qartë se si ta ndalojë atë. Kjo do të thotë, ju, natyrisht, mund të filtroni daljen e ps duke përdorur grep dhe të kërkoni një proces emri i të cilit përmban openconnect, por kjo është disi e lodhshme. Faleminderit edhe autorëve që menduan për këtë. Openconnect ka një çelës -pid-file, me të cilin mund të udhëzoni openconnect të shkruajë identifikuesin e tij të 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-pid

Tani gjithmonë mund të vrasësh një proces me komandën

kill $(cat ~/vpn-pid)

Nëse nuk ka proces, vrasja do të mallkojë, por nuk do të hedhë një gabim. Nëse skedari nuk është atje, atëherë asgjë e keqe nuk do të ndodhë, kështu që ju mund ta vrisni me siguri procesin në rreshtin e parë të skenarit.

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-pid

Tani mund të ndizni kompjuterin tuaj, të hapni tastierën dhe të ekzekutoni komandën, duke i kaluar kodin nga Google Authenticator. Konsola më pas mund të gozhdohet.

Pa një copë VPN. Në vend të një pasthënieje

Doli të ishte shumë e vështirë të kuptosh se si të jetosh pa fetë VPN. Më duhej të lexoja dhe të kërkoja shumë në google. Për fat të mirë, pasi keni kaluar kaq shumë kohë me një problem, manualet teknike dhe madje edhe njeriu openconnect lexojnë si romane emocionuese.

Si rezultat, zbulova se vpn-slice, si skripti vendas, modifikon tabelën e rrugëzimit në rrjete të veçanta.

Tabela e rrugëtimit

Për ta thënë thjesht, kjo është një tabelë në kolonën e parë e cila përmban se me çfarë duhet të fillojë adresa që Linux dëshiron të kalojë, dhe në kolonën e dytë se cili përshtatës rrjeti duhet të kalojë në këtë adresë. Në fakt, ka më shumë folës, por kjo nuk e ndryshon thelbin.

Për të parë tabelën e rrugëzimit, 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 linjë është përgjegjëse për vendin ku duhet të shkoni për të dërguar një mesazh në një adresë. E para është një përshkrim se ku duhet të fillojë adresa. Për të kuptuar se si të përcaktoni se 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 është emri i përshtatësit në të cilin duhet të dërgohet mesazhi.

Për VPN, Linux bëri një përshtatës virtual - tun0. Linja siguron që trafiku për të gjitha adresat që fillojnë me 192.168 të kalojë përmes saj

192.168.0.0/16 dev tun0 scope link

Ju gjithashtu mund të shikoni gjendjen aktuale të tabelës së rrugëtimit duke përdorur komandën rruga -n (Adresat IP janë anonimizuar me zgjuarsi) Kjo komandë prodhon rezultate në një formë tjetër dhe përgjithësisht është e vjetëruar, por prodhimi i saj shpesh gjendet në manualet në internet dhe ju duhet të jeni në gjendje ta lexoni atë.

Ku duhet të fillojë adresa IP për një rrugë mund të kuptohet nga kombinimi i kolonave Destinacioni dhe Genmask. Ato pjesë të adresës IP që korrespondojnë me numrat 255 në Genmask merren parasysh, por ato ku ka 0 jo. Kjo do të thotë, kombinimi i Destinacionit 192.168.0.0 dhe Genmask 255.255.255.0 do të thotë që nëse adresa fillon me 192.168.0, atëherë kërkesa për të do të shkojë përgjatë kësaj rruge. Dhe nëse Destinacioni 192.168.0.0 por Genmask 255.255.0.0, atëherë kërkesat për adresat që fillojnë me 192.168 do të shkojnë përgjatë kësaj rruge

Për të kuptuar se çfarë bën në të vërtetë vpn-slice, vendosa të shikoj gjendjet e tabelave para dhe pas

Përpara se të ndizni VPN-në 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 wlp3s0

Pasi thirri openconnect pa vpn-slice u bë kështu

route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 tun0
0.0.0.0         222.222.222.1   0.0.0.0         UG    600    0        0 wlp3s0
222.222.222.0   0.0.0.0         255.255.255.0   U     600    0        0 wlp3s0
333.333.333.333 222.222.222.1   255.255.255.255 UGH   0      0        0 wlp3s0
192.168.430.0   0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.430.534 0.0.0.0         255.255.255.255 UH    0      0        0 tun0

Dhe pasi telefononi openconnect në kombinim me vpn-slice si kjo

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 tun0

Mund të shihet se nëse nuk përdorni vpn-slice, atëherë openconnect shkruan në mënyrë eksplicite se të gjitha adresat, përveç atyre të treguara në mënyrë specifike, duhet të aksesohen përmes vpn.

Mu ketu:

0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 tun0

Aty, pranë tij, tregohet menjëherë një rrugë tjetër, e cila duhet të përdoret nëse adresa që Linux po përpiqet të kalojë nuk përputhet me asnjë maskë nga tabela.

0.0.0.0         222.222.222.1   0.0.0.0         UG    600    0        0 wlp3s0

Është shkruar tashmë këtu se në këtë rast duhet të përdorni një përshtatës standard Wi-Fi.

Besoj se shtegu VPN përdoret sepse është i pari në tabelën e rrugëzimit.

Dhe teorikisht, nëse e hiqni këtë shteg të paracaktuar nga tabela e rrugëzimit, atëherë së bashku me dnsmasq openconnect duhet të sigurojë funksionimin normal.

u përpoqa

route del default

Dhe gjithçka funksionoi.

Drejtimi i kërkesave në një server poste pa vpn-slice

Por unë kam edhe një server mail me adresën 555.555.555.555, i cili gjithashtu duhet të aksesohet përmes VPN. Rruga drejt tij gjithashtu duhet të shtohet manualisht.

ip route add 555.555.555.555 via dev tun0

Dhe tani gjithçka është në rregull. Kështu që ju mund të bëni pa vpn-slice, por duhet të dini mirë se çfarë po bëni. Tani po mendoj të shtoj në rreshtin e fundit të skriptit origjinal të openconnect heqjen e rrugës së paracaktuar dhe të shtoj një rrugë për postuesin pas lidhjes me vpn, vetëm në mënyrë që të ketë më pak pjesë lëvizëse në biçikletën time.

Ndoshta, kjo pasthënie do të mjaftonte që dikush të kuptojë se si të konfigurojë një VPN. Por ndërsa po përpiqesha të kuptoja se çfarë dhe si të bëja, lexova mjaft udhëzues të tillë që funksionojnë për autorin, por për disa arsye nuk funksionojnë për mua, dhe vendosa të shtoj këtu të gjitha pjesët që gjeta. Do të isha shumë i lumtur për diçka të tillë.

Burimi: www.habr.com

Si të lidheni me një VPN të korporatës në Linux duke përdorur openconnect dhe vpn-slice