Дали сакате да користите Linux на работа, но вашата корпоративна VPN не ви дозволува? Тогаш оваа статија може да помогне, иако тоа не е сигурно. Би сакал однапред да ве предупредам дека не ги разбирам добро прашањата за администрирање на мрежата, па затоа е можно да сум направил сè погрешно. Од друга страна, можно е да напишам водич на таков начин што ќе биде разбирлив за обичните луѓе, па затоа ве советувам да го пробате.
Статијата содржи многу непотребни информации, но без ова знаење немаше да можам да ги решам проблемите што неочекувано ми се појавија со поставување на VPN. Мислам дека секој што ќе се обиде да го користи ова упатство ќе има проблеми што јас ги немав, и се надевам дека овие дополнителни информации ќе помогнат сами да се решат овие проблеми.
Повеќето од командите што се користат во овој водич треба да се извршуваат преку sudo, кој е отстранет за краткост. Имај на ум.
Повеќето IP адреси се сериозно замаглени, па ако видите адреса како 435.435.435.435, мора да има некоја нормална IP адреса, специфична за вашиот случај.
Имам Ubuntu 18.04 април, но мислам дека упатството може да се примени и на други дистрибуции со мали прилагодувања. Сепак, во овој текст, Linux == Ubuntu.
Cisco Connect
Оние кои седат на Windows или MacOS може да се поврзе со нашата корпоративна VPN преку Cisco Connect, што бара наведување на адресата на гејтвејот и внесување лозинка што се состои од фиксен дел и код генериран од Google Authenticator секој пат кога ќе се поврзат.
Во случајот со Linux, не можев да го активирам Cisco Connect, но успеав да побарам препорака за користење openconnect на Google, направена специјално за замена на Cisco Connect.
Отвори поврзување
Во теорија, Ubuntu има специјален графички интерфејс за openconnect, но тоа не функционираше за мене. Можеби е на подобро.
На Ubuntu, openconnect е инсталиран од менаџерот на пакети.
apt install openconnectВеднаш по инсталацијата, можете да се обидете да се поврзете со VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com е адреса на фиктивна VPN
poxvuibr - фиктивно корисничко име
openconnect ќе побара да внесеш лозинка која, да потсетам, се состои од фиксен дел и код од Google Authenticator, а потоа ќе се обиде да се поврзе со vpn. Ако работи, честитки, можете безбедно да ја прескокнете средината, што е многу болна, и да продолжите на точката за openconnect што работи во позадина. Ако не работи, тогаш можете да продолжите. Иако работеше кога се поврзувате, на пример, од гостински Wi-Fi на работа, тогаш можеби е премногу рано да се радувате, треба да се обидете да ја повторите постапката од дома.
Сертификат
Постои голема веројатност ништо да не започне, а излезот 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 key
И можете да дознаете кој сертификат серверот ни го испрати директно од она што 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Можеби сега тоа функционира, тогаш можете да продолжите до крајот. Но, лично, Ubunta ми покажа смоква во оваа форма
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, ќе треба сами да го сфатите ова. Ако има прашања во коментарите, ќе напишам посебен пост за ова. Но, ова е редовна програма на Python, така што не треба да има никакви тешкотии. Инсталирав користејќи 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 -- на скрипта се пренесува низа со команда што треба да се повика наместо скриптата. ./bin/vpn-slice - патека до извршната датотека vpn-slice 192.168.430.0/24 - маска на адреси на кои треба да се оди во vpn. Овде, мислиме дека ако адресата започнува со 192.168.430, тогаш ресурсот со оваа адреса треба да се пребарува во VPN
Сега ситуацијата треба да биде речиси нормална. За малку. Сега можете да отидете на Habr и можете да одите до внатрекорпоративниот ресурс преку IP, но не можете да отидете до внатрекорпоративниот ресурс со симболично име. Ако наведете совпаѓање помеѓу симболичното име и адресата во домаќините, сè треба да работи. И работете додека не се смени ip-от. Linux сега може да пристапи на Интернет или на интранет, во зависност од IP-адресата. Но, некорпоративниот DNS сè уште се користи за одредување на адресата.
Проблемот може да се манифестира и во оваа форма - на работа сè е во ред, но дома можете да пристапите само до внатрешните корпоративни ресурси преку IP. Тоа е затоа што кога сте поврзани на корпоративен Wi-Fi, се користи и корпоративниот DNS, а во него се решаваат симболични адреси од VPN, и покрај тоа што сè уште е невозможно да се оди на таква адреса без користење на VPN.
Автоматска модификација на датотеката на домаќините
Ако vpn-slice се праша учтиво, тогаш по подигнувањето на VPN, може да отиде во неговиот DNS, да ги најде IP адресите на потребните ресурси со нивните симболични имиња и да ги внесе во хостовите. По исклучувањето на VPN, овие адреси ќе се отстранат од домаќините. За да го направите ова, треба да пренесете симболични имиња на 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
Ако има малку адреси во мрежата, тогаш пристапот за автоматско менување на датотеката на домаќините работи доста добро. Но, ако има многу ресурси на мрежата, тогаш постојано ќе треба да додавате линии како 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, Linux оди на корпоративниот DNS, а ако е потребно нешто друго, тогаш на стандардниот.
Барав на Гугл подолго време и открив дека таквата функционалност е достапна во Ubuntu надвор од кутијата. Ова значи можност за користење на локалниот DNS-сервер dnsmasq за решавање на имињата.
Односно, можете да бидете сигурни дека Linux секогаш оди до локалниот DNS-сервер за IP адреси, кој пак, во зависност од името на доменот, ќе ја бара IP-а на соодветниот надворешен DNS-сервер.
За да управува со сè што е поврзано со мрежи и мрежни конекции, Ubuntu користи NetworkManager, а графичкиот интерфејс за избирање, на пример, Wi-Fi конекции е само преден крај за него.
Ќе треба да се искачиме во неговата конфигурација.
- Направете датотека во /etc/NetworkManager/dnsmasq.d/evilcorp
адреса=/.evilcorp.com/192.168.430.534
Обрнете внимание на точката пред evilcorp. Тоа сигнализира dnsmasq дека сите поддомени на evilcorp.com треба да се пребаруваат во корпоративниот dns.
- Кажете му на NetworkManager да користи dnsmasq за резолуција на името
Конфигурацијата на менаџерот на мрежата се наоѓа во /etc/NetworkManager/NetworkManager.conf Треба да додадете таму:
[главно]
dns=dnsmasq
- Рестартирајте го NetworkManager
service network-manager restartСега, откако ќе се поврзете со VPN користејќи openconnect и vpn-slice, IP-а ќе се одреди нормално, дури и ако не додавате симболични адреси на аргументите на vpnslice.
Како да пристапите до индивидуални услуги преку VPN
Откако успеав да се поврзам на VPN, бев многу среќен два дена, а потоа се покажа дека ако се поврзам на VPN надвор од канцелариската мрежа, тогаш поштата не работи. Симптомот е познат, нели?
Нашата пошта се наоѓа на mail.publicevilcorp.com, што значи дека не потпаѓа под правилото во dnsmasq и адресата на серверот за пошта се пребарува преку јавниот DNS.
Па, канцеларијата сè уште користи DNS, кој ја содржи оваа адреса. Така мислев. Всушност, по додавањето на линијата во dnsmasq
адреса=/mail.publicevilcorp.com/192.168.430.534
ситуацијата воопшто не е променета. ip остана иста. Морав да одам на работа.
И дури подоцна, кога навлегов подлабоко во ситуацијата и малку го разбрав проблемот, еден паметен ми кажа како да го решам. Беше неопходно да се поврзете со серверот за пошта не само така, туку преку VPN
Јас користам vpn-slice за да одам преку VPN до адреси кои започнуваат со 192.168.430. И серверот за пошта не само што има симболична адреса што не е поддомен на evilcorp, тој исто така нема IP адреса што започнува со 192.168.430. И, се разбира, тој не дозволува никој од општата мрежа да дојде кај него.
За да може Linux да помине низ 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 се погрижија за нас и додадоа посебен клуч на програмата -позадина, што ја прави програмата да работи во позадина по стартувањето. Ако го стартувате вака, можете да ја затворите конзолата по стартувањето
#!/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 користејќи grep и да барате процес чие име содржи openconnect, но ова е некако досадно. Благодарност до авторите кои размислуваа и за ова. Openconnect има клуч -pid-датотека, со која можете да му наложите на 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 $(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-парче. Наместо послеговор
Се покажа дека е многу тешко да се разбере како да се живее без VPN-slice. Морав многу да читам и да гуглам. За среќа, откако поминавте толку многу време со проблем, техничките прирачници, па дури и човекот openconnect читаа како возбудливи романи.
Како резултат на тоа, дознав дека vpn-slice, како мајчин скрипта, ја менува рутирачката табела за одделни мрежи.
Табела за насочување
Едноставно кажано, ова е табела во првата колона која содржи што треба да започне со адресата низ која сака да помине Linux, а во втората колона низ кој мрежен адаптер да помине на оваа адреса. Всушност, има повеќе звучници, но ова не ја менува суштината.
За да ја видите рутирачката табела, треба да ја извршите командата 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, Linux направи виртуелен адаптер - tun0. Линијата гарантира дека сообраќајот за сите адреси кои започнуваат со 192.168 поминува низ неа
192.168.0.0/16 dev tun0 scope link Можете исто така да ја погледнете моменталната состојба на рутирачката табела користејќи ја командата траса -н (IP-адресите се паметно анонимизирани) Оваа команда дава резултати во различна форма и генерално е застарена, но нејзиниот излез често се наоѓа во прирачниците на Интернет и треба да можете да ја читате.
Каде треба да започне IP адресата за маршрута може да се разбере од комбинацијата на колоните Дестинација и Genmask. Оние делови од IP адресата што одговараат на броевите 255 во Genmask се земени предвид, но оние каде што има 0 не се. Односно, комбинацијата на Дестинација 192.168.0.0 и Genmask 255.255.255.0 значи дека ако адресата започнува со 192.168.0, тогаш барањето до неа ќе оди по оваа рута. И ако Дестинацијата 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Таму, веднаш до него, веднаш се означува друга патека, која мора да се користи доколку адресата низ која се обидува да помине Linux не се совпаѓа со ниедна маска од табелата.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Овде веќе е напишано дека во овој случај треба да користите стандарден адаптер за Wi-Fi.
Верувам дека 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. Но, додека се обидував да разберам што и како да правам, прочитав доста такви водичи кои работат за авторот, но поради некоја причина не ми функционираат и решив овде да ги додадам сите парчиња што ги најдов. Јас би бил многу среќен за такво нешто.
Извор: www.habr.com
