Бажаєте використовувати лінукс на роботі, але корпоративний VPN не дає? Тоді ця стаття може допомогти, хоч це не точно. Хочу заздалегідь попередити, що питання адміністрування мереж я розумію погано, тому не виключено, що все зробив неправильно. З іншого боку, не виключено, що я зможу написати керівництво так, що воно буде зрозумілим звичайним людям, тож раджу спробувати.
У статті багато зайвої інформації, але без цих знань я не зміг би вирішити проблеми, які в мене зненацька з'являлися з налаштуванням vpn. Думаю, що у будь-кого, хто спробує застосувати це керівництво, виникнуть проблеми, яких я не мав, і сподіваюся, що ця зайва інформація допоможе ці проблеми самостійно вирішити.
Більшість команд, що використовуються в посібнику, потрібно виконувати через sudo, який для стислості прибраний. Майте на увазі.
Більшість ip адрес зазнали жорстокого обфускування, тому якщо бачите адресу на кшталт 435.435.435.435 — там має бути якась нормальна ip, специфічна для вашого випадку.
У мене Ubuntu 18.04, але думаю з невеликими редагуваннями керівництво можна застосовувати і до інших дистрибутивів. Однак у цьому тексті лінукс = Ubuntu.
Cisco Connect
Ті, хто сидить на Windows або MacOS, можуть підключитися до нашого корпоративного VPN через Cisco Connect, якому потрібно вказати адресу гейтвея і при кожному підключенні вводити пароль, що складається з фіксованої частини та коду, що генерується Google Authenticator.
У випадку з Лінуксом, завести Cisco Connect не вдалося, зате вдалося набридлити рекомендацію використовувати OpenConnect, зроблений спеціально для того, щоб замінити Cisco Connect.
Openconnect
За ідеєю в убунті є спеціальний графічний інтерфейс для OpenConnect, але в мене він не заробив. Може воно і на краще.
У бунті Openconnect ставиться з пакетного менеджера.
apt install openconnectВідразу після встановлення можна спробувати підключитися до VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com це адреса вигаданого VPN
poxvuibr - ім'я вигаданого користувача
openconnect попросить ввести пароль, який, нагадаю, складається з фіксованої частини та коду Google Authenticator, а потім спробує підключитися до vpn. Якщо вийшло, вітаю, можете сміливо пропускати середину в якій багато болю та переходити до пункту про роботу Openconnect у фоні. Якщо не запрацювало, можна продовжувати. Хоча якщо вийшло при підключенні з гостьового вайфая на роботі, то можна радіти і рано, треба спробувати повторити процедуру з дому.
Сертифікат
З високою ймовірністю нічого не запуститься, а вихлоп 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 не дозволяє ходити до інтернету.
Взагалі не дуже незручно, коли для того, щоб сходити на хабр, доводиться використовувати окремий комп'ютер. Відсутність можливості копіпастити зі stackoverfow, взагалі може паралізувати роботу, тому що треба щось робити.
Потрібно якось організувати, щоб колись треба зайти на ресурс із внутрішньої мережі, лінукс ходив у vpn, а коли треба зайти на хабр — ходив в інтернет.
openconnect після запуску та встановлення з'єднання з vpn виконує спеціальний скрипт, який знаходиться в /usr/share/vpnc-scripts/vpnc-script. У скрипт на вхід передаються якісь змінні, а він робить налаштування vpn. На жаль, я не зміг розібратися, як розділити потоки трафіку між корпоративним vpn та рештою інтернету за допомогою рідного скрипту.
Мабуть спеціально для таких як я була розроблена утиліта vpn-slice, яка дозволяє спрямовувати трафік двома каналами без танців з бубном. Ну, тобто танцювати доведеться, але при цьому шаманом бути не обов'язково.
Поділ трафіку за допомогою vpn-slice
По-перше, vpn-slice доведеться поставити, з цим доведеться розібратися самостійно. Якщо у коментарях будуть питання, я напишу з цього приводу окрему посаду. Але це звичайна програма на пітоні, тож складнощів бути не повинно. Я ставив за допомогою virtualenv.
А далі утиліту треба застосувати, за допомогою ключа -script вказавши openconnect, що замість стандартного скрипта потрібно використовувати vpn-slice
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 " vpn.evilcorp.com В —script передається рядок із командою, яку потрібно викликати замість скрипта. ./bin/vpn-slice - шлях до виконуваного файлу vpn-slice 192.168.430.0/24 - маска адрес, за якими слід ходити до vpn. Тут, мається на увазі, що якщо адреса починається з 192.168.430 — то ресурс із цією адресою потрібно шукати всередині vpn
Тепер ситуація має бути майже нормальною. Майже. Тепер можна зайти на хабр і можна зайти на внутрішньокорпоративний ресурс по IP, але не можна зайти на внутрішньокорпоративний ресурс за символьним ім'ям. Якщо прописати відповідність символьного імені та адреси hosts — все має заробити. І працювати, поки IP не зміниться. Лінукс тепер вміє ходити в інтернет або у внутрішньокорпоративну мережу залежно від IP. Але для визначення адреси, як і раніше, використовується не корпоративний DNS.
Проблема ще може виявлятися в такому вигляді - на роботі все нормально, а вдома на внутрішньокорпоративні ресурси можна зайти лише по IP. Це тому, що коли ти підключений до корпоративного Wi-Fi, то DNS використовується теж корпоративний, і в ньому символьні адреси з VPN ресолвяться, незважаючи на те, що пройти за такою адресою без використання VPN, як і раніше, не можна.
Автоматична модифікація файлу hosts
Якщо vpn-slice ввічливо попросити, він може після підняття VPN сходити до її DNS, знайти там ip адреси необхідних ресурсів з їх символьним іменам і вписати в hosts. Після вимкнення VPN ці адреси будуть видалені з hosts. Для цього потрібно передати символьні імена в vpn-slice як аргументи. Ось так.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com Тепер все має працювати і в офісі та на пляжі.
Шукати адреси всіх піддоменів у DNS, який віддала VPN
Якщо адрес всередині мережі небагато, підхід з автоматичною модифікацією файлу hosts цілком робочий. Але якщо ресурсів у мережі багато, то вам постійно треба буде додавати в скрипт рядка на зразок zoidberg.test.evilcorp.com zoidberg це так звати один із тестових стендів.
Але тепер, коли ми трохи розуміємо, до чого цю необхідність можна усунути.
Якщо після підняття VPN подивитися в /etc/hosts, то можна побачити, ось такий рядок
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
Та й у resolv.conf було додано новий рядок. Коротше, vpn-slice якимось чином визначила, де знаходиться dns сервер для vpn.
Тепер треба зробити так, щоб для того, щоб дізнатися ip адресу доменного імені, що закінчується на evilcorp.com, лінукс ходив у корпоративний dns, а якщо треба щось інше, то дефолтний.
Я досить довго гуглив і виявив, що така функціональність є в убунті з коробки. Йдеться про можливість використовувати для ресолва імен локальний dns сервер dnsmasq.
Тобто можна зробити так, щоб за IP адресами лінукс завжди ходив у локальний DNS сервер, який у свою чергу, залежно від доменного імені, буде шукати IP на відповідному зовнішньому DNS сервері.
Для управління всім, пов'язаним з мережами та мережевими з'єднаннями, в убунті використовується NetworkManager, а графічний інтерфейс для вибору, наприклад, вайфай з'єднання - просто фронт до нього.
Нам треба буде полазити у його конфігурації.
- Створити файл у /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Зверніть увагу на точку перед evilcorp. Вона сигналізує dnsmasq, що всі піддомени evilcorp.com треба шукати саме в корпоративному dns.
- Сказати NetworkManager, що для дозволу імен треба використовувати dnsmasq
Конфігурація network-manager знаходиться в /etc/NetworkManager/NetworkManager.conf Треба додати туди:
[main] dns=dnsmasq
- Перезапустити NetworkManager
service network-manager restartТепер, після підключення до VPN за допомогою зв'язки openconnect і vpn-slice, ip буде нормально визначитись, навіть якщо не додавати символьні адреси в аргументи до vpnslice.
Як ходити через VPN в окремі сервіси
Після того, як вдалося підключитися до vpn, я два дні дуже радів, а потім з'ясувалося, що якщо підключатися до впн не з офісної мережі, то не працює пошта. Симптом знайомий, чи не так?
Пошта у нас знаходиться в mail.publicevilcorp.com, а значить не підпадає під правило в dnsmasq і адреса поштового сервера шукається через публічний DNS.
Ну а в офісі все одно використовується DNS, в якому ця адреса є. Тобто, я так думав. Насправді після додавання до dnsmasq рядка
address=/mail.publicevilcorp.com/192.168.430.534
ситуація не змінилася. ip залишився той самий. Довелося мені ходити на роботу.
І вже потім, коли я заглибився в ситуацію і трохи розібрався в проблемі, одна розумна людина підказала мені, як її вирішити. Потрібно було підключатися до поштового сервера не просто так, а через vpn
Я використовую vpn-slice, щоб ходити через VPN на адреси, які починаються з 192.168.430. А у поштового сервера не лише символьна адреса не є піддоменом evilcorp, у нього ще й адреса ip не починається з 192.168.430. І із загальної мережі він, звичайно, нікого до себе не пускає.
Для того, щоб лінукс ходив через VPN та до поштового сервера, потрібно додати до vpn-slice та його. Допустимо адресу поштовика-555.555.555.555
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 555.555.555.555 192.168.430.0/24" vpn.evilcorp.com Скрипт для підняття VPN з одним аргументом
Все це, звісно, не дуже зручно. Так, можна зберегти текст у файл і копіпастить в консольку, а не набирати руками, але все одно приємного мало. Для полегшення процесу можна загорнути команду в скрипт, який перебуватиме у PATH. І тоді потрібно буде лише ввести код, отриманий із Google Authenticator
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com Якщо помістити скрипт у connect~evilcorp~ то можна буде просто писати в консолі
connect_evil_corp 567987Але тепер все одно доведеться навіщось тримати консоль в якій запущений Openconnect відкритою
Запуск Openconnect у фоні
На щастя, автори openconnect подбали про нас і додали в програму спеціальний ключ —background, який робить так, щоб програма після запуску працювала у фоні. Якщо запустити її так, то консоль після запуску можна закрити
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
--user poxvuibr
--passwd-on-stdin
--background
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com Тепер лише незрозуміло, куди йдуть логи. Логи нам загалом не дуже потрібні, але мало. Openconnect може перенаправити їх у syslog, де вони будуть зберігатися в цілісності та безпеці. потрібно цього треба додати в команду ключ -syslog
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
--user poxvuibr
--passwd-on-stdin
--background
--syslog
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com І ось, виходить, що OpenConnect працює десь там у фоні і нікому не заважає, але як його зупинити незрозуміло. Тобто можна, звичайно, відфільтрувати вихлоп ps грепом і шукати процес у назві якого є Openconnect, але це якось нудно. Дякую авторам, які подумали і про це. В openconnect є ключик -pid-file, за допомогою якого можна проінструктувати openconnect писати ідентифікатор свого процесу у файл.
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
--user poxvuibr
--passwd-on-stdin
--background
--syslog
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com
--pid-file ~/vpn-pidТепер завжди можна прибити процес командою
kill $(cat ~/vpn-pid)Якщо процесу немає, kill свариться, але помилку не кине. Якщо файлу немає, то теж не станеться нічого страшного, так що можна сміливо вбивати процес у першому рядку скрипту.
kill $(cat ~/vpn-pid)
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
--user poxvuibr
--passwd-on-stdin
--background
--syslog
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com
--pid-file ~/vpn-pidТепер можна увімкнути комп'ютер, відкрити консоль і запустити команду, передавши їй код із Google Authenticator. Консоль потім можна прибити.
Без vpn-slice. Замість післямови
Зрозуміти, як жити без vpn-slice, виявилося дуже складно. Довелося багато читати та гуглити. На щастя, коли стільки часу провів із проблемою, технічні мануали і навіть man openconnect читаються як захоплюючі романи.
У результаті я з'ясував, що vpn-slice, як і рідний скрипт, модифікує таблицю маршрутизації для поділу мереж.
Таблиця маршрутизації
Це, спрощено кажучи, така таблиця в першій колонці якої міститься з чого повинна починатися адреса, якою хоче пройти лінукс, а в другій через якийсь мережевий адаптер за цією адресою пройти. Насправді стовпчиків більше, але суті це не змінює.
Щоб подивитися таблицю маршрутизації потрібно виконати команду ip route
default via 192.168.1.1 dev wlp3s0 proto dhcp metric 600
192.168.430.0/24 dev tun0 scope link
192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.534 metric 600
192.168.430.534 dev tun0 scope link Тут кожен рядок відповідає за те, куди треба пройти для того, щоб надіслати повідомлення на якусь адресу. Першим йде опис, з чого має починатися адреса. Для того, щоб зрозуміти як визначити, що 192.168.0.0/16 означає, що адреса повинна починатися з 192.168, потрібно погуглити що таке маска ip адреси. Після dev знаходиться ім'я адаптера, в який треба надсилати повідомлення.
Для VPN лінукс зробив віртуальний адаптер – tun0. За те, щоб трафік для всіх адрес починаються з 192.168 йшов через нього відповідає рядок
192.168.0.0/16 dev tun0 scope link Ще подивитися на стан таблиці маршрутизації можна за допомогою команди маршрут -n (ip адреси талановиті анонімізовані) Ця команда видає результати в іншому вигляді і взагалі deprecated, але її вихлоп часто трапляється в мануалах в інтернеті і треба вміти його читати.
З чого повинен починати IP адресу для маршруту можна зрозуміти з комбінації колонок Destination і Genmask. Ті частини IP адреси, яким у Genmask відповідають цифри 255, враховуються, а ті, де там 0 - ні. Тобто комбінація Destination 192.168.0.0 та Genmask 255.255.255.0 означає, що якщо адреса починається з 192.168.0, то запит до неї піде цим маршрутом. А якщо Destination 192.168.0.0 та Genmask 255.255.0.0, то цим маршрутом підуть запити до адрес, які починаються з 192.168
Для того, щоб розібратися, що насправді робить vpn-slice, я вирішив подивитися на стани таблиць до і після
До включення VPN було так
route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0
222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0
333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0Після виклику openconnect без vpn-slice стало так
route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0
222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0
333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0
192.168.430.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.430.534 0.0.0.0 255.255.255.255 UH 0 0 0 tun0А після виклику openconnect в комбінації з vpn-slice ось так
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0
222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0
333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0
192.168.430.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.430.534 0.0.0.0 255.255.255.255 UH 0 0 0 tun0Видно, що якщо не використовувати vpn-slice, то openconnect явно пише, що по всіх адресах, крім окремо зазначених, треба ходити через vpn.
Ось тут:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Там поруч відразу вказано ще один шлях, який треба використовувати, якщо адреса, якою намагається пройти лінукс, не відповідає жодній масці з таблиці.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Тут уже написано, що в такому разі треба ходити через стандартний вайфай адаптер.
Я вважаю, що шлях для VPN використовується тому, що він у таблиці маршрутизації перший.
І теоретично, якщо прибрати цей дефолтний шлях з таблиці маршрутизації, то у зв'язці з dnsmasq openconnect повинен забезпечувати нормальну роботу.
Я спробував
route del defaultІ все запрацювало.
Роутинг запитів до поштового сервера без vpn-slice
Але ж у мене є ще поштовий сервер з адресою 555.555.555.555, на який теж треба ходити через vpn. Маршрут до нього також треба додати руками.
ip route add 555.555.555.555 via dev tun0І ось тепер все норм. Так що обійтися без vpn-slice можна, але вже треба добре знати, що робиш. Я зараз думаю не додати чи в останній рядок рідного скрипту openconnect видалення дефолтного маршруту і додавання маршруту для поштовика після підключення до vpn, просто, щоб рухомих частин у моєму велосипеді стало менше.
Напевно, комусь для того, щоб зрозуміти як налаштувати VPN, вистачило б цього післямови. Але я, поки намагався зрозуміти, що і як мені робити, прочитав досить багато таких посібників, які працюють у автора, але чомусь не працюють у мене і вирішив додати сюди всі шматочки, які знайшов. Я б чомусь такому дуже потішився.
Джерело: habr.com