Искате да използвате 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, създаден специално, за да замести Cisco Connect.
Openconnect
В 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/
Свързано с 777.777.777.777:443
SSL преговори с vpn.evilcorp.com
Валидирането на сертификата на сървъра се провали: подписващият не е намерен
Сертификатът от VPN сървъра "vpn.evilcorp.com" не успя да премине валидацията.
Причина: не е намерен подписващ
За да се доверите на този сървър в бъдеще, може би добавете това към вашия команден ред:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Въведете 'да', за да приемете, 'не', за да прекратите; всичко друго, за да видите: fgets (stdin): Операция сега в прогресОт една страна, това е неприятно, защото свързването с VPN не е станало, но от друга страна, как да поправим този проблем е принципно ясно.
Тук сървърът ни е изпратил сертификат, по който можем да определим, че свързването става именно със сървъра на родната корпорация, а не с злата измамник, а системата не познава този сертификат. И затова не може да провери дали сървърът е истински или не. И по тази причина, за всеки случай, прекратява работата си.
За да успее openconnect да се свърже със сървъра, е нужно явно да му кажете кой сертификат трябва да дойде от VPN сървъра с помощта на ключа —servercert
А за да разберем кой сертификат ни е изпратил сървърът, можем да го видим направо от това, което е печатал openconnect. Ето от този фрагмент:
За да се доверите на този сървър в бъдеще, може би добавете това към вашия команден ред:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Въведете 'да', за да приемете, 'не', за да прекратите; всичко друго, за да видите: fgets (stdin): Операция сега в прогресС такава команда можете да опитате да се свържете отново
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comМоже би сега е проработило, тогава можете да преминете към края. Но лично на мен Убунту показа пръст в такава форма
POST https://vpn.evilcorp.com/
Свързано с 777.777.777.777:443
SSL преговори с vpn.evilcorp.com
Проверка на сертификат на сървъра не беше успешна: подписващият не беше намерен
Свързано с HTTPS на vpn.evilcorp.com
XML POST е активиран
Моля, въведете вашето потребителско име и парола.
POST https://vpn.evilcorp.com/
Получен отговор CONNECT: HTTP/1.1 200 OK
CSTP свързано. DPD 300, Keepalive 30
Настройването на DTLS неуспешно; използва се SSL вместо това
Свързано като 192.168.333.222, използващи SSL
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
RTNETLINK отговори: Файлът съществува
/etc/resolvconf/update.d/libc: Предупреждение: /etc/resolv.conf не е символна връзка към /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 987. Цялата парола openconnect може да бъде предадена чрез стандартния вход с помощта на аргумента --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinСега можете постоянно да се връщате към последната въведена команда и да променяте само частта от Google Authenticator.
Корпоративният VPN не позволява достъп до интернет.
Неправилно е, когато за да посетите хабр, трябва да използвате отделен компютър. Липсата на възможност за копипейст от stackoverflow може наистина да парализира работата, затова е нужно нещо да се направи.
Необходимо организовать, чтобы при доступе к ресурсу из внутренней сети Linux использовал VPN, а когда нужно заходить на Хабр — выходил в Интернет.
OpenConnect после запуска и установления соединения с VPN выполняет специальный скрипт, расположенный в /usr/share/vpnc-scripts/vpnc-script. В скрипт передаются некоторые переменные, после чего он настраивает VPN. К сожалению, я не смог разобраться, как разделить потоки трафика между корпоративным VPN и остальным Интернетом с помощью стандартного скрипта.
Похоже, что специально для таких случаев была разработана утилита vpn-slice, которая позволяет направлять трафик по двум каналам без лишних хлопот. То есть, работать придется, но шаманом быть не обязательно.
Разделение трафика с использованием vpn-slice
Во-первых, vpn-slice нужно установить, с этим придется разобраться самостоятельно. Если в комментариях будут вопросы, я напишу по этому поводу отдельный пост. Но это обычная программа на Python, поэтому трудностей возникнуть не должно. Я устанавливал с помощью virtualenv.
А затем утилиту нужно применить, указав ключ —script, чтобы использовать вместо стандартного скрипта 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 не поменяется. Linux теперь может выходить в Интернет или во внутреннюю корпоративную сеть в зависимости от 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, Linux да търси в корпоративния DNS, а ако трябва нещо друго, то в дефолтния.
Доста време търсих в Google и открих, че такава функционалност съществува в Ubuntu по подразбиране. Става въпрос за възможността да се използва локален DNS сървър за резолване на имена, dnsmasq.
Тоест може да се направи така, че за IP адресите Linux винаги да ходи в локалния DNS сървър, който от своя страна, в зависимост от домейното име, ще търси IP на съответния външен DNS сървър.
За управление на всичко, свързано с мрежи и мрежови връзки в Ubuntu, се използва NetworkManager, а графичният интерфейс за избор, например, на Wi-Fi връзка, е просто преден интерфейс към него.
Ще трябва да разгледаме конфигурацията му.
- Създайте файл в /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, бях много радостен два дни, а след това разбрах, че ако се свързвате с 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. И от публичната мрежа, разбира се, не пуска никого при себе си.
За да може 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 се погрижиха за нас и добавиха в програмата специален ключ —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 с grep и да търсите процеса с името 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 Също така, текущото състояние на таблицата за маршрутизация може да се види с командата route -n (IP адресите умело анонимизирани) Тази команда дава резултати в друга форма и е изцяло остаряла, но изходът ѝ често може да бъде намерен в ръководства в интернет, така че е необходимо да знаете как да го прочетете.
Откъде трябва да започва 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 стана така
маршрут -н
Таблица маршрутизации ядра IP
Цель Шлюз Маска подсети Флаги Метрика Ссылка Использовать Интерфейс
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 ето как
Таблица маршрутизации ядра IP
Цел Шлюз Маска подсети Флаги Метрика Ссылка Использовать Интерфейс
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Тук е написано, че в такъв случай трябва да се премине през стандартния WI-FI адаптер.
Предполагам, че маршрутът за VPN се използва, защото той е първи в таблицата за маршрутизация.
И теоретично, ако премахнем този подразбиращ се маршрут от таблицата за маршрутизация, openconnect в комбинация с dnsmasq трябва да осигури нормална работа.
Опитах
маршрут 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
