Искате ли да използвате 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/
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 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, указвайки 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 адресът не се промени. 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, а ако трябва нещо друго, то в дефолтния.
Доста дълго време гуглих и открих, че такава функционалност има в Ubuntu от самото начало. Става въпрос за възможността за ресолва на имена с локален DNS сървър dnsmasq.
Тоест може да се направи така, че Linux винаги да ходи за IP адреси в локалния 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 с greping и да търсите процеса, в името на който има 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, подобно на родния скрипт, модифицира таблицата за маршрутизация за разделяне на мрежи.
Таблица за маршрутизация
Това, опростено казано, е таблица, в първата колона на която се съдържа от какво трябва да започне адресът, по който 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 Можете да видите текущото състояние на таблицата за маршрутизация с помощта на командата route -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
Ядро IP таблици за маршрутиране
Дестинация Gateway Genmask Флагове Метричност Референция Употреба Интерфейс
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 таблици за маршрутиране
Дестинация Gateway Genmask Флагове Метричност Референция Употреба Интерфейс
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 се използва, защото е първи в таблицата за маршрутиране.
И теоретично, ако премахнете този дефолтен маршрут от таблицата за маршрутиране, openconnect в комбинация с dnsmasq трябва да осигури нормална работа.
Опитах
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
