Легкий доступ до всіх ваших речей за допомогою сітчастої VPN без довіри

Джон Герцен

changelog.complete.org

33 хв

13 квітня 2023 р

Напевно всі знайомі зі звичайним VPN. Традиційним варіантом використання є підключення до корпоративної чи домашньої мережі з віддаленого місця та доступ до послуг, ніби ви там.

Але сьогодні поняття «корпоративна мережа» та «домашня мережа» менше базуються на фізичному розташуванні. Наприклад, компанія може взагалі не мати окремого офісу, може мати кілька офісів плюс кілька людей, які працюють віддалено, тощо. Домашня мережа може мати, скажімо, PVR і файловий сервер, тоді як портативні пристрої, такі як ноутбуки, планшети та телефони, можуть спілкуватися один з одним незалежно від місця розташування. Наприклад, член сім’ї може подорожувати з ноутбуком, інший – у кафе, і ці два пристрої можуть захотіти спілкуватися, окрім спілкування з пристроями вдома.

І в обох сценаріях можуть виникнути запитання щодо надання обмеженого доступу друзям. Можливо, ви бажаєте надати другові доступ до частини вашого файлового сервера або, як компанія, ви можете мати підрядників, які працюють над обмеженим проектом.

Невдовзі ви опинитесь у безладі VPN, перенаправлених портів і трюків, щоб усе це запрацювало. Зі зростанням поширеності CGNAT багато разів ви навіть не можете відкрити порт для публічного Інтернету. Кожен додаток або пристрій, ймовірно, має власний шлюз, щоб зробити його видимим в Інтернеті, за деякі з яких ви платите.

Потім ви додаєте питання: чи варто справді довіряти своїй локальній мережі? З огляду на можливості використання цього послуги гостями, шахрайські точки доступу тощо, відповідь, мабуть, «ні».

Ми можемо перенести відповідальність за роботу з NAT, коливаннями IP-адрес, шифруванням і автентифікацією з прикладного рівня далі в мережевий стек. Тоді ми отримуємо набагато простішу картину для всіх.

Отже, ця сторінка в основному призначена для того, щоб мережа працювала просто та ефективно.

Як зробити так, щоб Інтернет працював у цих сценаріях?

Ми об’єднаємо три концепції:

VPN, що забезпечує повністю зашифрований і автентифікований зв’язок і стабільні IP-адреси
Mesh Networking , у якому пристрої автоматично знаходять оптимальні шляхи зв’язку один з одним
Мережа з нульовою довірою , у якій нам не потрібно нічого довіряти щодо основної локальної мережі, тому що весь наш трафік використовує захищені системи в пунктах 1 і 2.

Поєднуючи ці концепції, ми досягаємо гарних результатів:

Ви можете ssh hostname, де ім’я хоста – це одна з ваших машин (сервер, ноутбук тощо), і, доки він hostnameпрацює, ви можете отримати до нього доступ, де б він не був, де б ви не були.
- У поєднанні з mosh ці сеанси будуть довговічними навіть при переході до інших хост-мереж.
- Ви також можете використовувати telnet, оскільки основна мережа має бути безпечною.
Вам не потрібно возитися з ключами шифрування, сертифікатами тощо для кожної внутрішньої служби. Оскільки IP-адреси тепер надійні, це все, що вам потрібно. hosts.allow може повернутися!
У вас є спосіб вийти з надзвичайно обмежених мереж. Кожен інструмент, який тут обговорюється, має спосіб повернутися до маршрутизації через посередника (ретранслятор) на TCP-порт 443, якщо все інше не допомагає.

Іноді можуть бути компроміси. Наприклад:

У локальних мережах зі швидкістю понад 1 Гбіт/с продуктивність може знизитися через витрати на шифрування та інкапсуляцію. Однак ці інструменти повинні дозволяти хостам виявляти розташування один одного і не надсилати трафік через Інтернет, якщо пристрої локальні.
За допомогою деяких із цих інструментів локальні один від одного хости (в тій самій локальній мережі) можуть не знайти один одного, якщо вони не можуть отримати доступ до рівня керування через Інтернет (інтернет не працює або постачальник не працює)

Деякі інші функції, які надають деякі інструменти, включають:

Легкий обмін обмеженим доступом з друзями/гостями
Подбати про все, що вам потрібно, включаючи сертифікати SSL, для надання певної внутрішньомережевої служби загальнодоступному Інтернету
Додаткова маршрутизація вашого вихідного Інтернет-трафіку через вихідний вузол у вашій мережі. Корисно, наприклад, якщо ваша локальна мережа блокує безліч речей.

Давайте зануримося.

Типи Mesh VPN

У цій статті я розгляну декілька типів сіток:

Повністю децентралізовано з автоматичною маршрутизацією
Ця модель не має спеціальної центральної площини управління. Вузли виявляють один одного різними способами та встановлюють маршрути один до одного. Ці маршрути можуть бути прямими з’єднаннями через Інтернет або через інші вузли. Цей підхід забезпечує найбільшу стійкість. Приклади, про які я розповім, включають Іґдрасіль і тинк.
Автоматичний одноранговий з централізованим керуванням
У цій моделі вузли за замовчуванням спілкуються шляхом встановлення прямих зв’язків між ними. Звичайний вузол ніколи не передає трафік від імені інших вузлів. Спеціальні реле використовуються для обробки випадків, коли обхід NAT неможливий. Цей підхід зазвичай пропонує просте налаштування. Приклади, які я розгляну, включають Tailscale, Zerotier, Nebula та Netmaker.
Використовуйте власні та гібридні підходи
Це «сумка» інших ідей; наприклад, пробігти Ігґдрасіль над Хвостою лускою.

Термінологія

Заради послідовності я буду використовувати спільну мову для обговорення речей, які мають різні терміни в різних екосистемах:

Кожен інструмент, який тут обговорюється, має спосіб роботи з обходом NAT. Це може допомогти у встановленні прямих з'єднань (наприклад, STUN), і якщо це не вдається, воно може просто ретранслювати трафік між вузлами. Я буду називати таке реле «брокером». Це може бути або не бути та сама система, яка є площиною керування для інструменту.
Усі ці системи працюють на нижніх рівнях, які не шифруються. Такими нижніми рівнями може бути локальна мережа (дротова чи бездротова, яка може мати або не мати доступу до Інтернету) або загальнодоступний Інтернет (IPv4 та/або IPv6). Я буду називати незашифрований нижній рівень, як би він не був, «clearnet».

