Жадаеце выкарыстоўваць лінукс на працы, але карпаратыўны VPN не дае? Тады гэты артыкул можа дапамагчы, хаця гэта не дакладна. Жадаю загадзя папярэдзіць, што пытанні адміністравання сетак я разумею дрэнна, таму не выключана, што я ўсё зрабіў няправільна. З іншага боку не выключана, што я змагу напісаць кіраўніцтва так, што яно будзе зразумелае звычайным людзям, так што раю паспрабаваць.
У артыкуле шмат лішняй інфармацыі, але без гэтых ведаў я б не змог вырашыць праблемы, якія ў мяне нечакана з'яўляліся з настройкай vpn. Думаю, што ў любога, хто паспрабуе прымяніць гэтае кіраўніцтва, узнікнуць праблемы, якіх у мяне не было, і спадзяюся, што гэтая лішняя інфармацыя дапаможа гэтыя праблемы самастойна вырашыць.
Большасць каманд, якія выкарыстоўваюцца ў кіраўніцтве трэба выконваць праз sudo, які для сцісласці прыбраны. Майце на ўвазе.
Большасць ip адрасоў падвергліся жорсткай абфускацыі, таму калі бачыце адрас накшталт 435.435.435.435 – там павінен быць нейкі нармальны ip, спецыфічны для вашага выпадку.
У мяне Ubuntu 18.04/XNUMX, але думаю з невялікімі праўкамі кіраўніцтва можна ўжываць і да іншых дыстрыбутываў. Аднак у гэтым тэксце лінукс == Ubuntu.
Cisco Connect
Тыя, хто сядзіць на Windows або MacOS могуць падлучыцца да нашага карпаратыўнага VPN праз Cisco Connect, якому трэба паказаць адрас гейтвея і пры кожным падключэнні ўводзіць пароль, які складаецца з фіксаванай часткі і кода, які генеруецца Google Authenticator.
У выпадку з Лінукс, завесці Cisco Connect не атрымалася, затое атрымалася нагугліць рэкамендацыю выкарыстоўваць openconnect, зроблены адмыслова для таго, каб замяніць Cisco Connect.
Openconnect
Па ідэі ва ўбунце ёсць спецыяльны графічны інтэрфейс для openconnect але ў мяне ён не зарабіў. Можа яно і да лепшага.
Ва ўбунце openconnect ставіцца з пакетнага мэнэджара.
apt install openconnectАдразу пасля ўстаноўкі можна паспрабаваць падключыцца да VPN.
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com гэта адрас выдуманага VPN
poxvuibr - імя выдуманага карыстальніка
openconnect папросіць увесці пароль, які, нагадаю, складаецца з фіксаванай часткі і кода з Google Authenticator, а потым паспрабуе падлучыцца да vpn. Калі атрымалася, віншую, можаце смела прапускаць сярэдзіну, у якой шмат болю і пераходзіць да пункта пра працу openconnect у фоне. Калі не зарабіла, то можна працягваць. Хоць калі атрымалася пры падлучэнні напрыклад з гасцявога вайфая на працы, тое магчыма цешыцца і ранавата, трэба паспрабаваць паўтарыць працэдуру з хаты.
Cертификат
З высокай верагоднасцю нічога не запусціцца, а выхлап openconnect будзе выглядаць неяк вось так:
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З аднаго боку гэта непрыемна, таму што да VPN падлучэнні не адбылося, але з іншага боку як паправіць гэтую праблему ў прынцыпе зразумела.
Тут сервер даслаў нам сертыфікат, па якім можна вызначыць, што падлучэнне адбываецца менавіта да сервера роднай карпарацыі, а не да злоснага ашуканца, а сістэме гэты сертыфікат невядомы. І таму яна не можа праверыць, сапраўдны сервер ці не. І таму на ўсялякі выпадак спыняе працу.
Для таго, каб openconnect усёткі падлучыўся да сервера, трэба відавочна сказаць яму, які сертыфікат павінен прыйсці ад VPN сервера з дапамогай дапамогай ключа — servercert
А даведацца які сертыфікат нам даслаў сервер можна прама з таго, што надрукаваў openconnect. Вось з гэтага кавалка:
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Вось такой камандай можна паспрабаваць падключыцца яшчэ раз
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comМагчыма зараз зарабіла, тады можна пераходзіць да канца. Але асабіста мне Убунта паказала дулю вось у такой форме
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.comhabr.com будзе салявіцца, але зайсці туды будзе нельга. Адрасы тыпу jira.evilcorp.com наогул не салявяцца.
Што тут адбылося, мне не зразумела. Але эксперымент паказвае, што калі дадаць у /etc/resolv.conf радок
nameserver 192.168.430.534то адрасы ўсярэдзіне VPN пачнуць магічнай выявай салявіцца і па іх можна будзе хадзіць, гэта значыць тое, што шукае якімі DNS салавіць адрасы, глядзіць менавіта ў /etc/resolv.conf, а не кудысьці яшчэ.
Што падлучэнне да VPN ёсць і яно працуе, можна пераканацца і без правак у /etc/resolv.conf, для гэтага дастаткова ўвесці ў браўзэры не сымбальнае імя рэсурсу з vpn, а яго ip адрас
Па выніку атрымліваецца дзве праблемы
- пры падключэнні да VPN не падхапляецца яе dns
- увесь трафік ідзе праз vpn, які не дазваляе хадзіць у інтэрнэт
Што рабіць я зараз раскажу, але спачатку крыху аўтаматызацыі.
Аўтаматычны ўвод фіксаванай часткі пароля
Да бягучага моманту вы хутчэй за ўсё ўжо ўвялі пароль не менш за пяць разоў і гэтая працэдура вас ужо ладна стаміла. Па-першае, таму што пароль доўгі, па-другое таму што пры ўводзе трэба ўкласціся ў фіксаваны часавы прамежак
Канчатковае вырашэнне праблемы ў артыкул не ўвайшло, але можна зрабіць так, каб фіксаваную частку пароля не прыйшлося ўводзіць па шмат разоў.
Дапусцім, фіксаваная частка пароля - fixedPassword, а частка з Google Authenticator 567. Увесь пароль цалкам openconnect можна перадаць праз стандартны ўвод з дапамогай аргументу -passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinЦяпер можна пастаянна вяртацца да апошняй уведзенай каманды і мяняць там толькі частку з Google Authenticator.
Карпаратыўны VPN не дазваляе хадзіць у інтэрнэт.
Наогул не вельмі няёмка, калі для таго, каб схадзіць на хабр даводзіцца выкарыстоўваць асобны кампутар. Адсутнасць магчымасці копіпасціць са stackoverfow, наогул можа паралізаваць працу, таму што трэба нешта рабіць.
Трэба неяк арганізаваць, каб калі трэба зайсці на рэсурс з унутранай сеткі, лінукс хадзіў у vpn, а калі трэба зайсці на хабр – хадзіў у інтэрнэт.
openconnect пасля запуску і ўстаноўкі злучэння з vpn, выконвае спецыяльны скрыпт, які знаходзіцца ў /usr/share/vpnc-scripts/vpnc-script. У скрыпт на ўваход перадаюцца нейкія зменныя, а ён робіць наладу vpn. Нажаль, я не змог разабрацца, як падзяліць струмені трафіку паміж карпаратыўным vpn і астатнім інтэрнэтам з дапамогай роднага скрыпту.
Мабыць спецыяльна для такіх як я была распрацавана ўтыліта vpn-slice, якая дазваляе накіроўваць трафік па двух каналах без танцаў з бубнам. Ну, гэта значыць танцаваць давядзецца, але шаманам пры гэтым быць не абавязкова.
Падзел трафіку з дапамогай vpn-slice
Па-першае vpn-slice давядзецца паставіць, з гэтым давядзецца разабрацца самастойна. Калі ў каментарах будуць пытанні, я напішу з гэтай нагоды асобную пасаду. Але гэта звычайная праграма на пітоне, так што цяжкасцей быць не павінна. Я ставіў з дапамогай virtualenv.
А далей утыліту трэба ўжыць, з дапамогай ключа -script паказаўшы openconnect, што замест стандартнага скрыпту трэба выкарыстоўваць 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 перадаецца радок з камандай, якую трэба выклікаць замест скрыпту. ./bin/vpn-slice - шлях да выкананага файла vpn-slice 192.168.430.0/24 - маска адрасоў, па якіх варта хадзіць у vpn. Тут, маецца на ўвазе што калі адрас пачынаецца з 192.168.430 - то рэсурс з гэтым адрасам трэба шукаць усярэдзіне vpn.
Цяпер сітуацыя павінна быць амаль нармальнай. Амаль. Цяпер можна зайсці на хабр і можна зайсці на ўнутрыкарпаратыўны рэсурс па ip, але нельга зайсці на ўнутрыкарпаратыўны рэсурс па знакавым імені. Калі прапісаць адпаведнасць знакальнага імя і адрасы ў hosts - усё павінна зарабіць. І працаваць, пакуль ip не памяняецца. Лінукс зараз умее хадзіць у інтэрнэт або ва ўнутрыкарпаратыўную сетку ў залежнасці ад ip. Але для вызначэння адраса па-ранейшаму выкарыстоўваецца не карпаратыўны DNS.
Праблема яшчэ можа выяўляцца ў такім выглядзе – на працы ўсё нармальна, а дома на ўнутрыкарпаратыўныя рэсурсы можна зайсці толькі па ip. Гэта таму што калі ты падлучаны да карпаратыўнага Wi-Fi, то DNS выкарыстоўваецца таксама карпаратыўны, і ў ім знакавыя адрасы з VPN салявяцца, нягледзячы на ??тое, што прайсці па такім адрасе без выкарыстання VPN па-ранейшаму нельга.
Аўтаматычная мадыфікацыя файла hosts
Калі vpn-slice ветліва папытаць, то ён можа пасля ўзняцця VPN схадзіць у яе DNS, знайсці тамака ip адрасы патрэбных рэсурсаў па іх знакавым імёнам і ўпісаць іх у hosts. Пасля выключэння VPN гэтыя адрасы будуць выдаленыя з hosts. Для гэтага трэба перадаць знакавыя імёны ў vpn-slice у якасці аргументаў. Вось так.
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 Цяпер усё павінна працаваць і ў офісе і на пляжы.
Шукаць адрасы ўсіх паддаменаў у DNS, які аддала VPN
Калі адрасоў усярэдзіне сетак трохі, то падыход з аўтаматычнай мадыфікацыяй файла hosts суцэль працоўны. Але калі рэсурсаў у сетцы шмат, то вам увесь час трэба будзе дадаваць у скрыпт радка накшталт zoidberg.test.evilcorp.com zoidberg гэта так клічуць адзін з тэставых стэндаў.
Але цяпер, калі мы крыху разумеем што да чаго гэтую неабходнасць можна ўхіліць.
Калі пасля падняцця VPN паглядзець у /etc/hosts, то можна ўбачыць, вось такі радок
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
Ды і ў resolv.conf быў дададзены новы радок. Карацей, vpn-slice нейкім чынам вызначыла, дзе знаходзіцца dns сервер для vpn.
Зараз трэба зрабіць так, каб для таго, каб пазнаць ip адрас даменнага імя, які канчаецца на evilcorp.com, лінукс хадзіў у карпаратыўны dns, а калі трэба нешта іншае, то ў дэфолтны.
Я даволі доўга гугліў і выявіў, што такая функцыянальнасць ёсць ва ўбунте са скрынкі. Маецца на ўвазе магчымасць выкарыстоўваць для рэсаловы імёнаў лакальны dns сервер dnsmasq.
Гэта значыць можна зрабіць так, каб за ip адрасамі лінукс заўсёды хадзіў у лакальны dns сервер, які ў сваю чаргу, у залежнасці ад даменнага імя, будзе шукаць ip на які адпавядае вонкавым dns серверы.
Для кіравання ўсім, звязаным з сеткамі і сеткавымі злучэннямі, ва ўбунце выкарыстоўваецца NetworkManager, а графічны інтэрфейс для выбару, напрыклад, вайфай злучэння - проста фронт да яго.
Нам трэба будзе палазіць у яго канфігурацыі.
- Стварыць файл у /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Звярніце ўвагу на кропку перад evilcorp. Яна сігналізуе dnsmasq, што ўсе паддамены evilcorp.com трэба шукаць менавіта ў карпаратыўным dns.
- Сказаць NetworkManager, што для дазволу імёнаў трэба выкарыстоўваць dnsmasq
Канфігурацыя network-manager знаходзіцца ў /etc/NetworkManager/NetworkManager.conf Трэба дадаць туды:
[main] dns=dnsmasq
- Перазапусціць NetworkManager
service network-manager restartЗараз, пасля падлучэння да VPN з дапамогай звязкі openconnect і vpn-slice, ip будзе нармальна вызначацца, нават калі не дадаваць знакавыя адрасы ў аргументы да vpnslice.
Як хадзіць праз VPN у асобныя сэрвісы
Пасля таго, як атрымалася падлучыцца да vpn, я дні два вельмі радаваўся, а потым высветлілася, што калі падлучацца да впн не з офіснай сеткі, то не працуе пошта. Сімптом знаёмы, ці не праўда?
Пошта ў нас знаходзіцца ў mail.publicevilcorp.com, а значыць не пападае пад правіла ў dnsmasq і адрас паштовага сервера шукаецца праз публічны DNS.
Ну а ў офісе ўсё роўна выкарыстоўваецца DNS, у якім гэты адрас ёсць. Гэта значыць, я так думаў. На справе пасля дадання ў dnsmasq радкі
address=/mail.publicevilcorp.com/192.168.430.534
сітуацыя ніяк не змянілася. ip застаўся той жа. Прыйшлося мне хадзіць на працу.
І ўжо потым, калі я паглыбіўся ў сітуацыю і крыху разабраўся ў праблеме, адзін разумны чалавек падказаў мне як яе вырашыць. Трэба было падлучацца да паштовага сервера не проста так, а праз vpn.
Я выкарыстоўваю vpn-slice, каб хадзіць праз VPN па адрасах, якія пачынаюцца з 192.168.430. А ў паштовага сервера не толькі знакавы адрас не з'яўляецца паддаменам evilcorp, у яго яшчэ і ip адрас не пачынаецца з 192.168.430. І з агульнай сеткі ён, вядома, нікога да сябе не пускае.
Для таго, каб лінукс хадзіў праз VPN і да паштовага сервера, трэба дадаць у vpn-slice і яго. Дапусцім адрас паштара-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 Скрыпт для ўзняцця VPN з адным аргументам
Усё гэта, канешне, не вельмі зручна. Так, можна захаваць тэкст у файлік і копіпасціць у кансольку, а не набіраць рукамі, але ўсё роўна прыемнага мала. Для палягчэння працэсу можна загарнуць каманду ў скрыпт, які будзе знаходзіцца ў PATH. І тады трэба будзе толькі ўвесці код, атрыманы з 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 Калі змясціць скрыпт у connect~evilcorp~ то можна будзе проста пісаць у кансолі
connect_evil_corp 567987Але зараз усё роўна прыйдзецца навошта-то трымаць кансоль у якой запушчаны openconnect адчыненай
Запуск openconnect у фоне
На шчасце аўтары openconnect паклапаціліся пра нас і дадалі ў праграму спецыяльны ключ -background, які робіць так, каб праграма пасля запуску працавала ў фоне. Калі запусціць яе вось так, то кансоль пасля запуску можна зачыніць
#!/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 Цяпер толькі незразумела, куды ідуць логі. Лагі нам увогуле не моцна патрэбныя, але ці мала. openconnect можа перанакіраваць іх у syslog, дзе яны будуць захоўвацца ў цэласнасці і захаванасці. трэба гэтага трэба дадаць у каманду ключ -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 І вось, атрымліваецца, што openconnect працуе дзесьці тамака ў фоне і нікому не мяшае, але як яго спыніць незразумела. Гэта значыць можна, вядома адфільтраваць выхлап ps грэпам і шукаць працэс у назове якога ёсць openconnect, але гэта неяк моташна. Дзякуй аўтарам, якія падумалі і пра гэта. У openconnect ёсць ключык -pid-file, з дапамогай якога можна праінструктаваць openconnect пісаць ідэнтыфікатар свайго працэсу ў файл.
#!/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Цяпер заўсёды можна прыбіць працэс камандай
kill $(cat ~/vpn-pid)Калі працэсу няма, kill лаецца, але памылку не кіне. Калі файла няма, тое таксама не здарыцца нічога страшнага, так што можна смела забіваць працэс у першым радку скрыпту.
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Цяпер можна ўключыць кампутар, адкрыць кансоль і запусціць каманду, перадаўшы ёй код з Google Authenticator. Кансоль потым можна прыбіць.
Без vpn-slice. Замест пасляслоўя
Зразумець, як жыць без vpn-slice аказалася вельмі складана. Прыйшлося шмат чытаць і гугліць. Да шчасця, калі столькі часу правёў з праблемай, тэхнічныя мануалы і нават man openconnect чытаюцца як захапляльныя раманы.
У выніку я высветліў, што vpn-slice, як і родны скрыпт, для падзелу сетак мадыфікуе табліцу маршрутызацыі.
Табліца маршрутызацыі
Гэта, спрошчана кажучы, такая табліца ў першай калонцы якой утрымоўваецца з чаго павінен пачынацца адрас, па якім жадае мінуць лінукс, а ў другой праз які сеткавы адаптар па гэтым адрасе мінуць. Насамрэч калонак больш, але сутнасці гэта не мяняе.
Каб паглядзець табліцу маршрутызацыі трэба выканаць каманду 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 Тут кожны радок адказвае за тое, куды трэба прайсці для таго, каб даслаць паведамленне па нейкім адрасе. Першым ідзе апісанне, з чаго павінен пачынацца адрас. Для таго, каб зразумець як вызначыць, што 192.168.0.0/16 азначае, што адрас павінен пачынацца з 192.168 трэба трошкі што такое маска ip адрасы. Пасля dev знаходзіцца імя адаптара, у які трэба слаць паведамленне.
Для VPN лінукс зрабіў віртуальны адаптар – tun0. За тое, каб трафік для ўсіх адрасоў, якія пачынаюцца з 192.168, ішоў праз яго, адказвае радок.
192.168.0.0/16 dev tun0 scope link Яшчэ паглядзець на бягучы стан табліцы маршрутызацыі можна з дапамогай каманды маршрут -n (ip адрасы таленавіта ананімізаваныя) Гэтая каманда выдае вынікі ў іншым выглядзе і наогул deprecated, але яе выхлап часта трапляецца ў мануалах у інтэрнэце і трэба ўмець яго чытаць.
З чаго павінен пачынаць IP адрас для маршруту можна зразумець з камбінацыі калонак Destination і Genmask. Тыя часткі ip адрасы, якім у Genmask адпавядаюць лічбы 255, улічваюцца, а тыя, дзе тамака 0 — не. Гэта значыць камбінацыя Destination 192.168.0.0 і Genmask 255.255.255.0 азначае, што калі адрас пачынаецца з 192.168.0, то запыт да яго пайдзе па гэтым маршруце. А калі Destination 192.168.0.0 але Genmask 255.255.0.0, то па гэтым маршруце пайдуць запыты да адрасоў, якія пачынаюцца з 192.168.
Для таго, каб разабрацца, што на самой справе робіць vpn-slice я вырашыў паглядзець на станы табліц да і пасля
Да ўключэння VPN было так
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Пасля выкліку openconnect без vpn-slice сталася так
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А пасля выкліку openconnect у камбінацыі з vpn-slice вось так
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Відаць, што калі не выкарыстоўваць vpn-slice, то openconnect відавочна піша, што па ўсіх адрасах, акрамя асобна паказаных, трэба хадзіць праз vpn.
Вось тут:
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Тут ужо напісана, што ў такім разе трэба хадзіць праз стандартны адаптар вайфа.
Я мяркую, што шлях для VPN выкарыстоўваецца таму, што ен у табліцы маршрутызацыі першы.
І тэарэтычна, калі прыбраць вось гэты дэфолтны шлях з табліцы маршрутызацыі, то ў звязку з dnsmasq openconnect павінен забяспечваць звычайную працу.
Я паспрабаваў
route del defaultІ ўсё зарабіла.
Роўтынг запытаў да паштовага сервера без vpn-slice
Але ж у мяне ёсць яшчэ паштовы сервер з адрасам 555.555.555.555, на які таксама трэба хадзіць праз vpn. Маршрут да яго таксама трэба дадаць рукамі.
ip route add 555.555.555.555 via dev tun0І вось зараз усё нормаў. Так што абысціся без vpn-slice можна, але ўжо трэба добра ведаць, што робіш. Я зараз думаю не дадаць ці ў апошні радок роднага скрыпту openconnect выдаленне дэфолтнага маршруту і даданне маршруту для паштара пасля падлучэння да vpn, проста, каб рухаюцца частак у маім ровары стала паменш.
Мусіць, камусьці для таго, каб зразумець як наладзіць VPN хапіла б гэтага пасляслоўя. Але я, пакуль спрабаваў зразумець што і як мне рабіць, прачытаў дастаткова шмат такіх кіраўніцтваў, якія працуюць у аўтара, але чамусьці не працуюць у мяне і вырашыў дадаць сюды ўсе кавалачкі, якія знайшоў. Я б нечаму такому вельмі парадаваўся.
Крыніца: habr.com