Kā izveidot savienojumu ar korporatīvo VPN operētājsistēmā Linux, izmantojot openconnect un vpn-slice

Vai vēlaties izmantot Linux darbā, bet jÅ«su uzņēmuma VPN to neļaus? Tad Å”is raksts var palÄ«dzēt, lai gan tas nav droÅ”i. Jau iepriekÅ” vēlos brÄ«dināt, ka labi nesaprotu tÄ«kla administrÄ“Å”anas jautājumus, tāpēc, iespējams, ka visu izdarÄ«ju nepareizi. No otras puses, iespējams, ka es varu uzrakstÄ«t ceļvedi tā, lai tas bÅ«tu saprotams parastajiem cilvēkiem, tāpēc iesaku to izmēģināt.

Rakstā ir daudz nevajadzÄ«gas informācijas, taču bez Ŕīm zināŔanām es nebÅ«tu varējis atrisināt problēmas, kas man negaidÄ«ti parādÄ«jās ar VPN iestatÄ«Å”anu. Es domāju, ka ikvienam, kurÅ” mēģinās izmantot Å”o rokasgrāmatu, bÅ«s problēmas, kuras man nebija, un es ceru, ka Ŕī papildu informācija palÄ«dzēs atrisināt Ŕīs problēmas paÅ”as no sevis.

Lielākā daļa Å”ajā rokasgrāmatā izmantoto komandu ir jāpalaiž, izmantojot sudo, kas Ä«suma labad ir noņemta. Paturi prātā.

Lielākā daļa IP adreÅ”u ir nopietni aizsegtas, tādēļ, ja redzat adresi, piemēram, 435.435.435.435, tur ir jābÅ«t kādai parastai IP adresei, kas ir raksturÄ«ga jÅ«su gadÄ«jumam.

Man ir Ubuntu 18.04, bet es domāju, ka ar nelielām izmaiņām ceļvedi var piemērot citiem izplatÄ«jumiem. Tomēr Å”ajā tekstā Linux == Ubuntu.

Cisco Connect

Tie, kas izmanto operētājsistēmu Windows vai MacOS, var izveidot savienojumu ar mūsu korporatīvo VPN, izmantojot Cisco Connect, kuram ir jānorāda vārtejas adrese un ikreiz, kad izveidojat savienojumu, jāievada parole, kas sastāv no fiksētas daļas un Google autentifikatora ģenerēta koda.

Linux gadÄ«jumā es nevarēju palaist Cisco Connect, bet man izdevās Google ieteikums izmantot openconnect, kas Ä«paÅ”i izstrādāts, lai aizstātu Cisco Connect.

Atveriet savienojumu

Teorētiski Ubuntu ir Ä«paÅ”s grafiskais interfeiss openconnect, taču tas man nedarbojās. VarbÅ«t tas ir uz labu.

Ubuntu programmā openconnect ir instalēts no pakotņu pārvaldnieka.

apt install openconnect

TÅ«lÄ«t pēc instalÄ“Å”anas varat mēģināt izveidot savienojumu ar VPN

openconnect --user poxvuibr vpn.evilcorp.com

vpn.evilcorp.com ir fiktīva VPN adrese
poxvuibr - fiktīvs lietotājvārds

openconnect lÅ«gs ievadÄ«t paroli, kas, atgādināŔu, sastāv no fiksētas daļas un koda no Google Authenticator, un tad tas mēģinās izveidot savienojumu ar vpn. Ja tas darbojas, apsveicam, varat droÅ”i izlaist vidu, kas ir ļoti sāpÄ«gi, un pāriet uz punktu par openconnect darbÄ«bu fonā. Ja tas nedarbojas, varat turpināt. Lai gan, ja tas strādāja, pieslēdzoties, piemēram, no viesa Wi-Fi darbā, tad var bÅ«t par agru priecāties, jums vajadzētu mēģināt atkārtot procedÅ«ru no mājām.

Sertifikāts

Pastāv liela varbÅ«tÄ«ba, ka nekas nesāksies, un openconnect izvade izskatÄ«sies apmēram Ŕādi:

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

No vienas puses, tas ir nepatÄ«kami, jo nebija savienojuma ar VPN, bet, no otras puses, kā Å”o problēmu novērst, principā ir skaidrs.