Критерії оцінювання

Ось що я хочу бачити від рішення:

Безпечний, із наскрізним шифруванням і автентифікацією всіх комунікацій і запобіганням трафіку з ненадійних пристроїв.
Гнучкий, швидко й автоматично адаптується до змін топології мережі.
Відмовостійкий, без єдиної точки відмови та з локальними пристроями, здатними спілкуватися, навіть якщо вони відключені від Інтернету чи інших частин мережі.
Конфіденційний, зведення до мінімуму витоку інформації або метаданих про мене та мої системи
Можливість проходити через CGNAT без використання брокера, коли це можливо
Менша вимога для мене, але все одно приємно мати, це можливість залучати інших через щось на зразок публікації в Інтернеті або запрошення гостей.
Повністю або майже повністю відкритий код
Безкоштовно або дуже дешево для особистого використання
Широка підтримка операційних систем, включаючи безголовий Linux на x86_64 та ARM.

Повністю децентралізовані VPN з автоматичною маршрутизацією

Цьому опису підходять дві системи: Yggdrasil і Tinc. Давайте зануримося.

Іґдрасіль

Я почну з Іггдрасіля , тому що я вже багато про нього написав. Це було представлено в попередніх публікаціях, таких як:

Yggdrasil може бути приватною мережею VPN або чимось більшим

Yggdrasil може бути приватною мережевою мережею VPN, як і інші інструменти, описані тут. Однак він унікальний тим, що ключовою метою проекту є також зробити його корисним як глобальну сітчасту мережу планетарного масштабу. Таким чином, Yggdrasil є випробувальним стендом нових ідей у розподіленій маршрутизації, призначених для масштабування до величезних розмірів і всіляких умов з’єднання. Станом на 10 квітня 2023 року основна глобальна сітка Yggdrasil налічує понад 5000 вузлів. Ви можете вибрати, брати участь чи ні.

Кожен вузол у сітці Yggdrasil має пару відкритих/приватних ключів. Тоді кожен вузол має адресу IPv6 (у приватному адресному просторі), отриману з його відкритого ключа. Використовуючи ці адреси IPv6, ви можете спілкуватися відразу.

Yggdrasil відрізняється від більшості інших інструментів тим, що він не обов’язково прагне встановити прямий зв’язок у чистій мережі між, скажімо, хостом A та хостом G, щоб вони могли спілкуватися. Він віддасть перевагу такому прямому зв’язку, якщо він існує, але буде цілком щасливий, якщо його немає.

Причина в тому, що кожен вузол Yggdrasil також є маршрутизатором у сітці Yggdrasil. Давайте трохи посидимо з цією концепцією. Розглянемо:

Якщо у вас є купа машин у вашій локальній мережі, але лише одна з них може працювати через Clearnet, це добре; всі інші машини відкриють цей шлях до світу та скористаються ним, коли це буде необхідно.
Все, що вам потрібно для роботи брокера, — це звичайний вузол із загальнодоступною IP-адресою. Якщо ви берете участь у глобальній сітці, ви можете використовувати для цієї мети один (чи більше) безкоштовних публічних вузлів .
Кожному вузлу не обов’язково знати IP-адресу clearnet кожного іншого вузла (підвищення конфіденційності). Фактично, кожному вузлу навіть не обов’язково знати про існування всіх інших вузлів, якщо він може знайти маршрут до певного вузла, коли його запитують.
Yggdrasil може знайти один або кілька маршрутів між вузлами, і він може використовувати ці знання про декілька маршрутів для агресивної оптимізації для різних умов мережі, включаючи комбінації, скажімо, завантажень і сеансів ssh з низькою затримкою.

За лаштунками Yggdrasil розраховує оптимальні маршрути між вузлами, якщо це необхідно, використовуючи DHT на всій сітці для початкового контакту, а потім виводячи більш оптимальні шляхи. (Ви також можете прочитати докладнішу інформацію про алгоритм маршрутизації.)

І останнє, чим Yggdrasil відрізняється від більшості інших інструментів, полягає в тому, що немає окремого сервера керування. Жоден вузол не є «особливим», відповідальним, єдиним зберігачем метаданих або чимось подібним. Вся система повністю розповсюджена та автоматично збирається.

Зустріч із сусідами

Є два способи, за якими Іґґдрасіль дізнається про однолітків:

Шляхом широкомовного виявлення в локальній мережі
Через прослуховування певного порту (або підключення до конкретного хосту/порту)

Іноді це може призвести до кількох способів підключення до вузла; Yggdrasil віддає перевагу з’єднанню, автоматично виявленому за допомогою трансляції, а потім найнижчій затримці визначеного шляху. Іншими словами, коли ваші ноутбуки знаходяться в одній кімнаті локальної локальної мережі, ваші пакети будуть передаватись безпосередньо між ними, не перетинаючи Інтернет.

Унікальні способи використання

Yggdrasil унікально підходить для мережевих складних ситуацій. Наприклад, у ситуації після стихійного лиха доступ до Інтернету може бути недоступним або нестабільним, але може бути багато локальних пристроїв – можливо, таких, які раніше не знали один про одного – які можуть обмінюватися інформацією. Іґґдрасіль ідеально відповідає цій ситуації. Комбінація широкомовного автоматичного виявлення, розподіленої маршрутизації тощо означає, що якщо між двома вузлами є будь-який фізичний шлях, Yggdrasil знайде та включить його.

Ad-hoc Wi-Fi використовується рідко, тому що це справжня проблема. Іггдрасіль насправді робить його корисним! Для його широкомовного виявлення взагалі не потрібна IP-адреса, надана в інтерфейсі (він лише використовує локальну адресу посилання IPv6), тому вам не потрібно з’ясовувати сервер DHCP чи щось подібне. І Yggdrasil буде прагнути виконувати маршрутизацію вздовж контурів радіочастотного тракту. Таким чином, у вас може бути ноутбук на великій відстані, який передає зв’язок від людей, які знаходяться далі, оскільки він може бачити обох. Або навіть ланцюжок таких речей.

