Два переходи VPN поспіль: хто насправді бачить ваш трафік?

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

Почніть із клієнта і назвіть обидва кінці

Почніть там, де починає користувач, у профілі підключення. У ньому є одна віддалена адреса, один метод автентифікації і, якщо проєкт це підтримує, список маршрутів. Позначте цей зовнішній тунель від клієнта до шлюзу A і дайте йому прикладні адреси: адреса тунелю клієнта 10.77.0.2, адреса A 10.77.0.1 і публічна кінцева точка A 198.51.100.10, узяті з документаційного діапазону TEST-NET-2, щоб ніщо в прикладі не могло зіткнутися з реальним хостом.

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

Послідовно: A розшифровує, потім знову шифрує

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

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

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

Вкладено: A знімає лише зовнішній шар

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

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

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

Малюйте спостерігачів, а не лише тунелі

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

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

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

Пройдіть шляхи відмови, перш ніж вибирати

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

ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1

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

openssl s_client -connect intranet.example.com:443 -brief < /dev/null

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

Вибирайте послідовний варіант, коли A має застосувати політику до внутрішнього пакета або коли клієнт не може запускати два вкладені тунелі. Вибирайте вкладеність, коли внутрішнє корисне навантаження має залишатися нечитабельним у A. Запишіть вибір разом із його спостерігачами та його числами MTU, і наступній людині не доведеться перемальовувати всю картину, щоб відповісти на одне питання.