Проброшенный порт VPN: что видят посетители и провайдер

Проброс порта даёт посторонним маршрут к сервису через публичный адрес провайдера. Это единственное изменение одновременно влияет и на открытость, и на узнаваемость, и ни то, ни другое не публикует имя того, кто управляет сервисом. Разделение этих двух вещей помогает избежать противоположных ошибок: считать 'проброс' анонимностью и считать его идентификацией. Три вопроса чётко их разделяют, и ответы приходят из разных доказательств.

Три объекта, три разных вопроса

Держите публичный адрес отдельно от приложения, которое отвечает за ним, а оба — отдельно от человека или организации, которые этим управляют. У каждого своя аудитория и свои доказательства. Их смешение даёт выводы, которые звучат аккуратно и являются неверными.

Пройдите по ним в этом порядке. Первый — вопрос доступности, второй — вопрос идентичности приложения, а третий — вопрос атрибуции, который первые два освещают лишь частично. Когда кто-то спрашивает, приватен ли проброс портов, спросите, какой из трёх имеется в виду. Ответы действительно различаются, и страница политики обычно рассматривает только один из них.

Что посетитель может связать между конечными точками

Посетитель подключается к конечной точке и видит то, что приложение законно показывает: 'имя хоста', имя сертификата, страницу входа, опубликованное содержимое. Эти детали идентифицируют сервис даже тогда, когда его обычный адрес доступа скрыт за туннелем. Две конечные точки, показывающие один и тот же названный сайт, дают наблюдателям основание связать их. Ничто в этом поведении не является утечкой, поскольку приложение создано, чтобы его видели.

Совпадение сертификатов, перенаправлений и содержимого страниц у двух конечных точек — сильный признак того, что они принадлежат одному сервису. Это остаётся утверждением о сервисе, а не о человеке, пока какая-нибудь другая запись не свяжет эти две точки.

Рекомендации IETF по конфиденциальности описывают, как постоянные идентификаторы позволяют соотносить взаимодействия во времени. Соотнесение — не атрибуция, поскольку одним сервисом могут управлять несколько человек, а адрес может переходить между не связанными подписчиками. Именно это различие не позволяет выводу о соотнесении превратиться в обвинение.

Что должен знать провайдер проброса

Чтобы доставить входящее соединение, система провайдера должна удерживать активную связь между публичной точкой входа и внутренним назначением. Этот эксплуатационный факт отличается от того, что видит посетитель, и снова отличается от того, что провайдер решает сохранить. Держите два вопроса раздельно, когда читаете страницу политики, потому что один неизбежен, а другой — решение. Утверждение, что история просмотров не хранится, ничего не говорит об истории сопоставлений.

Сохраняются ли исторические сопоставления, привязки к аккаунту или записи о соединениях — это вопрос к фактической политике и реализации провайдера. Проброс не доказывает, что каждая категория протоколируется. Спросите конкретно, какие поля остаются после отзыва сопоставления и насколько долго.

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

То, как долго длится сопоставление, меняет открытость

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

Срок жизни меняет то, какое соотнесение возможно. Стабильная конечная точка приглашает к долговременному отслеживанию одного сервиса, а вращающаяся делает каждое наблюдение сложнее связать с предыдущим. Ни одно из свойств не является гарантией насчёт записей провайдера, и ни одно не заменяет решения о том, что публикует сам сервис.

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

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

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

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

Вывод сервиса из эксплуатации означает два закрытия, а не одно: отзовите сопоставление через его владельца, а затем разберитесь со слушателем и правом как с отдельными пунктами. Конечная точка в закладках, которая перестаёт отвечать, не отзывает учётные данные и не возвращает уже доставленную информацию.