Проброшений порт VPN: що бачать відвідувачі та провайдер

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

Три об’єкти, три різні питання

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

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

Що відвідувач може зв’язати між кінцевими точками

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

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

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

Що має знати провайдер пробросу

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

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

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

Як довго триває зіставлення, змінює відкритість

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

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

Публікуйте усвідомлено, а потім закрийте обидва двері

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

openssl s_client -connect pub.example.net:443 -brief < /dev/null
curl -sSI https://pub.example.net/

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

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