Кому ви довіряєте, коли самі запускаєте VPN-сервер

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

Крок 1: складіть перелік сторін

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

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

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

Крок 2: запишіть, що ви отримали

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

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

Крок 3: прийміть список обслуговування

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

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

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

Крок 4: відкиньте припущення про анонімність

Запуск сервера не робить ваш браузер анонімним. Сайти досі отримують відомості про обліковий запис і файли cookie, а HTTPS захищає дані застосунку на своєму власному шляху незалежно від тунелю.

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

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

Крок 5: виберіть його з названої причини

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

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

Крок 6: сплануйте вихід

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

Модель спільної відповідальності AWS — корисний шаблон і поза AWS, бо вона вимагає того самого питання: який рівень ваш, а який належить комусь іншому. Дайте відповідь для кожної сторони з кроку 1, і модель довіри перестане бути гаслом.