Å eit serveris mums atsÅ«tÄ«ja sertifikātu, pēc kura mēs varam noteikt, ka savienojums tiek izveidots ar mÅ«su dzimtās korporācijas serveri, nevis ar ļaunu krāpnieku, un Å”is sertifikāts sistēmai nav zināms. Un tāpēc viņa nevar pārbaudÄ«t, vai serveris ir Ä«sts vai nē. Un tāpēc katram gadÄ«jumam tas pārstāj darboties.

Lai openconnect izveidotu savienojumu ar serveri, jums ir skaidri jānorāda, kuram sertifikātam ir jānāk no VPN servera, izmantojot servera atslēgu.

Un jūs varat uzzināt, kuru sertifikātu serveris mums nosūtīja tieŔi no tā, ko izdrukāja openconnect. Lūk, no Ŕī gabala:

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

Ar Å”o komandu varat mēģināt vēlreiz izveidot savienojumu

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

Varbūt tagad tas darbojas, tad varat pāriet uz beigām. Bet personīgi Ubunta man parādīja vīģi Ŕādā 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

vietne habr.com atrisinās, taču jūs nevarēsit tur doties. Tādas adreses kā jira.evilcorp.com vispār netiek atrisinātas.

Kas Å”eit notika, man nav skaidrs. Taču eksperiments parāda, ka, pievienojot rindiņu failam /etc/resolv.conf

nameserver 192.168.430.534

tad VPN iekÅ”ienē esoŔās adreses sāks maÄ£iski atrisināties, un jÅ«s varat tās izstaigāt, tas ir, tas, ko DNS meklē, lai atrisinātu adreses, izskatās Ä«paÅ”i mapē /etc/resolv.conf, nevis kaut kur citur.

Varat pārbaudīt, vai ir izveidots savienojums ar VPN un tas darbojas, neveicot nekādas izmaiņas failā /etc/resolv.conf; lai to izdarītu, pārlūkprogrammā ievadiet nevis VPN resursa simbolisko nosaukumu, bet gan tā IP adresi.

Rezultātā ir divas problēmas

  • Pieslēdzoties VPN, tā dns netiek uztverts
  • visa trafika notiek caur VPN, kas neļauj piekļūt internetam

Es jums pateikŔu, ko darīt tagad, bet vispirms nedaudz automatizācijas.

Paroles fiksētās daļas automātiska ievade

Å obrÄ«d jÅ«s, visticamāk, jau esat ievadÄ«jis savu paroli vismaz piecas reizes, un Ŕī procedÅ«ra jÅ«s jau ir nogurdinājusi. Pirmkārt, tāpēc, ka parole ir gara, un, otrkārt, tāpēc, ka ievadot ir jāiekļaujas noteiktā laika periodā

Galīgais problēmas risinājums rakstā netika iekļauts, taču varat pārliecināties, ka paroles fiksētā daļa nav jāievada daudzas reizes.

Pieņemsim, ka paroles fiksētā daļa ir FiksētaPassword, bet Google autentifikatora daļa ir 567 987. Visu paroli var nodot openconnect, izmantojot standarta ievadi, izmantojot argumentu --passwd-on-stdin.

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

Tagad varat pastāvīgi atgriezties pie pēdējās ievadītās komandas un tajā mainīt tikai daļu no Google autentifikatora.

Korporatīvais VPN neļauj sērfot internetā.

Kopumā tas nav Ä«paÅ”i neērti, ja jums ir jāizmanto atseviŔķs dators, lai dotos uz Habru. Nespēja kopēt-ielÄ«mēt no stackoverfow parasti var paralizēt darbu, tāpēc kaut kas ir jādara.

Mums tas ir kaut kā jāorganizē tā, lai tad, kad jums ir nepiecieÅ”ams piekļūt resursam no iekŔējā tÄ«kla, Linux pāriet uz VPN, bet, kad jums ir jāiet uz Habr, tas pāriet uz internetu.

openconnect pēc palaiÅ”anas un savienojuma ar vpn izveidoÅ”anas izpilda Ä«paÅ”u skriptu, kas atrodas mapē /usr/share/vpnc-scripts/vpnc-script. Daži mainÄ«gie tiek nodoti skriptam kā ievade, un tas konfigurē VPN. Diemžēl es nevarēju izdomāt, kā sadalÄ«t trafika plÅ«smas starp korporatÄ«vo VPN un pārējo internetu, izmantojot vietējo skriptu.

