Искате ли да използвате 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, но успях да намеря в Google препоръка за използване на openconnect, направена специално, за да замени Cisco Connect.

отворено свързване

На теория Ubuntu има специален графичен интерфейс за openconnect, но не работи за мен. Може би е за добро.

В Ubuntu openconnect се инсталира от мениджъра на пакети.

apt install openconnect

Веднага след инсталирането можете да опитате да се свържете с VPN

openconnect --user poxvuibr vpn.evilcorp.com

vpn.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

И можете да разберете кой сертификат ни е изпратил сървърът директно от отпечатаното от 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

/ И т.н. / resolv.conf

# Generated by NetworkManager
search gst.evilcorpguest.com
nameserver 127.0.0.53

/run/resolvconf/resolv.conf

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 192.168.430.534
nameserver 127.0.0.53
search evilcorp.com gst.publicevilcorp.com

habr.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 не ви позволява да сърфирате в интернет.

Като цяло не е много неудобно, когато трябва да използвате отделен компютър, за да отидете на Habr. Невъзможността за копиране и поставяне от stackoverfow може като цяло да парализира работата, така че трябва да се направи нещо.

Трябва по някакъв начин да го организираме така, че когато имате нужда от достъп до ресурс от вътрешната мрежа, Linux отива към VPN, а когато трябва да отидете до Habr, той отива към Интернет.

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 

--script се предава низ с команда, която трябва да бъде извикана вместо скрипта. ./bin/vpn-slice - път до изпълнимия файл на vpn-slice 192.168.430.0/24 - маска на адресите, към които да отидете във vpn. Тук имаме предвид, че ако адресът започва с 192.168.430, тогава ресурсът с този адрес трябва да се търси в VPN

Сега ситуацията трябва да е почти нормална. почти. Сега можете да отидете до Habr и можете да отидете до вътрешнокорпоративния ресурс чрез ip, но не можете да отидете до вътрешнокорпоративния ресурс чрез символично име. Ако зададете съвпадение между символното име и адреса в hosts, всичко трябва да работи. И работи докато ip-то се промени. Linux вече има достъп до интернет или интранет, в зависимост от IP. Но некорпоративен DNS все още се използва за определяне на адреса.

Проблемът може да се прояви и под тази форма - на работа всичко е наред, но у дома можете да получите достъп до вътрешните корпоративни ресурси само чрез IP. Това е така, защото когато сте свързани към корпоративен Wi-Fi, се използва и корпоративният DNS и в него се разрешават символни адреси от VPN, въпреки факта, че все още е невъзможно да отидете на такъв адрес без да използвате VPN.

Автоматично модифициране на файла hosts

Ако 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

Ако има малко адреси в мрежата, тогава подходът за автоматично модифициране на файла hosts работи доста добре. Но ако има много ресурси в мрежата, тогава постоянно ще трябва да добавяте редове като zoidberg.test.evilcorp.com към скрипта zoidberg е името на един от тестовите стендове.

Но сега, когато разбираме малко защо тази необходимост може да бъде премахната.

Ако след повдигане на VPN погледнете в /etc/hosts, можете да видите този ред

192.168.430.534 dns0.tun0 # vpn-slice-tun0 АВТОМАТИЧНО СЪЗДАДЕНО

И беше добавен нов ред към resolv.conf. Накратко, vpn-slice по някакъв начин определи къде се намира dns сървърът за vpn.

Сега трябва да се уверим, че за да разберем IP адреса на име на домейн, завършващо на evilcorp.com, Linux отива към корпоративния DNS и ако е необходимо нещо друго, тогава към този по подразбиране.

Търсих в Google доста време и открих, че такава функционалност е налична в Ubuntu веднага. Това означава възможност за използване на локалния DNS сървър dnsmasq за разрешаване на имена.

Тоест можете да се уверите, че Linux винаги отива към локалния DNS сървър за IP адреси, който от своя страна, в зависимост от името на домейна, ще търси IP на съответния външен DNS сървър.

За да управлява всичко, свързано с мрежите и мрежовите връзки, Ubuntu използва NetworkManager, а графичният интерфейс за избор например на Wi-Fi връзки е само преден край към него.

Ще трябва да се изкачим в неговата конфигурация.

1. Създайте файл в /etc/NetworkManager/dnsmasq.d/evilcorp

адрес=/.evilcorp.com/192.168.430.534

Обърнете внимание на точката пред evilcorp. Той сигнализира на dnsmasq, че всички поддомейни на evilcorp.com трябва да се търсят в корпоративния dns.

1. Кажете на NetworkManager да използва dnsmasq за разрешаване на имена

Конфигурацията на мрежовия мениджър се намира в /etc/NetworkManager/NetworkManager.conf Трябва да добавите там:

[основен] dns=dnsmasq

1. Рестартирайте 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 ще проклина, но няма да изведе грешка. Ако файлът не е там, тогава няма да се случи нищо лошо, така че можете спокойно да убиете процеса в първия ред на скрипта.

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. Трябваше да чета и да търся много. За щастие, след като сте прекарали толкова много време с проблем, техническите ръководства и дори man 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, трябва да потърсите в Google какво представлява IP адресната маска. След dev има името на адаптера, към който трябва да се изпрати съобщението.

За VPN Linux направи виртуален адаптер - tun0. Линията гарантира, че трафикът за всички адреси, започващи с 192.168, преминава през нея

192.168.0.0/16 dev tun0 scope link 

Можете също така да видите текущото състояние на таблицата за маршрутизиране, като използвате командата маршрут -n (IP адресите са умело анонимизирани) Тази команда дава резултати в различна форма и като цяло е отхвърлена, но изходът й често се намира в ръководствата в Интернет и трябва да можете да я прочетете.

Къде трябва да започне IP адресът за маршрут може да се разбере от комбинацията от колоните Destination и Genmask. Тези части от IP адреса, които съответстват на числата 255 в Genmask, се вземат предвид, но тези, където има 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

Там до него веднага се посочва друг път, който трябва да се използва, ако адресът, през който се опитва да премине 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