Gusto mo bang gumamit ng Linux sa trabaho, ngunit hindi ka papayagan ng iyong corporate VPN? Kung gayon ang artikulong ito ay maaaring makatulong, bagaman hindi ito tiyak. Nais kong bigyan ka ng babala nang maaga na hindi ko naiintindihan ang mga isyu sa pangangasiwa ng network, kaya posibleng mali ang ginawa ko. Sa kabilang banda, posibleng magsulat ako ng gabay sa paraang mauunawaan ito ng mga ordinaryong tao, kaya ipinapayo ko sa iyo na subukan ito.
Ang artikulo ay naglalaman ng maraming hindi kinakailangang impormasyon, ngunit kung wala ang kaalamang ito ay hindi ko malutas ang mga problema na hindi inaasahang lumitaw sa akin sa pag-set up ng isang VPN. Sa palagay ko ang sinumang sumusubok na gumamit ng gabay na ito ay magkakaroon ng mga problema na wala sa akin, at umaasa ako na ang karagdagang impormasyong ito ay makakatulong sa paglutas ng mga problemang ito sa kanilang sarili.
Karamihan sa mga utos na ginamit sa gabay na ito ay kailangang patakbuhin sa pamamagitan ng sudo, na inalis para sa kaiklian. Tandaan.
Karamihan sa mga IP address ay na-obfuscate nang husto, kaya kung makakita ka ng address tulad ng 435.435.435.435, dapat mayroong ilang normal na IP doon, partikular sa iyong kaso.
Mayroon akong Ubuntu 18.04, ngunit sa palagay ko ay may maliliit na pagbabago ang gabay ay maaaring mailapat sa iba pang mga distribusyon. Gayunpaman, sa tekstong ito Linux == Ubuntu.
Cisco Connect
Ang mga nasa Windows o MacOS ay maaaring kumonekta sa aming corporate VPN sa pamamagitan ng Cisco Connect, na kailangang tukuyin ang gateway address at, sa tuwing kumonekta ka, maglagay ng password na binubuo ng isang nakapirming bahagi at isang code na nabuo ng Google Authenticator.
Sa kaso ng Linux, hindi ko mapatakbo ang Cisco Connect, ngunit nagawa kong mag-google ng isang rekomendasyon na gumamit ng openconnect, na partikular na ginawa upang palitan ang Cisco Connect.
Openconnect
Sa teorya, ang Ubuntu ay may espesyal na graphical na interface para sa openconnect, ngunit hindi ito gumana para sa akin. Marahil ito ay para sa ikabubuti.
Sa Ubuntu, naka-install ang openconnect mula sa manager ng package.
apt install openconnectKaagad pagkatapos ng pag-install, maaari mong subukang kumonekta sa isang VPN
openconnect --user poxvuibr vpn.evilcorp.comAng vpn.evilcorp.com ay ang address ng isang fictitious VPN
poxvuibr - kathang-isip na username
hihilingin sa iyo ng openconnect na magpasok ng isang password, na, hayaan mo akong ipaalala sa iyo, ay binubuo ng isang nakapirming bahagi at isang code mula sa Google Authenticator, at pagkatapos ay susubukan nitong kumonekta sa vpn. Kung ito ay gumagana, binabati kita, maaari mong ligtas na laktawan ang gitna, na kung saan ay maraming sakit, at magpatuloy sa punto tungkol sa openconnect na tumatakbo sa background. Kung hindi ito gumana, maaari kang magpatuloy. Bagaman kung gumana ito kapag kumokonekta, halimbawa, mula sa isang bisitang Wi-Fi sa trabaho, maaaring masyadong maaga para magsaya; dapat mong subukang ulitin ang pamamaraan mula sa bahay.
Sertipiko
Malaki ang posibilidad na walang magsisimula, at ang output ng openconnect ay magmumukhang ganito:
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 progressSa isang banda, ito ay hindi kanais-nais, dahil walang koneksyon sa VPN, ngunit sa kabilang banda, kung paano ayusin ang problemang ito ay, sa prinsipyo, malinaw.
Dito nagpadala sa amin ang server ng isang sertipiko, kung saan matutukoy namin na ang koneksyon ay ginagawa sa server ng aming katutubong korporasyon, at hindi sa isang masamang manloloko, at ang sertipiko na ito ay hindi alam ng system. At samakatuwid hindi niya masuri kung ang server ay totoo o hindi. At kaya, kung sakali, huminto ito sa paggana.
Upang makakonekta ang openconnect sa server, kailangan mong tahasang sabihin dito kung aling certificate ang dapat manggaling sa VPN server gamit ang βservercert key
At maaari mong malaman kung aling sertipiko ang direktang ipinadala sa amin ng server mula sa kung ano ang na-print ng openconnect. Narito ang mula sa pirasong ito:
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 progressSa utos na ito maaari mong subukang kumonekta muli
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comMarahil ngayon ay gumagana na, pagkatapos ay maaari kang magpatuloy sa dulo. Ngunit sa personal, ipinakita sa akin ng Ubunta ang isang igos sa form na ito
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.comMareresolba ang habr.com, ngunit hindi ka makakapunta doon. Ang mga address tulad ng jira.evilcorp.com ay hindi nareresolba.
Hindi malinaw sa akin ang nangyari dito. Ngunit ipinapakita ng eksperimento na kung idaragdag mo ang linya sa /etc/resolv.conf
nameserver 192.168.430.534pagkatapos ang mga address sa loob ng VPN ay magsisimulang magsikap na malutas at maaari mong lakad ang mga ito, iyon ay, kung ano ang hinahanap ng DNS upang malutas ang mga address ay partikular na nakikita sa /etc/resolv.conf, at hindi sa ibang lugar.
Maaari mong i-verify na mayroong koneksyon sa VPN at ito ay gumagana nang hindi gumagawa ng anumang mga pagbabago sa /etc/resolv.conf; upang gawin ito, ipasok lamang sa browser hindi ang simbolikong pangalan ng mapagkukunan mula sa VPN, ngunit ang IP address nito
Bilang resulta, mayroong dalawang problema
- Kapag kumokonekta sa isang VPN, ang dns nito ay hindi kinuha
- lahat ng trapiko ay dumadaan sa VPN, na hindi pinapayagan ang pag-access sa Internet
Sasabihin ko sa iyo kung ano ang gagawin ngayon, ngunit kaunting automation muna.
Awtomatikong pagpasok ng nakapirming bahagi ng password
Sa ngayon, malamang na naipasok mo na ang iyong password nang hindi bababa sa limang beses at napapagod ka na ng pamamaraang ito. Una, dahil mahaba ang password, at pangalawa, dahil sa pagpasok kailangan mong magkasya sa loob ng isang takdang panahon
Ang huling solusyon sa problema ay hindi kasama sa artikulo, ngunit maaari mong tiyakin na ang nakapirming bahagi ng password ay hindi kailangang ipasok nang maraming beses.
Ipagpalagay natin na ang nakapirming bahagi ng password ay fixedPassword, at ang bahagi mula sa Google Authenticator ay 567. Ang buong password ay maaaring ipasa sa openconnect sa pamamagitan ng karaniwang input gamit ang --passwd-on-stdin argument.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinNgayon ay maaari kang patuloy na bumalik sa huling inilagay na command at baguhin lamang ang bahagi ng Google Authenticator doon.
Ang isang corporate VPN ay hindi nagpapahintulot sa iyo na mag-surf sa Internet.
Sa pangkalahatan, hindi masyadong abala kapag kailangan mong gumamit ng hiwalay na computer upang pumunta sa Habr. Ang kawalan ng kakayahang mag-copy-paste mula sa stackoverfow sa pangkalahatan ay maaaring maparalisa ang trabaho, kaya may kailangang gawin.
Kailangan nating ayusin ito kahit papaano upang kapag kailangan mong mag-access ng isang mapagkukunan mula sa panloob na network, pupunta ang Linux sa VPN, at kapag kailangan mong pumunta sa Habr, mapupunta ito sa Internet.
openconnect, pagkatapos maglunsad at magtatag ng isang koneksyon sa vpn, nagsasagawa ng isang espesyal na script, na matatagpuan sa /usr/share/vpnc-scripts/vpnc-script. Ang ilang mga variable ay ipinapasa sa script bilang input, at kino-configure nito ang VPN. Sa kasamaang palad, hindi ko malaman kung paano hatiin ang mga daloy ng trapiko sa pagitan ng isang corporate VPN at ang natitirang bahagi ng Internet gamit ang isang katutubong script.
Tila, ang vpn-slice utility ay binuo lalo na para sa mga taong tulad ko, na nagpapahintulot sa iyo na magpadala ng trapiko sa pamamagitan ng dalawang channel nang hindi sumasayaw gamit ang tamburin. Well, iyon ay, kailangan mong sumayaw, ngunit hindi mo kailangang maging isang shaman.
Paghihiwalay ng trapiko gamit ang vpn-slice
Una, kailangan mong mag-install ng vpn-slice, kakailanganin mong malaman ito sa iyong sarili. Kung may mga katanungan sa mga komento, magsusulat ako ng isang hiwalay na post tungkol dito. Ngunit ito ay isang regular na programa ng Python, kaya hindi dapat magkaroon ng anumang mga paghihirap. Nag-install ako gamit ang virtualenv.
At pagkatapos ay dapat ilapat ang utility, gamit ang -script switch, na nagpapahiwatig na openconnect na sa halip na karaniwang script, kailangan mong gumamit ng 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 ay ipinasa ang isang string na may isang command na kailangang tawagan sa halip na ang script. ./bin/vpn-slice - path sa vpn-slice executable file 192.168.430.0/24 - mask ng mga address na pupuntahan sa vpn. Dito, ibig sabihin namin na kung ang address ay magsisimula sa 192.168.430, kung gayon ang mapagkukunan na may ganitong address ay kailangang hanapin sa loob ng VPN
Ang sitwasyon ngayon ay dapat na halos normal. halos. Ngayon ay maaari kang pumunta sa Habr at maaari kang pumunta sa intra-corporate na mapagkukunan sa pamamagitan ng ip, ngunit hindi ka maaaring pumunta sa intra-corporate na mapagkukunan sa pamamagitan ng simbolikong pangalan. Kung tumukoy ka ng tugma sa pagitan ng simbolikong pangalan at address sa mga host, dapat gumana ang lahat. At gumana hanggang sa magbago ang ip. Maa-access na ngayon ng Linux ang Internet o ang intranet, depende sa IP. Ngunit ginagamit pa rin ang non-corporate DNS upang matukoy ang address.
Ang problema ay maaari ring magpakita mismo sa form na ito - sa trabaho ang lahat ay maayos, ngunit sa bahay maaari mo lamang ma-access ang mga panloob na mapagkukunan ng korporasyon sa pamamagitan ng IP. Ito ay dahil kapag nakakonekta ka sa corporate Wi-Fi, ginagamit din ang corporate DNS, at ang mga simbolikong address mula sa VPN ay nalutas dito, sa kabila ng katotohanan na imposible pa ring pumunta sa naturang address nang hindi gumagamit ng VPN.
Awtomatikong pagbabago ng file ng host
Kung tatanungin ang vpn-slice nang magalang, pagkatapos ay pagkatapos na itaas ang VPN, maaari itong pumunta sa DNS nito, hanapin doon ang mga IP address ng mga kinakailangang mapagkukunan sa pamamagitan ng kanilang mga simbolikong pangalan at ipasok ang mga ito sa mga host. Pagkatapos i-off ang VPN, ang mga address na ito ay aalisin sa mga host. Upang gawin ito, kailangan mong ipasa ang mga simbolikong pangalan sa vpn-slice bilang mga argumento. Ganito.
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 Ngayon ang lahat ay dapat gumana pareho sa opisina at sa beach.
Maghanap para sa mga address ng lahat ng mga subdomain sa DNS na ibinigay ng VPN
Kung mayroong ilang mga address sa loob ng network, kung gayon ang diskarte ng awtomatikong pagbabago sa file ng host ay gumagana nang maayos. Ngunit kung mayroong maraming mga mapagkukunan sa network, pagkatapos ay kailangan mong patuloy na magdagdag ng mga linya tulad ng zoidberg.test.evilcorp.com sa script na zoidberg ay ang pangalan ng isa sa mga test bench.
Ngunit ngayong naiintindihan na natin nang kaunti kung bakit maaaring alisin ang pangangailangang ito.
Kung, pagkatapos itaas ang VPN, tumingin ka sa /etc/hosts, makikita mo ang linyang ito
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
At isang bagong linya ang idinagdag sa resolv.conf. Sa madaling salita, ang vpn-slice ay natukoy kung saan matatagpuan ang dns server para sa vpn.
Ngayon kailangan nating tiyakin na upang malaman ang IP address ng isang domain name na nagtatapos sa evilcorp.com, ang Linux ay pupunta sa corporate DNS, at kung may kailangan pa, pagkatapos ay sa default.
Nag-Google ako nang medyo matagal at nalaman kong available ang ganoong functionality sa Ubuntu out of the box. Nangangahulugan ito ng kakayahang gamitin ang lokal na DNS server na dnsmasq upang malutas ang mga pangalan.
Iyon ay, maaari mong tiyakin na ang Linux ay palaging pumupunta sa lokal na DNS server para sa mga IP address, na kung saan, depende sa domain name, ay hahanapin ang IP sa kaukulang panlabas na DNS server.
Upang pamahalaan ang lahat ng nauugnay sa mga network at koneksyon sa network, gumagamit ang Ubuntu ng NetworkManager, at ang graphical na interface para sa pagpili, halimbawa, ang mga koneksyon sa Wi-Fi ay isang front end lamang nito.
Kakailanganin nating umakyat sa pagsasaayos nito.
- Gumawa ng file sa /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Bigyang-pansin ang punto sa harap ng evilcorp. Ito ay nagpapahiwatig ng dnsmasq na ang lahat ng mga subdomain ng evilcorp.com ay dapat hanapin sa corporate dns.
- Sabihin sa NetworkManager na gumamit ng dnsmasq para sa paglutas ng pangalan
Ang configuration ng network-manager ay matatagpuan sa /etc/NetworkManager/NetworkManager.conf Kailangan mong idagdag doon:
[pangunahing] dns=dnsmasq
- I-restart ang NetworkManager
service network-manager restartNgayon, pagkatapos kumonekta sa isang VPN gamit ang openconnect at vpn-slice, ang ip ay matutukoy nang normal, kahit na hindi ka magdagdag ng mga simbolikong address sa mga argumento sa vpnslice.
Paano ma-access ang mga indibidwal na serbisyo sa pamamagitan ng VPN
Matapos kong makakonekta sa VPN, napakasaya ko sa loob ng dalawang araw, at pagkatapos ay lumabas na kung kumonekta ako sa VPN mula sa labas ng network ng opisina, hindi gagana ang mail. Pamilyar ang sintomas, di ba?
Ang aming mail ay matatagpuan sa mail.publicevilcorp.com, na nangangahulugang hindi ito napapailalim sa panuntunan sa dnsmasq at ang mail server address ay hinahanap sa pamamagitan ng pampublikong DNS.
Well, ang opisina ay gumagamit pa rin ng DNS, na naglalaman ng address na ito. Yan ang naisip ko. Sa katunayan, pagkatapos idagdag ang linya sa dnsmasq
address=/mail.publicevilcorp.com/192.168.430.534
hindi nagbago ang sitwasyon. ip ay nanatiling pareho. Kinailangan kong pumasok sa trabaho.
At nang maglaon, nang mas malalim ang pag-iisip ko sa sitwasyon at naunawaan ko ang problema, sinabi sa akin ng isang matalinong tao kung paano ito lutasin. Kinailangan na kumonekta sa mail server hindi lang ganoon, ngunit sa pamamagitan ng VPN
Gumagamit ako ng vpn-slice para dumaan sa VPN sa mga address na nagsisimula sa 192.168.430. At ang mail server ay hindi lamang mayroong simbolikong address na hindi isang subdomain ng evilcorp, wala rin itong IP address na nagsisimula sa 192.168.430. At siyempre hindi niya pinapayagan ang sinuman mula sa pangkalahatang network na lumapit sa kanya.
Upang ang Linux ay dumaan sa VPN at sa mail server, kailangan mo rin itong idagdag sa vpn-slice. Sabihin nating ang address ng mailer ay 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 Script para sa pagpapataas ng VPN na may isang argumento
Ang lahat ng ito, siyempre, ay hindi masyadong maginhawa. Oo, maaari mong i-save ang teksto sa isang file at kopyahin-i-paste ito sa console sa halip na i-type ito sa pamamagitan ng kamay, ngunit hindi pa rin ito kaaya-aya. Upang gawing mas madali ang proseso, maaari mong i-wrap ang command sa isang script na makikita sa PATH. At pagkatapos ay kakailanganin mo lamang ipasok ang code na natanggap mula sa 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 Kung inilagay mo ang script sa connect~evilcorp~ maaari kang sumulat lamang sa console
connect_evil_corp 567987Ngunit ngayon kailangan mo pa ring panatilihing bukas ang console kung saan bukas ang openconnect para sa ilang kadahilanan
Pagpapatakbo ng openconnect sa background
Sa kabutihang palad, inalagaan kami ng mga may-akda ng openconnect at nagdagdag ng isang espesyal na susi sa programa -background, na ginagawang gumagana ang programa sa background pagkatapos ng paglunsad. Kung patakbuhin mo ito nang ganito, maaari mong isara ang console pagkatapos ilunsad
#!/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 Ngayon ay hindi lang malinaw kung saan napupunta ang mga log. Sa pangkalahatan, hindi talaga namin kailangan ng mga log, ngunit hindi mo alam. Openconnect ay maaaring i-redirect ang mga ito sa syslog, kung saan sila ay pananatiling ligtas at secure. kailangan mong idagdag ang βsyslog switch sa command
#!/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 At kaya, lumalabas na ang openconnect ay gumagana sa isang lugar sa background at hindi nakakaabala sa sinuman, ngunit hindi malinaw kung paano ito pipigilan. Iyon ay, maaari mong, siyempre, i-filter ang ps output gamit ang grep at maghanap ng isang proseso na ang pangalan ay naglalaman ng openconnect, ngunit ito ay kahit papaano nakakapagod. Salamat sa mga may-akda na nag-isip tungkol dito. Ang Openconnect ay mayroong key -pid-file, kung saan maaari mong turuan ang openconnect na isulat ang process identifier nito sa isang file.
#!/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-pidNgayon ay maaari mong palaging patayin ang isang proseso gamit ang command
kill $(cat ~/vpn-pid)Kung walang proseso, ang pumatay ay susumpa, ngunit hindi magtapon ng pagkakamali. Kung wala doon ang file, wala ring masamang mangyayari, kaya ligtas mong patayin ang proseso sa unang linya ng script.
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-pidNgayon ay maaari mong i-on ang iyong computer, buksan ang console at patakbuhin ang command, na ipapasa dito ang code mula sa Google Authenticator. Pagkatapos ay maipapako ang console.
Nang walang VPN-slice. Sa halip na isang afterword
Ito ay naging napakahirap na maunawaan kung paano mabuhay nang walang VPN-slice. Kailangan kong magbasa at mag-google ng marami. Sa kabutihang palad, pagkatapos na gumugol ng napakaraming oras sa isang problema, ang mga teknikal na manual at maging ang openconnect ng tao ay nagbabasa tulad ng mga kapana-panabik na nobela.
Bilang resulta, nalaman ko na ang vpn-slice, tulad ng native na script, ay nagbabago sa routing table upang magkahiwalay na mga network.
Routing table
Sa madaling salita, ito ay isang talahanayan sa unang column na naglalaman kung ano ang address na gustong pagdaanan ng Linux ay dapat magsimula, at sa pangalawang column kung aling network adapter ang dadaan sa address na ito. Sa katunayan, marami pang nagsasalita, ngunit hindi nito binabago ang kakanyahan.
Upang matingnan ang routing table, kailangan mong patakbuhin ang ip route command
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 Dito, ang bawat linya ay may pananagutan sa kung saan mo kailangang pumunta upang magpadala ng mensahe sa ilang address. Ang una ay isang paglalarawan kung saan dapat magsimula ang address. Upang maunawaan kung paano matukoy na ang 192.168.0.0/16 ay nangangahulugan na ang address ay dapat magsimula sa 192.168, kailangan mong i-google kung ano ang IP address mask. Pagkatapos ng dev mayroong pangalan ng adaptor kung saan dapat ipadala ang mensahe.
Para sa VPN, gumawa ang Linux ng virtual adapter - tun0. Tinitiyak ng linya na ang trapiko para sa lahat ng mga address na nagsisimula sa 192.168 ay dumaan dito
192.168.0.0/16 dev tun0 scope link Maaari mo ring tingnan ang kasalukuyang estado ng routing table gamit ang command ruta -n (Ang mga IP address ay matalinong hindi nagpapakilala) Ang utos na ito ay gumagawa ng mga resulta sa ibang anyo at sa pangkalahatan ay hindi na ginagamit, ngunit ang output nito ay madalas na matatagpuan sa mga manual sa Internet at kailangan mong mabasa ito.
Kung saan dapat magsimula ang IP address para sa isang ruta ay mauunawaan mula sa kumbinasyon ng mga column ng Destination at Genmask. Ang mga bahagi ng IP address na tumutugma sa mga numerong 255 sa Genmask ay isinasaalang-alang, ngunit ang mga kung saan mayroong 0 ay hindi. Ibig sabihin, ang kumbinasyon ng Destination 192.168.0.0 at Genmask 255.255.255.0 ay nangangahulugan na kung ang address ay magsisimula sa 192.168.0, ang kahilingan dito ay mapupunta sa rutang ito. At kung ang Destination 192.168.0.0 ngunit Genmask 255.255.0.0, ang mga kahilingan sa mga address na nagsisimula sa 192.168 ay mapupunta sa rutang ito
Upang malaman kung ano talaga ang ginagawa ng vpn-slice, nagpasya akong tingnan ang mga estado ng mga talahanayan bago at pagkatapos
Bago i-on ang VPN ay ganito
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 wlp3s0Pagkatapos tumawag sa openconnect na walang vpn-slice naging ganito
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 tun0At pagkatapos tawagan ang openconnect kasabay ng vpn-slice na ganito
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 tun0Makikita na kung hindi ka gumagamit ng vpn-slice, pagkatapos ay tahasang isinusulat ng openconnect na ang lahat ng mga address, maliban sa mga partikular na ipinahiwatig, ay dapat ma-access sa pamamagitan ng vpn.
Dito:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Doon, sa tabi nito, ang isa pang landas ay agad na ipinahiwatig, na dapat gamitin kung ang address na sinusubukan ng Linux na dumaan ay hindi tumutugma sa anumang maskara mula sa talahanayan.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Nakasulat na dito na sa kasong ito kailangan mong gumamit ng karaniwang Wi-Fi adapter.
Naniniwala ako na ang VPN path ay ginagamit dahil ito ang una sa routing table.
At theoretically, kung aalisin mo ang default na landas na ito mula sa routing table, pagkatapos ay kasabay ng dnsmasq openconnect ay dapat matiyak ang normal na operasyon.
sinubukan ko
route del defaultAt lahat ay gumana.
Mga kahilingan sa pagruruta sa isang mail server na walang vpn-slice
Ngunit mayroon din akong mail server na may address na 555.555.555.555, na kailangan ding ma-access sa pamamagitan ng VPN. Kailangan ding manu-manong idagdag ang ruta patungo dito.
ip route add 555.555.555.555 via dev tun0At ngayon maayos na ang lahat. Kaya maaari mong gawin nang walang vpn-slice, ngunit kailangan mong malaman kung ano ang iyong ginagawa. Iniisip ko na ngayon ang tungkol sa pagdaragdag sa huling linya ng native na openconnect script ang pag-alis ng default na ruta at pagdaragdag ng ruta para sa mailer pagkatapos kumonekta sa vpn, para lang mas kaunting gumagalaw na bahagi sa aking bike.
Malamang, sapat na ang afterword na ito para maunawaan ng isang tao kung paano mag-set up ng VPN. Ngunit habang sinusubukan kong maunawaan kung ano at kung paano gawin, nabasa ko ang napakaraming mga gabay na gumagana para sa may-akda, ngunit sa ilang kadahilanan ay hindi gumagana para sa akin, at nagpasya akong idagdag dito ang lahat ng mga piraso na nakita ko. Ako ay magiging napakasaya tungkol sa isang bagay na tulad nito.
Pinagmulan: www.habr.com