Служба Onion против службы VPN: разные модели доступа

Люди описывают службу Onion и службу, доступную только через VPN, как два варианта одной идеи: скрой порт и поделись секретным адресом. Они различаются тем, к чему привязан адрес, кто может до него добраться и что должно произойти до прихода запроса. Одна — место встречи внутри Tor, другая — маршрут внутри частной сети. Если считать их взаимозаменяемыми, получаются проекты, которые не являются ни частными, ни поддерживаемыми.

Миф: оба решения — просто скрытая дверь

Общее свойство реально, но тонко: ни одно решение не ставит административный интерфейс на напрямую доступный публичный порт. Всё дальнейшее расходится. Адрес Onion выводится из собственного ключа службы, поэтому имя привязано к личности; адрес VPN — просто адрес в сети, куда вас допустили. Одно прячет службу внутри наложенной сети, другое впускает вас в частную топологию. Именно отношение ко второму как к синониму первого и начинает путаницу.

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

На что на самом деле указывает адрес Onion

Адрес Onion версии v3 кодирует открытый ключ службы, поэтому никто не может выбрать адрес для службы, которой не управляет. Клиент подключается через Tor к месту встречи, а служба достигает той же точки со своей стороны; ни один обычный выходной узел не несёт это соединение к службе. Имя — это личность, а не запись DNS.

dig +short example.onion
curl --socks5-hostname 127.0.0.1:9050 http://example.onion/
systemctl status tor

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

Остановитесь, если единственная причина проекта onion — избежать настройки аутентификации. Наложенная сеть этого не даёт, и вы всё равно построите её позже.

Что на самом деле даёт маршрут VPN

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

ip route get 10.20.30.40
wg show
curl -sv https://files.internal.example/ -o /dev/null

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

Остановитесь, если аудитория неизвестна или постоянно меняется. Зачисление посторонних в частную сеть, чтобы показать им одну страницу, — большое обязательство по сравнению с публикацией службы.

Выбор между ними и то, что остаётся прежним

Выбирайте модель onion, когда аудитория техническая, у службы вообще не должно быть публичного адреса и вы можете принять требования клиента Tor. Выбирайте модель VPN, когда аудитория — определённая группа, устройствами которой вы управляете и чей доступ хотите фиксировать на сетевом уровне. Ни один выбор не снимает потребность в аутентификации приложения, исправлениях или пути восстановления. Ни один не является автоматически более приватным в том смысле, который важен вашим пользователям.

В обоих решениях запишите, кто может добраться до службы, как они идентифицируются и что происходит при утрате учётных данных. Ответ для службы onion включает её ключи клиентской авторизации и сам адрес; ответ для VPN включает учётную запись, устройство и политику шлюза. Это разные перечни, и только один из них будет очевиден следующему администратору.

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