Шифрован ли е 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 е свързана" не е оценка на нищо от това. Честната версия назовава двата крайни пункта, пътя между тях и първия преход, който не е покрит.

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