AcÄ«mredzot vpn-slice utilÄ«ta tika izstrādāta Ä«paÅ”i tādiem cilvēkiem kā es, kas ļauj nosÅ«tÄ«t trafiku pa diviem kanāliem, nedejojot ar tamburÄ«nu. Nu, tas ir, jums bÅ«s jādejo, bet jums nav jābÅ«t Å”amanim.

Satiksmes atdalīŔana, izmantojot vpn-slice

Pirmkārt, jums bÅ«s jāinstalē vpn-slice, jums tas bÅ«s jāizdomā paÅ”am. Ja komentāros ir jautājumi, par to uzrakstÄ«Å”u atseviŔķu ierakstu. Bet Ŕī ir parasta Python programma, tāpēc nevajadzētu rasties grÅ«tÄ«bām. Es instalēju, izmantojot virtualenv.

Un tad ir jāpiemēro utilīta, izmantojot slēdzi -script, kas norāda, lai atvērtu savienojumu, ka standarta skripta vietā ir jāizmanto vpn-slice

echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin 
--script "./bin/vpn-slice 192.168.430.0/24  " vpn.evilcorp.com 

--script tiek nodota virkne ar komandu, kas jāizsauc skripta vietā. ./bin/vpn-slice ā€” ceļŔ uz vpn-slice izpildāmo failu 192.168.430.0/24 ā€” adreÅ”u maska, uz kuru jādodas vpn. Å eit mēs domājam, ka, ja adrese sākas ar 192.168.430, tad resurss ar Å”o adresi ir jāmeklē VPN iekÅ”ienē.

Situācijai tagad vajadzētu bÅ«t gandrÄ«z normālai. GandrÄ«z. Tagad jÅ«s varat doties uz Habr un jÅ«s varat doties uz uzņēmuma iekŔējo resursu ar ip, bet jÅ«s nevarat doties uz uzņēmuma iekŔējo resursu ar simbolisku nosaukumu. Ja saimniekos norādāt atbilstÄ«bu starp simbolisko nosaukumu un adresi, visam vajadzētu darboties. Un strādā, kamēr mainās ip. Linux tagad var piekļūt internetam vai iekÅ”tÄ«klam atkarÄ«bā no IP. Bet adreses noteikÅ”anai joprojām tiek izmantots nekorporatÄ«vs DNS.

Problēma var izpausties arÄ« Ŕādā formā - darbā viss ir kārtÄ«bā, bet mājās var piekļūt tikai iekŔējiem korporatÄ«vajiem resursiem caur IP. Tas ir tāpēc, ka, izveidojot savienojumu ar korporatÄ«vo Wi-Fi, tiek izmantots arÄ« korporatÄ«vais DNS, un tajā tiek atrisinātas simboliskās adreses no VPN, neskatoties uz to, ka joprojām nav iespējams nokļūt uz Ŕādu adresi, neizmantojot VPN.

Automātiska saimniekdatora faila modifikācija

Ja vpn-slice pajautā pieklājÄ«gi, tad pēc VPN pacelÅ”anas tas var aiziet uz savu DNS, atrast tur nepiecieÅ”amo resursu IP adreses pēc to simboliskajiem nosaukumiem un ievadÄ«t hostos. Pēc VPN izslēgÅ”anas Ŕīs adreses tiks noņemtas no saimniekiem. Lai to izdarÄ«tu, vpn-slice kā argumenti ir jānodod simbolisks nosaukumi. Kā Å”is.

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 

Tagad visam vajadzētu darboties gan birojā, gan pludmalē.

Meklējiet visu apakÅ”domēnu adreses VPN norādÄ«tajā DNS

Ja tÄ«klā ir maz adreÅ”u, resursdatora faila automātiskās modificÄ“Å”anas pieeja darbojas diezgan labi. Bet, ja tÄ«klā ir daudz resursu, jums pastāvÄ«gi bÅ«s jāpievieno rindas, piemēram, zoidberg.test.evilcorp.com. Zoidberg ir viena testa stenda nosaukums.

Bet tagad, kad mēs mazliet saprotam, kāpēc Å”o vajadzÄ«bu var novērst.