Yggdrasil: Безпека та конфіденційність

Меш Іггдрасіля агресивно жадібний. Він зрівняється з будь-яким вузлом, який зможе знайти (якщо не вказано інше), і знайде маршрут до будь-якого місця, де зможе. Є два основних способи захистити вас від несанкціонованого трафіку: обмеживши доступ до вашої сітки та заблокувавши інтерфейс Yggdrasil. Можна використовувати як обидва, так і одночасно.

Я детальніше обговорю брандмауер у кінці цієї статті. По суті, ви майже напевно захочете зробити це, якщо берете участь у загальнодоступній сітці, тому що це схоже на глобальну маршрутизацію загальнодоступної IP-адреси безпосередньо на ваш пристрій.

Якщо ви хочете обмежити, хто може спілкуватися з вашою сіткою, просто вимкніть функцію трансляції на всіх ваших вузлах (порожній MulticastInterfacesрозділ у конфігурації) і не вказуйте жодному з ваших вузлів підключатися до публічного однорангового вузла. Ви можете встановити список авторизованих відкритих ключів, які можуть підключатися до інтерфейсів прослуховування ваших вузлів, що ви, ймовірно, захочете зробити. Ймовірно, ви захочете або відкрити кілька вхідних портів (якщо можете), або налаштувати вузол із відомою IP-адресою на такому місці, як $5/міс VPS, щоб допомогти з обходом NAT (знову ж таки, налаштуванняAllowedPublicKeysв міру необхідності). Yggdrasil не дозволяє фільтрувати багатоадресні клієнти за відкритим ключем, лише за мережевим інтерфейсом, тому ми вимикаємо виявлення широкомовної передачі. Ви можете досить легко навчити Іггдрасіля статичним внутрішнім IP-адресам локальної мережі ваших вузлів і змусити все працювати таким чином. (Або налаштуйте внутрішній «шлюз» або два вузли, до яких клієнти просто підключаються, коли вони локальні). Але по суті, вам потрібно трохи більше подумати над цим із Yggdrasil, ніж з іншими інструментами тут, які є лише закритими.

Порівняно з деякими іншими інструментами тут, Yggdrasil краще бореться з витоком інформації; вузли знають лише деталі, такі як IP-адреси Clearnet, прямо підключених однорангових вузлів. Ви можете отримати список прямо підключених однорангових вузлів будь-якого відомого вузла в сітці, але цей список є відкритими ключами прямо підключених однорангових вузлів, а не IP-адреси Clearnet.

Деякі інші інструменти містять певний обмежений інтегрований брандмауер (з обмеженими списками керування доступом тощо). Yggdrasil — ні, але він повністю сумісний із мережевими екранами на хості. Я все одно рекомендую їх навіть з багатьма іншими інструментами.

Yggdrasil: підключення та проходження NAT

У порівнянні з іншими інструментами, Yggdrasil є цікавою сумішшю. Він забезпечує повнофункціональну сітку та полегшує підключення в ситуаціях, у яких не може жоден інший інструмент. Проте його обхід NAT, хоча він існує та працює, призводить до використання брокера в деяких складніших ситуаціях CGNAT частіше, ніж деякі інші інструменти, що може перешкоджати продуктивності.

Базовий протокол Yggdrasil базується на TCP. Перш ніж ви втечете, кричачи, що він має бути повільним і ненадійним, як OpenVPN через TCP – це не так, і він навіть напрочуд хороший у боротьбі з буфером. Я виявив, що його продуктивність на одному рівні з іншими інструментами тут, і він працює так добре, як я очікував, навіть на нестабільних з’єднаннях 4G.

Загалом історія проходження NAT неоднозначна. З одного боку, ви можете запустити вузол, який слухає порт 443 – і Yggdrasil може навіть змусити його говорити TLS (хоча це непотрібно з точки зору безпеки), тож ви, ймовірно, зможете вийти з більшості обмежувальних брандмауерів, які вам коли-небудь доводилося стикатися. Якщо ви приєднаєтеся до загальнодоступної сітки, знайте, що багато публічних однорангових пристроїв слухають порт 443 (та інші добре відомі порти, такі як 53, а також випадкові порти з високими номерами).

Якщо ви підключите свою систему до кількох загальнодоступних однорангових пристроїв, існує ймовірність (хоча й дуже невелика) того, що частина трафіку громадського транспорту може проходити через неї. На практиці публічні однорангові вузли, як ми сподіваємось, уже взаємодіють один з одним, запобігаючи цьому (ви можете перевірити це за допомогою yggdrasilctl debug_remotegetpeers key=ABC...). Я ніколи не відчував проблеми з цим. Крім того, оскільки затримка є фактором маршрутизації для Yggdrasil, дуже малоймовірно, що випадкові з’єднання, які ми використовуємо, будуть конкурентоспроможними з аналогами центру обробки даних.

Іггдрасіль: ділитися з друзями

Якщо ви готові брати участь у публічній мережі, це одна з найпростіших речей. Попросіть свого друга встановити Yggdrasil, направте його на загальнодоступний вузол, дайте йому свою IP-адресу Yggdrasil, і все. (Ну, мабуть, ви також відкриваєте свій брандмауер – ви дотримувалися моєї поради щодо його налаштування, правда?)

Якщо ваш друг відвідує ваше місце розташування, він може просто підключитися до вашого Wi-Fi, встановити Yggdrasil, і він автоматично знайде маршрут до вас. Yggdrasil навіть має режим нульової конфігурації для ефемерних вузлів, таких як певні контейнери Docker.

Yggdrasil безпосередньо не підтримує публікацію в Clearnet, але, звичайно, можливо проксі (або навіть NAT) до/з Clearnet, і люди це роблять.

Іггдрасіль: DNS

В Yggdrasil немає особливого додаткового DNS. Ви, звичайно, можете запустити DNS-сервер в Yggdrasil, як і будь-де в іншому місці. Особисто я просто додаю відповідні хости /etc/hostsта залишаю це на цьому, але це залежить від вас.

Yggdrasil: вихідний код, ціни та портативність

