Domain fronting — це не VPN: два імені, один запит

Ці дві техніки потрапляють в одну теку, бо обидві передбачають посередника і обидві звучать як приховування. Але працюють вони з різними об'єктами. Domain fronting — це про те, яке ім'я на якому рівні одного HTTPS-запиту з'являється. VPN — це про те, які пакети йдуть певним шляхом до піра. Називати фронтинг різновидом VPN означає приходити до проєктів, які не можуть працювати, і до оглядів, які ставлять неправильне питання.

Два імені, два рівні

TLS-з'єднання може нести ім'я сервера у своєму рукостисканні. Коли з'єднання встановлено, HTTP-запит указує потрібну йому повноважну сторону, зазвичай у заголовку Host. Це два поля, які читаються в два різні моменти двома різними частинами програмного забезпечення.

Domain fronting використовує різницю між першими двома, так що сервіс фронтингу приймає з'єднання і потім спрямовує запит в інше місце. Це працює лише там, де сервіс готовий його спрямувати, а це питання політики провайдера, а не протокольного трюку.

Фронтинг залежить від провайдера, а не від техніки

Як обмежений приклад, поширені запитання щодо Front Door у документації Azure описують захист від domain fronting. Там описано дозволену невідповідність для доменів у межах однієї підписки та налаштованих маршрутів, а також відповідь 421 Misdirected Request, коли захист від невідповідності блокує запит.

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

Це також не інструкція з обходу обмежень іншої мережі. Читати правила маршрутизації провайдера, щоб зрозуміти, що він дозволяє, — це архітектурна робота; ставитися до цих правил як до рецепту обходу — інша діяльність з іншими наслідками. Тримайте ці дві діяльності окремо в документі, який ви пишете. Саме друга призводить до того, що проєкт відхиляють на огляді.

Що насправді вибирає VPN

У мережевому VPN маршрутизація та політика платформи вибирають внутрішній трафік для тунелю до піра. Залежно від схеми це може охоплювати кілька застосунків або визначену підмножину, і може нести протоколи, які взагалі не мають HTTP-запиту.

Фронтинг нічого з цього не робить. Організація одного HTTPS-запиту через сервіс фронтингу не встановлює маршрут у приватну мережу, не несе довільні UDP-застосунки і не змушує кожну програму на пристрої використовувати сервіс. Якщо вам потрібне таке покриття, вам потрібен проксі або тунель, а не трюк з іменем.

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

Видимість не бінарна

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

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

Намалюйте три квадрати

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

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