Ja pēc VPN palielināŔanas skatāties /etc/hosts, varat redzēt Å”o rindiņu

192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOMĀTISVEIDOTS

Un failam resolv.conf tika pievienota jauna rinda. ÄŖsāk sakot, vpn-slice kaut kādā veidā noteica, kur atrodas vpn DNS serveris.

Tagad mums ir jāpārliecinās, ka, lai uzzinātu IP adresi domēna vārdam, kas beidzas ar evilcorp.com, Linux pāriet uz korporatÄ«vo DNS un, ja nepiecieÅ”ams kaut kas cits, tad uz noklusējuma.

Es diezgan ilgu laiku meklēju Google un atklāju, ka Ŕāda funkcionalitāte ir pieejama Ubuntu. Tas nozÄ«mē iespēju izmantot vietējo DNS serveri dnsmasq, lai atrisinātu nosaukumus.

Tas ir, jūs varat pārliecināties, ka Linux vienmēr dodas uz lokālo DNS serveri pēc IP adresēm, kas savukārt atkarībā no domēna nosaukuma meklēs IP attiecīgajā ārējā DNS serverī.

Lai pārvaldÄ«tu visu, kas saistÄ«ts ar tÄ«kliem un tÄ«kla savienojumiem, Ubuntu izmanto NetworkManager, un grafiskais interfeiss, piemēram, Wi-Fi savienojumu izvēlei, ir tikai tā priekÅ”gals.

Mums vajadzēs kāpt tā konfigurācijā.

  1. Izveidojiet failu mapē /etc/NetworkManager/dnsmasq.d/evilcorp

adrese=/.evilcorp.com/192.168.430.534

Pievērsiet uzmanÄ«bu punktam evilcorp priekŔā. Tas signalizē dnsmasq, ka visi evilcorp.com apakÅ”domēni ir jāmeklē korporatÄ«vajā DNS.

  1. Pastāstiet NetworkManager, lai vārda izŔķirŔanai izmantotu dnsmasq

Tīkla pārvaldnieka konfigurācija atrodas mapē /etc/NetworkManager/NetworkManager.conf Tur jāpievieno:

[galvenais] dns=dnsmasq

  1. Restartējiet programmu NetworkManager

service network-manager restart

Tagad, pēc savienojuma izveides ar VPN, izmantojot openconnect un vpn-slice, IP tiks noteikts normāli, pat ja vpnslice argumentiem nepievienosiet simboliskas adreses.

Kā piekļūt atseviŔķiem pakalpojumiem, izmantojot VPN

Pēc tam, kad izdevās izveidot savienojumu ar VPN, divas dienas biju ļoti priecīgs, un tad izrādījās, ka, ja pieslēdzos VPN no ārpus biroja tīkla, tad pasts nedarbojas. Simptoms ir pazīstams, vai ne?

Mūsu pasts atrodas vietnē mail.publicevilcorp.com, kas nozīmē, ka uz to neattiecas dnsmasq noteikums, un pasta servera adrese tiek meklēta, izmantojot publisko DNS.

Nu, birojs joprojām izmanto DNS, kurā ir Ŕī adrese. Tā es domāju. Faktiski pēc rindas pievienoÅ”anas dnsmasq

address=/mail.publicevilcorp.com/192.168.430.534

situācija nemaz nav mainījusies. ip palika tas pats. Man bija jāiet uz darbu.

Un tikai vēlāk, kad es iedziļinājos situācijā un nedaudz sapratu problēmu, viens gudrs cilvēks man teica, kā to atrisināt. Bija nepiecieÅ”ams izveidot savienojumu ar pasta serveri ne tikai tā, bet caur VPN

Es izmantoju vpn-slice, lai pārietu caur VPN uz adresēm, kas sākas ar 192.168.430. Un pasta serverim ir ne tikai simboliska adrese, kas nav evilcorp apakÅ”domēns, bet arÄ« nav IP adreses, kas sākas ar 192.168.430. Un, protams, viņŔ neļauj nevienam no vispārējā tÄ«kla ierasties pie viņa.

Lai Linux varētu iet caur VPN un pasta serveri, jums tas jāpievieno arī vpn-slice. Pieņemsim, ka pasta sūtītāja adrese ir 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 

Skripts VPN palielināŔanai ar vienu argumentu