Yggdrasil є повністю відкритим кодом (LGPLv3 плюс додаткові дозволи за винятком) і дуже портативним. Він написаний на Go та має попередньо зібрані двійкові файли для всіх основних платформ (включаючи пакет Debian , який я створив).

З Yggdrasil нічого не стягується. Публічні однолітки з переліку є безкоштовними та керуються волонтерами. Ви можете керувати своїми однолітками, якщо хочете; вони можуть бути загальнодоступними та приватними, загальнодоступними та перерахованими (просто надішліть PR, щоб отримати їх у списку) або приватними (приймають з’єднання лише з ключів певних вузлів). «Пір» у цьому випадку — це просто вузол із відомою IP-адресою.

Yggdrasil заохочує використання в інших проектах. Наприклад, NNCP інтегрує вузол Yggdrasil для легкого зв’язку з іншими вузлами NNCP.

Висновки Іггдрасіля

Yggdrasil є найкращим за надійністю (не має єдиної точки відмови) і гнучкістю. Він підтримуватиме опортуністичні зв’язки між однолітками, навіть якщо Інтернет не працює. Унікальна додаткова функція можливості бути частиною глобальної сітки є приємною. Компроміси включають більшу схильність до необхідності використовувати брокера в обмежувальних середовищах CGNAT. Деякі інші інструменти мають клієнти, які замінюють розпізнавач DNS ОС, щоб також забезпечити розпізнавання імен хостів членських вузлів; Yggdrasil — ні, хоча ви, звичайно, можете запустити власну інфраструктуру DNS через Yggdrasil (або, якщо на те пішло, дозволити загальнодоступним DNS-серверам надавати відповіді Yggdrasil, якщо хочете).

Також необхідно приділяти більше уваги брандмауерам або підтримці відокремлення від публічної сітки. Однак, як я поясню нижче, багато інших варіантів можуть мати потенційні наслідки, якщо рівень керування або ваш обліковий запис для нього скомпрометовано, тобто ви також повинні заблокувати їх. Тим не менш, це може бути більш безпосереднім занепокоєнням щодо Іґґдрасіля.

Незважаючи на те, що Yggdrasil вказано як експериментальний, я використовую його більше року і виявив, що він надійний. Вони дійсно змінили спосіб обчислення IP-адрес під час переходу з 0,3 до 0,4, що призвело до глобальної перенумерації, тому майте на увазі, що це можливість, поки вона експериментальна.

У мене є

tinc є найстарішим інструментом у цьому списку; версія 1.0 вийшла в 2003 році! Ви можете думати про tinc як про щось схоже на «старший Іґґдрасіль без публічного вибору».

Я буду обговорювати tinc 1.0.36, останню стабільну версію, яка вийшла в 2019 році. Гілка розробки, 1.1, існує з 2011 року, а останній випуск був випущений у 2021 році. Останній комміт до репо Github був у червні 2022 року. .

Tinc — єдиний інструмент, який підтримує інтерфейси tun і tap. Я детальніше ознайомлюся з різницею в огляді Zerotier нижче. Tinc фактично забезпечує кращу реалізацію крана, ніж Zerotier, з різними розумними опціями для трансляцій, але я все одно вважаю, що виклик Ethernet, на відміну від IP, VPN, невеликий.

Щоб налаштувати tinc , ви створюєте конфігурацію для кожного хоста, а потім розповсюджуєте її на кожен вузол tinc. Він містить відкритий ключ хоста. Таким чином, додавання хоста до сітки означає поширення його ключа всюди; скасування авторизації означає видалення його ключа всюди. Це робить його досить громіздким.

tinc може здійснювати виявлення трансляцій у локальній мережі та маршрутизацію сітки, але загалом ви повинні вручну навчити його, куди підключатися спочатку. Дещо заплутано, але всі приклади згадують перелік публічної адреси для вузла. Це не має сенсу для ноутбука, і я підозрюю, що ви просто пропустите це. Я думаю, що ця адреса використовується для чогось схожого на вузол Yggdrasil із публічною IP-адресою.

На відміну від усіх інших інструментів, описаних тут, tinc не має інструментів для перевірки стану роботи сітки.

Деякі властивості олова дали зрозуміти, що я навряд чи прийму його, тому цей огляд не був таким ретельним, як огляд Іґдрасіля.

tinc: Безпека та конфіденційність

Як згадувалося вище, кожен хост у сітці tinc автентифікується на основі свого відкритого ключа. Однак, якщо бути більш точним, цей ключ перевіряється лише в точці, коли він підключається до наступного однорангового переходу. (Звичайно, це також те саме, що й список дозволених pubkeys працює в Yggdrasil.) Оскільки IP-адреси в tinc не походять від їхнього ключа, і будь-який хост може призначити собі будь-який IP-адрес, який йому подобається, це означає, що скомпрометований хост міг видати себе за іншого.

Незрозуміло, чи наскрізно шифруються пакети при використанні вузла tinc як маршрутизатора. Той факт, що вони можуть маршрутизуватися на рівні ядра за допомогою інтерфейсу tun, означає, що вони можуть бути не такими.

У мене є: підключення та проходження NAT

Мені не вдалося знайти багато інформації про проходження NAT у tinc, окрім того, що він його підтримує. tinc може працювати через UDP або TCP і автоматично визначає, який використовувати, віддаючи перевагу UDP.

tinc: Обмін з друзями

У tinc немає спеціальної підтримки для цього, а через складність налаштування малоймовірно, що ви зробите це за допомогою tinc.

tinc: вихідний код, ціни та портативність

tinc є повністю відкритим кодом (GPLv2). Він написаний на C і, як правило, переносний. Він підтримує деякі дуже старі операційні системи. Мобільна підтримка сумнівна.

tinc, здається, не дуже активно підтримується.

У мене є висновки

Я не згадував продуктивність в інших своїх оглядах (див. розділ у кінці цієї публікації). Але він настільки поганий, що працює лише на 300 Мбіт/с у моїй мережі 2,5 Гбіт/с. Це 1/3 швидкості Ігґдрасіля чи Тейллуски. Поєднайте це з громіздкістю додавання хостів і певною невизначеністю в безпеці, і я не збираюся використовувати tinc.

Автоматичні однорангові мережі VPN із централізованим керуванням

