Чи зашифровано HTTP поверх ZeroTier? Перевірте, де закінчується оверлей

Пройдіть ці перевірки по черзі й зупиніться на першій невдалій, бо кожна відповідь змінює сенс наступного кроку. Справжнє питання вузьке: чи ходить звичайний HTTP у мережі ZeroTier інтернетом у відкритому вигляді? Між двома пірами ZeroTier зазвичай ні, оскільки оверлей шифрує цей перехід. Але це твердження про дві кінцеві точки, а не про кожен сегмент, який проходить запит. Маршрутизатор, міст або зворотний проксі зсуває кінцеву точку, і з іншого його боку відкритий текст починається знову.

Перевірка 1: знайдіть адресу, до якої звертається браузер

Порівняйте URL з тим, що машина справді має. ip -brief addr show показує інтерфейс zt і адресу оверлею, призначену контролером мережі; якщо URL використовує цю адресу, сокет браузера заходить в оверлей.

Коли ім'я натомість розв'язується в адресу LAN, оверлей може бути взагалі не задіяний, хоч би що підказував індикатор стану клієнта. ip route get 10.147.20.5 друкує інтерфейс і адресу джерела, які вибрало б ядро, тож інтерфейс zt там означає, що пакет потрапляє в оверлей, а ім'я вашої фізичної мережевої карти означає, що ні. Імена додають ще один шар: запис, що вказує на адресу оверлею, поводиться інакше, ніж той, що вказує на адресу LAN, а суфікс пошуку або запис у файлі hosts може тихо вирішити, який ви отримаєте.

Перевірка 2: переконайтеся, що обидва кінці — піри, а не ретранслятор, що розшифровує

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

Відповідь змінює учасник, який насправді не є кінцевою точкою. Коли протилежний бік — учасник ZeroTier, що маршрутизує або мостить у фізичну LAN, оверлей закінчується на цьому учаснику, а наступний перехід — звичайний Ethernet.

Перевірка 3: подивіться, де запит стає читабельним

На хості, який, на вашу думку, віддає сторінку, перехопіть інтерфейс оверлею під час перезавантаження: sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'. Читабельний рядок запиту в цьому виводі доводить, що трафік прийшов на цей хост розшифрованим, і це та межа, яку ви шукаєте.

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

Перехоплення loopback також важливе, коли попереду стоїть зворотний проксі, оскільки проксі, що приймає HTTPS і пересилає HTTP, переносить межу на власний бекенд.

Перевірка 4: врахуйте кожен перехід за маршрутизатором або мостом

Учасник, налаштований маршрутизувати між оверлеєм і LAN, — звичайна схема й місце, де більшість цих припущень ламається. Оверлей захищає ділянку від браузера до маршрутизатора і нічого після неї. Міст розповідає ту саму історію іншим механізмом: оверлей і фізичний сегмент стають одним широкомовним доменом, тож запит із ноутбука, під'єднаного через міст, іде звичайним Ethernet, навіть якщо цей ноутбук перебуває в мережі ZeroTier.

Простежте це, а не припускайте. traceroute від клієнта до адреси служби разом із таблицею маршрутизації на шлюзовому учаснику показує, чи останній перехід — zt чи eth.

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

Перевірка 5: вирішіть, що застосунку ще треба зробити

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

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

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

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