Tas viss, protams, nav Ä«paÅ”i ērti. Jā, jÅ«s varat saglabāt tekstu failā un kopēt un ielÄ«mēt to konsolē, nevis rakstÄ«t ar roku, taču tas joprojām nav Ä«paÅ”i patÄ«kami. Lai atvieglotu procesu, komandu varat ietÄ«t skriptā, kas atradÄ«sies mapē PATH. Un tad jums bÅ«s jāievada tikai kods, kas saņemts no Google autentifikatora

#!/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 

Ja ievietojat skriptu mapē connect~evilcorp~, varat vienkārÅ”i rakstÄ«t konsolē

connect_evil_corp 567987

Bet tagad jums joprojām ir jāpatur atvērta konsole, kurā darbojas openconnect kaut kādu iemeslu dēļ

Fonā darbojas openconnect

Par laimi, openconnect autori parÅ«pējās par mums un pievienoja programmai speciālu atslēgu -background, kas liek programmai pēc palaiÅ”anas darboties fonā. Ja palaižat to Ŕādi, pēc palaiÅ”anas varat aizvērt konsoli

#!/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  

Tagad vienkārÅ”i nav skaidrs, kur baļķi nonāk. Kopumā mums nav Ä«sti vajadzÄ«gi apaļkoki, taču jÅ«s nekad to nevarat zināt. openconnect var tos novirzÄ«t uz syslog, kur tie tiks glabāti droŔībā. komandai jāpievieno slēdzis ā€“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  

Un tā, izrādās, ka openconnect darbojas kaut kur fonā un nevienu netraucē, taču nav skaidrs, kā to apturēt. Tas ir, jÅ«s, protams, varat filtrēt ps izvadi, izmantojot grep, un meklēt procesu, kura nosaukumā ir ietverts openconnect, taču tas ir kaut kā nogurdinoÅ”i. Paldies autoriem, kuri arÄ« par to domāja. Openconnect ir atslēga -pid-fails, ar kuru varat uzdot openconnect ierakstÄ«t failā tā procesa identifikatoru.

#!/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

Tagad jūs vienmēr varat nogalināt procesu ar komandu

kill $(cat ~/vpn-pid)

Ja procesa nav, kill nolādēs, bet neizmetÄ«s kļūdu. Ja fails tur nav, tad arÄ« nekas slikts nenotiks, tāpēc varat droÅ”i nogalināt procesu skripta pirmajā rindā.

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

Tagad varat ieslēgt datoru, atvērt konsoli un palaist komandu, nosūtot tai kodu no Google autentifikatora. Pēc tam konsoli var pienaglot.

Bez VPN sadaļas. Pēcvārda vietā

IzrādÄ«jās ļoti grÅ«ti saprast, kā dzÄ«vot bez VPN Å”ķēles. Man nācās daudz lasÄ«t un googlēt. Par laimi, tik daudz laika pavadot problēmas risināŔanai, tehniskās rokasgrāmatas un pat man openconnect lasās kā aizraujoÅ”i romāni.

Rezultātā es atklāju, ka vpn-slice, tāpat kā vietējais skripts, pārveido marÅ”rutÄ“Å”anas tabulu, lai atdalÄ«tu tÄ«klus.

MarŔrutēŔanas tabula

VienkārÅ”i sakot, Ŕī ir tabula pirmajā kolonnā, kurā ir norādÄ«ts, ar ko jāsākas adresei, kuru vēlas izmantot Linux, un otrajā kolonnā, kuram tÄ«kla adapterim Å”ajā adresē jāiet cauri. PatiesÄ«bā runātāju ir vairāk, bet bÅ«tÄ«bu tas nemaina.

Lai skatÄ«tu marÅ”rutÄ“Å”anas tabulu, ir jāpalaiž komanda 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 

Šeit katra rinda ir atbildīga par to, kur jums jāiet, lai nosūtītu ziņojumu uz kādu adresi. Pirmais ir apraksts, kur adresei jāsākas. Lai saprastu, kā noteikt, ka 192.168.0.0/16 nozīmē, ka adresei jāsākas ar 192.168, google jāpameklē, kas ir IP adreses maska. Pēc dev ir tā adaptera nosaukums, kuram jānosūta ziņojums.

VPN Linux izveidoja virtuālo adapteri - tun0. LÄ«nija nodroÅ”ina, ka caur to iet trafika visām adresēm, kas sākas ar 192.168