Це, як правило, варіанти, які часто обговорюються. Поговоримо про варіанти.

Хвостова луска

Tailscale є популярним вибором у цьому типі VPN. Щоб використовувати Tailscale, ви спочатку зареєструєтесь на tailscale.com. Потім ви встановлюєте клієнт tailscale на кожній машині. Під час першого запуску він друкує URL-адресу, на яку ви можете натиснути, щоб авторизувати клієнта у вашій сітці («tailnet»). Tailscale призначає IP-адресу мережі для кожної системи. Клієнт Tailscale дозволяє площині керування Tailscale збирати IP-інформацію про кожен вузол, включаючи всі публічні та приватні IP-адреси, які можна виявити.

Коли ви намагаєтесь зв’язатися з вузлом через Tailscale, клієнт отримає відому контактну інформацію з рівня керування та спробує встановити зв’язок. Якщо він може зв’язатися через локальну локальну мережу, він це зробить (він не має автовизначення трансляції, як Yggdrasil; інформація має надходити з рівня керування). Інакше він спробує різні варіанти обходу NAT. Якщо нічого не допомагає, він використовуватиме посередника для ретрансляції трафіку; Tailscale називає брокера сервером ретрансляції DERP . На відміну від Yggdrasil, вузол Tailscale ніколи не передає трафік іншому; усі підключення є або прямими P2P, або через брокера.

Tailscale, як і деякі інші, базується на Wireguard; хоча wireguard-go, а не внутрішній Wireguard.

Tailscale має низку дещо унікальних особливостей у цьому просторі:

Funnel , який дозволяє надавати порти вашої системи загальнодоступному Інтернету через VPN.
Вузли виходу , які автоматизують процес маршрутизації вашого загальнодоступного Інтернет-трафіку через інший вузол у мережі. Це можливо з усіма інструментами, згаданими тут, але Tailscale дозволяє вмикати або вимикати його кількома швидкими командами.
Спільний доступ до вузла , що дає змогу ділитися підмножиною вашої мережі з гостями
Фантастичний набір документації , найкращий із усіх.

Воронка, зокрема, цікава. За допомогою кількох команд у стилі «tailscale serve» ви можете відкрити для світу дерево каталогів (або веб-сервер розробки). Tailscale надає вам загальнодоступне ім’я хосту, отримує для нього сертифікат і передає вам вхідний трафік. Це залежить від деяких невизначених обмежень пропускної здатності, і ви можете вибрати лише з трьох загальнодоступних портів, тому це не зовсім робоче рішення, але як швидкий і простий спосіб продемонструвати щось круте другові, це чудова функція.

Tailscale: безпека та конфіденційність

У Tailscale, як і в інших інструментах цієї категорії, однією з головних загроз, яку слід враховувати, є контрольна площина. Які наслідки компрометації рівня керування Tailscale або облікових даних, які ви використовуєте для доступу до нього?

Почнемо з облікових даних, які використовуються для доступу до нього. Tailscale сама не керує системою ідентифікації, натомість покладаючись на треті сторони. Для фізичних осіб це означає облікові записи Google, Github або Microsoft; Okta та інші SAML і подібні постачальники ідентифікаційної інформації також підтримуються, але це стикається зі складністю та витратами, які більшість людей не хочуть брати на себе. На жаль, усі три типи облікових записів часто мають збережені маркери автентифікації в браузері. Особисто я віддав би перевагу окремому, дуже безпечному логіну.

Якщо хтось скомпрометує ваш обліковий запис або самі сервери Tailscale, він не зможе безпосередньо прослуховувати ваш трафік, оскільки він зашифрований наскрізним. Однак якщо припустити, що зловмисник отримає доступ до вашого облікового запису, він може:

Втручатися в ваші ACL Tailscale, дозволяючи нові дії
Додайте нові вузли в мережу
Примусово видалити вузли з мережі
Увімкніть або вимкніть додаткові функції

Слід зазначити, що вони не можуть просто заволодіти наявною IP-адресою. Я б сказав, що найризикованішою можливістю тут є додавання нових вузлів до сітки. Оскільки вони також можуть втручатися у ваші ACL, вони можуть спробувати отримати доступ до всіх ваших внутрішніх служб. Вони навіть можуть увімкнути збір послуг і попросити Tailscale сказати їм, які та де є всі служби.

Тому, як і з іншими інструментами, я рекомендую локальний брандмауер на кожній машині з Tailscale. Детальніше про це нижче.

У Tailscale є нова альфа-функція під назвою tailnet lock , яка допомагає вирішити цю проблему. Він вимагає, щоб існуючі вузли в сітці підписали запит на приєднання нового вузла. Хоча це не стосується втручання ACL та деяких інших речей, це суттєва допомога у вирішенні найважливіших проблем. Однак tailnet lock знаходиться в альфа-версії, доступний лише в плані Enterprise і має список очікування, тому я не зміг його протестувати.

Будь-який вузол Tailscale може запитувати IP-адреси, що належать будь-якому іншому вузлу Tailscale. Площина керування Tailscale фіксує та надає вам цю інформацію про кожен вузол у вашій мережі: ім’я хоста ОС, IP-адреси та номери портів, операційну систему, дату створення, мітку часу останнього відвідування та параметри проходження NAT. За бажанням можна також увімкнути збір даних служби, який надсилає дані про відкриті порти на кожному вузлі до рівня керування.

Tailscale любить підкреслювати свою ключову функцію закінчення терміну дії та ротації . За замовчуванням термін дії всіх ключів закінчується через 180 днів, і трафік до та з вузла, термін дії якого закінчився, буде перервано, доки вони не будуть оновлені (загалом, ви повторно входите у свій провайдер і виконуєте операцію поновлення). На жаль, єдина згадка, яку я бачу про попередження про перешкоду закінчення терміну дії, є в клієнті Windows, і навіть там вам потрібно відредагувати розділ реєстру , щоб отримати попередження більше, ніж за замовчуванням за 24 години. Коротше кажучи, здається, ймовірно, щоб перервати зв’язок, коли це найважливіше. Ви можете вимкнути термін дії ключа для кожного вузла у веб-інтерфейсі консолі адміністратора, і я переважно це роблю, оскільки не хочу втрачати з’єднання в невідповідний час.

Tailscale: підключення та проходження NAT

Говорячи про надійність, головним моментом є можливість досягти площини керування Tailscale. Хоча за обмежених обставин можливо досягти вузлів без площини керування Tailscale, це «досить крихка установка» і, зокрема, не переживе перезавантаження клієнта. Отже, якщо ви використовуєте Tailscale для зв’язку з іншими вузлами вашої локальної мережі, це не працюватиме, якщо ваш Інтернет не підключений і контрольна площина доступна.

Якщо припустити, що ваш Інтернет і інфраструктура Tailscale працюють, хвилюватися мало. Ваш власний рівень комфорту з хмарними провайдерами та ваш Інтернет мають орієнтуватися тут.

Tailscale написав фантастичну статтю про проходження NAT , і вони, як можна було передбачити, дуже добре з цим справляються. Tailscale віддає перевагу UDP, але за потреби повертається до TCP. Сервери брокерів (DERP) втручаються як останній засіб, і клієнти Tailscale автоматично вибирають найкращих. Я не знаю нічого більш успішного з обходом NAT, ніж Tailscale. Це максимізує ситуації, в яких можна використовувати пряме з’єднання P2P без посередника.

Я виявив, що Tailscale дещо повільно помічає зміни в топографії мережі порівняно з Yggdrasil, і іноді потребує підбадьорення у вигляді перезапуску клієнтського процесу, щоб відновити зв’язок після зміни мережі. Однак цілком можливо (можливо, навіть ймовірно), що якби я почекав трохи довше, це все б вирішило.

Tailscale: Діліться з друзями

Раніше я торкався функції воронки. Функція спільного доступу дозволяє надати запрошення сторонній особі. За замовчуванням особа, яка приймає спільний доступ, може здійснювати лише вихідні з’єднання з мережею, до якої її запросили, і не може отримувати вхідні з’єднання з цієї мережі – це має сенс. Коли ви надаєте спільний доступ до вузла виходу, ви отримуєте прапорець, який також дозволяє надати спільний доступ до вузла виходу. Звичайно, особа, яка приймає спільний доступ, повинна встановити клієнт Tailnet. Поєднання послідовності й спільного використання робить Tailscale найкращим для тимчасового обміну.

Шкала: DNS

DNS Tailscale називається MagicDNS . Він працює як рівень поверх вашого стандартного DNS – переймаючи /etc/resolv.confна себе Linux – і забезпечує розпізнавання імен хостів сітки та деякі інші функції. Це досить хитра концепція.

Він також трохи нестабільний у Linux; дуельні програми хочуть написати /etc/resolv.conf. Я не можу сказати, що це повністю вина Tailscale; вони документують проблему та деякі обхідні шляхи .

Я хотів би мати можливість додавати власні записи до цієї служби; наприклад, щоб замінити загальнодоступну IP-адресу, щоб служба використовувала IP-адресу в сітці. На жаль, це поки що неможливо . Однак MagicDNS може запитувати існуючі сервери імен для певних доменів у розділеному налаштуванні DNS.

Tailscale: вихідний код, ціни та мобільність

Tailscale є майже повністю відкритим кодом, а клієнт дуже портативний. Клієнт має відкритий код (BSD 3-clause) на платформах з відкритим кодом і закритий код на платформах із закритим кодом. Сервери DERP є відкритими. Координаційний сервер із закритим вихідним кодом, хоча існує координаційний сервер із відкритим вихідним кодом під назвою Headscale (також BSD 3-clause), доступний за благословення та неофіційної підтримки Tailscale. Він підтримує більшість, але не всі функції координаційного сервера Tailscale.

Ціни Tailscale (які не застосовуються до використання Headscale) надають безкоштовний план для 1 користувача з до 20 пристроями. План Personal Pro розширює це до 100 пристроїв за 48 доларів на рік – непогана пропозиція за 4 долари на місяць. Також існує план «Спільнота на Github», а також плани, орієнтовані на бізнес. Подробиці див. на сторінці з цінами.

Як маленьке зауваження, я оцінив сценарій встановлення Tailscale. Він правильно додав відповідний ключ Tailscale таким чином, що його можна використовувати лише для автентифікації репо Tailscale, а не як загальносистемний автентифікатор. Це приємний штрих і добре говорить про їхніх розробників.

Висновки за хвостовою шкалою

Tailscale є лідером у обміні, має широкий набір функцій і чудову документацію. Подібно до інших рішень із централізованою площиною керування, комунікації пристроїв можуть перестати працювати, якщо площина керування недоступна, тому слід ретельно розглянути модель загрози площини керування.

Zerotier

Zerotier є близьким конкурентом Tailscale і багато в чому схожий на нього. Тож замість того, щоб дублювати тут всю інформацію про Tailscale, я в основному опишу, чим вона відрізняється від Tailscale.

Основна відмінність між ними полягає в тому, що Zerotier емулює мережу Ethernet через інтерфейс Linux tap, тоді як Tailscale емулює мережу TCP/IP через інтерфейс Linux tun.

Однак у Zerotier є ряд речей, які роблять його дещо недосконалим емулятором Ethernet. По-перше, у нього є проблема з посиленням трансляції ; машина, яка надсилає широкомовну передачу, надсилає її всім іншим вузлам, які мають її отримати (до встановленого максимуму). Я б не хотів, щоб багато програм транслювалося через повільне з’єднання. Хоча теоретично це може дозволити вам запускати Netware або DECNet через Zerotier, я не дуже впевнений, що сьогодні це дуже потрібно, і Zerotier явно орієнтований на IP, оскільки він розподіляє IP-адреси тощо. Zerotier забезпечує спеціальну підтримку емульованих ARP (IPv4) і NDP (IPv6). Хоча теоретично можна використовувати Zerotier як міст, це усуває принцип нульової довіри, а Tailscale підтримує маршрутизатори підмережі, які в будь-якому випадку надають майже той самий набір функцій.

Дещо незрозумілою функцією, але, можливо, корисною, є вбудована в Zerotier підтримка багатошляхової WAN для публічного інтерфейсу. Це фактично дає вам змогу зробити дещо базовий вид зв’язування каналів для WAN.