192.168.0.0/16 dev tun0 scope link 

Varat arÄ« apskatÄ«t marÅ”rutÄ“Å”anas tabulas paÅ”reizējo stāvokli, izmantojot komandu marÅ”ruts -n (IP adreses ir gudri anonimizētas) Å Ä« komanda rada rezultātus citā formā un parasti ir novecojusi, taču tās izvade bieži ir atrodama rokasgrāmatās internetā, un jums ir jāspēj to izlasÄ«t.

Kur jāsākas marÅ”ruta IP adresei, var saprast no kolonnu Destination un Genmask kombinācijas. Tiek ņemtas vērā tās IP adreses daļas, kas atbilst skaitļiem 255 Genmaskā, bet tās, kurās ir 0, netiek ņemtas vērā. Tas nozÄ«mē, ka galamērÄ·a 192.168.0.0 un Genmask 255.255.255.0 kombinācija nozÄ«mē, ka, ja adrese sākas ar 192.168.0, tad pieprasÄ«jums tai tiks nosÅ«tÄ«ts pa Å”o marÅ”rutu. Un, ja galamērÄ·is 192.168.0.0, bet Genmask 255.255.0.0, tad pieprasÄ«jumi uz adresēm, kas sākas ar 192.168, tiks nosÅ«tÄ«ti pa Å”o marÅ”rutu.

Lai noskaidrotu, ko vpn-slice patiesībā dara, es nolēmu apskatīt tabulu stāvokļus pirms un pēc

Pirms VPN ieslēgÅ”anas tas bija Ŕādi

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

Pēc openconnect izsaukÅ”anas bez vpn-slices tas kļuva Ŕāds

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

Un pēc openconnect izsaukÅ”anas kopā ar vpn-slice kā Å”is

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

Redzams, ka, ja neizmanto vpn-slice, tad openconnect tieÅ”i raksta, ka visām adresēm, izņemot Ä«paÅ”i norādÄ«tās, ir jāpiekļūst caur vpn.

TieŔi Ŕeit:

0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 tun0

Tur blakus uzreiz norādÄ«ts cits ceļŔ, kas jāizmanto, ja adrese, pa kuru Linux mēģina iziet, neatbilst nevienai maskai no tabulas.

0.0.0.0         222.222.222.1   0.0.0.0         UG    600    0        0 wlp3s0

Šeit jau ir rakstīts, ka Ŕajā gadījumā ir jāizmanto standarta Wi-Fi adapteris.

Es uzskatu, ka VPN ceļŔ tiek izmantots, jo tas ir pirmais marÅ”rutÄ“Å”anas tabulā.

Un teorētiski, ja jÅ«s noņemat Å”o noklusējuma ceļu no marÅ”rutÄ“Å”anas tabulas, tad kopā ar dnsmasq openconnect vajadzētu nodroÅ”ināt normālu darbÄ«bu.

ES mēģināju

route del default

Un viss strādāja.

Pieprasījumu marŔrutēŔana uz pasta serveri bez vpn-slice

Bet man ir arī pasta serveris ar adresi 555.555.555.555, kuram arī ir jāpiekļūst caur VPN. MarŔruts uz to arī jāpievieno manuāli.

ip route add 555.555.555.555 via dev tun0

Un tagad viss ir kārtÄ«bā. Tātad jÅ«s varat iztikt bez vpn-slice, bet jums ir labi jāzina, ko jÅ«s darāt. Tagad es domāju pievienot vietējā openconnect skripta pēdējai rindai noklusējuma marÅ”ruta noņemÅ”anu un pasta sÅ«tÄ«tāja marÅ”ruta pievienoÅ”anu pēc savienojuma ar VPN, lai manā velosipēdā bÅ«tu mazāk kustÄ«go daļu.

Iespējams, ar Å”o pēcvārdu pietiktu, lai kāds saprastu, kā izveidot VPN. Bet, kamēr es mēģināju saprast, ko un kā darÄ«t, es izlasÄ«ju diezgan daudz Ŕādu ceļvežu, kas autoram der, bet man nez kāpēc neder, un nolēmu pievienot Å”eit visus atrastos gabalus. Es ļoti priecātos par ko tādu.

Avots: www.habr.com

Pievieno komentāru