Zerotier: безпека та конфіденційність

Картина тут схожа на Tailscale, з тією різницею, що ви можете створити локальний обліковий запис Zerotier, а не покладатися на хмарну автентифікацію. Мені не вдалося знайти стільки подробиць про Zerotier, скільки про Tailscale — особливо я не зміг знайти нічого про те, наскільки «липкою» є IP-адреса. Однак на екрані конфігурації можна видалити вузол і призначити додаткові довільні IP-адреси в межах підмережі іншим вузлам, тому я думаю, що тут припущення полягає в тому, що якщо ваш обліковий запис Zerotier (або рівень керування Zerotier) скомпрометовано, зловмисник може видалити законний пристрій, додайте зловмисний і призначте попередню IP-адресу легального пристрою зловмисному. Я не знаю, як пом’якшити цей ризик, оскільки брандмауер певних IP-адрес неефективний, якщо зловмисник може просто заволодіти ними. Zerotier також не має нічого схожого на Tailnet Lock.

З цієї причини я не просувався набагато далі в своїй оцінці Zerotier.

Zerotier: підключення та проходження NAT

Як і Tailscale, Zerotier має обхід NAT із STUN. Однак схоже, що він більш обмежений , ніж Tailscale, і, зокрема, несумісний із подвійним NAT, який часто можна побачити сьогодні. Zerotier керує посередниками («кореневими серверами»), які можуть виконувати ретрансляцію, включно з ретрансляцією TCP. Таким чином, ви повинні мати можливість підключатися навіть із ворожих мереж, але у вас менше шансів створити з’єднання P2P, ніж за допомогою Tailscale.

Zerotier: ділитися з друзями

Мені не вдалося знайти жодних спеціальних функцій, пов’язаних із цим, у документації Zerotier. Тому це було б на тому ж рівні, що й Іґґдрасіль: можливо, навіть не надто складно, але без спеціальної допомоги.

Нульовий рівень: DNS

На відміну від Tailscale, Zerotier не підтримує автоматичне додавання записів DNS для ваших хостів. Таким чином, ваші параметри приблизно такі ж, як і в Yggdrasil, але з доданою опцією надсилання клієнту конфігурації, яка вказує на ваші власні DNS-сервери не нульового рівня.

Zerotier: вихідний код, ціни та портативність

Клієнт ZeroTier One доступний на Github під спеціальною «ліцензією на бізнес-джерело», яка не дозволяє використовувати його в певних налаштуваннях. Ця ліцензія не дозволить включити його в Debian. Їхня бібліотека, libzt, доступна за такою ж ліцензією. На сторінці з цінами згадується випуск спільноти для самостійного розміщення, але документація мізерна, і було важко зрозуміти, який у нього насправді набір функцій.

Безкоштовний план дозволяє мати 1 користувача з до 25 пристроями. Також доступні платні плани.

Нульові висновки

Чесно кажучи, я не бачу особливої причини використовувати Zerotier. Модель «віртуального Ethernet» здається дивним гібридом, який не приносить великої цінності. Мене хвилюють наслідки зламу облікового запису користувача чи рівня керування, і в ньому бракує багатьох функцій Tailscale (MagicDNS і обмін). Єдине, що він може запропонувати, — це багатошляхова глобальна мережа, але це досить езотерично — і також вирішується на інших рівнях — і не здається мені таким переконливим. Додайте до цього дивну ліцензію, і я не бачу особливої причини турбуватися про це.

Netmaker

Netmaker — це один із проектів, які сьогодні викликають шум. Netmaker є єдиним тут, що є обгорткою навколо внутрішньоядерного Wireguard, який може покращити продуктивність під час спілкування з одноранговими користувачами на 1 Гбіт/с або швидшому з’єднанні. Крім того, на відміну від інших інструментів, він має функцію вхідного шлюзу , яка дозволяє людям, які не мають клієнта Netmaker, але мають Wireguard, брати участь у VPN. Мені здається, я також десь бачив посилання на вузли як маршрутизатори, як у випадку з Yggdrasil, але я не можу цього розкопати зараз.

Проект знаходиться на ранній стадії; ви можете підписатися на «майбутнє закрите бета-тестування» з хостом SaaS, але насправді вам зазвичай вказують на самостійне розміщення за допомогою коду в репозиторії github . Є видання для спільноти та підприємства, але незрозуміло, як насправді вибрати. Сервер має купу компонентів : бінарний файл, CoreDNS, базу даних і веб-сервер. Він також вимагає підвищених привілеїв на хості на додаток до механізму контейнерів. Порівняйте це з єдиним двійковим файлом, який надають деякі інші.

Схоже, що релізи трапляються часто , але інколи виникають проблеми та потребують більш трудомістких процесів оновлення, ніж у більшості інших.

Я не хочу витрачати багато часу на керування сіткою. Отже, через великі потреби сервера, оновлення є трудомістким, воно займає iptables і таке інше на сервері, я не продовжував більш глибоку оцінку Netmaker. Він багатообіцяючий, але для мене він поки що не в тому стані, який би відповідав моїм потребам.

Туманність

Nebula — це цікавий сітчастий проект, який виник у Slack, здається, що все ще спонсорується Slack, але також розробляється Defined Networking (хоча їхній продукт зараз виглядає раннім). На відміну від інших інструментів у цьому розділі, Nebula взагалі не має веб-інтерфейсу. Схоже, що визначена мережа надасть щось на зразок послуги SaaS, але наразі вам доведеться самостійно запустити брокера («маяк»); можливо, на VPS 5 $/міс.

Через погані властивості проходження брандмауера я не проводив повної оцінки Nebula, але він все одно має дуже цікавий дизайн.

Nebula: безпека та конфіденційність

Оскільки Nebula не має традиційної площини керування, основою довіри в Nebula є CA (центр сертифікації). У документації наведено такий приклад налаштування:

./nebula-cert sign -name "lighthouse1" -ip "192.168.100.1/24"
./nebula-cert sign -name "laptop" -ip "192.168.100.2/24" -groups "laptop,home,ssh"
./nebula-cert sign -name "server1" -ip "192.168.100.9/24" -groups "servers"
./nebula-cert sign -name "host3" -ip "192.168.100.10/24"

Отже, сертифікат містить вашу IP-адресу, ім’я хоста та розміщення групи. Кожен хост у сітці отримує ваш сертифікат ЦС, а також сертифікат і ключ для кожного хоста, створені на кожному з цих кроків.

Це призводить до дійсно гарної моделі безпеки. Ваш центр сертифікації є захисником того, що довіряється вашій сітці. Ви навіть можете зробити його повітряним зазором або щось подібне, щоб було надзвичайно важко порушити периметр.

Nebula містить вбудований брандмауер. Оскільки здатність захищати від небажаних вузлів є дуже сильною, я б сказав, що це може бути єдина сітчаста мережа VPN, яку ви можете використовувати, не турбуючись про додатковий брандмауер на хості.

Ви можете визначити статичні відображення з IP-адреси мережі Nebula на IP-адресу Clearnet. Я не знайшов інформації про це, але теоретично, якщо обхід NAT не потрібен, ці статичні відображення можуть дозволити вузлам Nebula досягати один одного, навіть якщо Інтернет не працює. Однак я не знаю, чи це справді так.

Nebula: підключення та проходження NAT

Це слабке місце Nebula. Nebula надсилає весь трафік через один порт UDP ; не передбачено використання TCP. Це проблема в деяких готельних та інших громадських мережах, які відкривають лише вихідні порти TCP 80 і 443.

Я не міг знайти багато деталей про те, на що здатний NAT-обхід Nebula, але, згідно з певною проблемою Github , це було болючим місцем протягом багатьох років і не настільки спроможне, як Tailscale.

Ви можете призначити вузли в Nebula як посередників ( ретрансляторів ). Концепція така сама, як і в Іґґдрасілі, але менш універсальна. Ви повинні вручну вказати, яке реле використовувати. Мені незрозуміло, що відбувається, якщо різні вузли призначають різні реле. Майте на увазі, що це завжди відбувається через порт UDP.

Nebula: Діліться з друзями

Особливої підтримки тут немає.

Туманність: DNS

Nebula має експериментальну підтримку DNS . На відміну від Tailscale, який має внутрішній DNS-сервер на кожному вузлі, Nebula запускає DNS-сервер лише на маяку. Це означає, що він не може пересилати запити до DNS-сервера, який знаходиться вище за поточне розташування вашого ноутбука. Насправді DNS-сервер Nebula взагалі не пересилає. Він також не розпізнає власне ім’я.

У документації Nebula йдеться про використання кількох маяків, які ви можете зробити для резервування DNS або продуктивності, але мені незрозуміло, чи це змусить кожен маяк сформувати повну картину мережі.

Nebula: вихідний код, ціни та мобільність

Nebula є повністю відкритим кодом (MIT). Він складається з одного двійкового файлу Go та конфігурації. Він досить портативний.

Висновки Небула

Мене приваблює унікальна модель безпеки Nebula. Я б, мабуть, більш серйозно розглянув це, якби не відсутність підтримки TCP і погані загальні властивості проходження NAT. Його спадщина підключення до центру обробки даних справді проявляється.

Розгорніть свій власний і гібридний

Ось велика кількість ідей:

Пробіг Іггдрасіля над Хвостою лускою

Однією з можливостей було б використовувати Tailscale для кращого обходу NAT, а потім дозволити Yggdrasil працювати над ним. (Вам знадобиться брандмауер, щоб запобігти спробам Tailscale запустити Yggdrasil одночасно!) Це створює закриту мережу з усіма перевагами Yggdrasil, але отримує проходження NAT від Tailscale.

Недоліками можуть бути накладні витрати на подвійне шифрування та подвійну інкапсуляцію. Хороший колега Yggdrasil все одно може виявитися швидшим за це.

Загальнодоступний постачальник VPN для обходу NAT

Загальнодоступний провайдер VPN, такий як Mullvad, часто пропонує переадресацію вхідних портів і вузли в багатьох містах. Це може бути привабливим способом вирішення купи проблем проходження NAT: просто скористайтеся однією з цих служб, щоб отримати вхідний порт, і запустіть над ним будь-який спосіб.

Інший

Поєднання з локальними брандмауерами

Для більшості цих інструментів я рекомендую використовувати локальний брандмауер у поєднанні з ними. Я використовував Firehol і вважаю, що це дуже добре. Це означає, що вам не потрібно довіряти сітці, контрольній площині чи будь-якому іншому. Заковика в тому, що вам потрібен мережевий VPN, щоб забезпечити міцний зв’язок між IP-адресою та вузлом. Більшість, але не всі, так.

Продуктивність

Я перевірив деякі з них на продуктивність за допомогою iperf3 у локальній мережі 2,5 Гбіт/с. Ось результати. Усі швидкості вказані в Мбіт/с.

Ви бачите, що Wireguard був значно швидшим за інші варіанти. Тейллуска та Іґґдрасіль були приблизно схожими, а Тінк був жахливим.

Останні думки

Для моїх власних цілей я підозрюю, що так чи інакше залишуся з Іґдрасілем. Можливо, я просто візьму на себе невелике зниження продуктивності, яке має на увазі використання вузла ретрансляції. Або, можливо, я піду розумніше і використаю вхідний порт VPN, або перейду за Tailscale.

Іншим варіантом, який видався найцікавішим, була хвостова луска. Однак, живучи в регіоні, де Інтернет зникає частіше, ніж хотілося б, я хотів би просто мати можливість надсилати якомога більше трафіку через сітку, вірячи, що якщо локальна мережа працює, сітка працює.

У мене є одна річ, яка дійсно виграє від продуктивності, що перевищує Yggdrasil або Tailscale: NFS. Це між двома машинами, які ніколи не залишають мою локальну мережу, тому я, ймовірно, просто встановлю між ними пряме з’єднання Wireguard. Набагато простіше, ніж спробувати створити Kerberos!

Нарешті, я написав це з наміром бути корисним. Я мав справу з великою складністю та недостатньою документацією, тож, можливо, я десь помилився. Будь ласка, дайте мені знати, якщо ви знайдете якісь помилки.

Ця публікація в блозі є копією сторінки на моєму веб-сайті . Ця сторінка може періодично оновлюватися.

Просмотры: