HTTP-прокси, SSH-туннель или VPN: выберите правильный уровень

Спросите трёх инженеров, как добраться до внутреннего сервиса, и получите три проекта: веб-прокси, SSH-туннель или полноценный VPN. Все три способны сделать удалённый сервис доступным, и все три способны заставить трафик выглядеть приходящим из другого места. Различия проявляются позже, когда используемый протокол не тот, который предполагает выбранный инструмент. Схема, проходящая быструю проверку в браузере, регулярно отказывает в приложении, ради которого её затевали.

Решайте по двум фактам: какие протоколы должны пройти и кто может разрешить участвующие имена. Всё остальное — предпочтение.

Прокси переносит только то, что понимает

Веб-прокси разбирает протокол, для которого создан. Клиент передаёт ему запрос, а он передаёт запрос дальше, поэтому приложение без настройки прокси вообще не участвует. Для HTTPS клиенту нужен непрозрачный канал, который прокси предоставляет через CONNECT, а не чтением запроса.

Динамическое перенаправление SSH открывает локальный порт, говорящий по SOCKS, и этот порт ретранслирует поток TCP в любое место, которое назовёт клиент. Протоколы поверх TCP обычно через него работают. UDP — нет, если инструмент не добавил поддержку явно. Локальное перенаправление ещё уже: один локальный порт отображён на один фиксированный хост и порт, что обслуживает один известный сервис и ничего больше.

ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastion

VPN перемещает пакеты. Всё, что клиент направляет в туннель, проходит через него, включая UDP и ICMP, поэтому он подходит для сетевого требования, а не для одного соединения.

Кто-то должен разрешить имя

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

curl ясно показывает разделение: один флаг передаёт имя хоста прокси, другой сначала разрешает его локально. При локальном разрешении внутреннее имя отказывает ещё до того, как туннель будет затронут, и ошибка обвиняет прокси в том, что на самом деле было решением DNS.

VPN идёт третьим путём, устанавливая частный резолвер и домен поиска рядом с маршрутами. Это удобно и создаёт знакомую иллюзию: маршрут, который есть, с резолвером, который не отвечает, выглядит точно как мёртвый туннель, хотя пакеты достигают другой стороны.

Когда сеть разрешает только один выход

Многие корпоративные сети разрешают исходящие соединения только через прокси с аутентификацией. OpenVPN и SSH можно заставить работать там: первый — туннелируя свой транспорт через прокси, второй — через команду прокси, запускающую небольшой помощник CONNECT.

Туннели поверх TCP переживают это ограничение, а VPN на UDP — нет, что объясняет массу конфигураций, которые работают дома и отказывают в офисе. Вторую цену легко упустить: TCP-туннель внутри проксированного TCP-соединения теперь имеет два слоя с повторной передачей, и при потерях эта пара встаёт так, как ни один слой по отдельности не делает.

Выстраивание посредников — другой вопрос, нежели выбор уровня. Добавление второго прокси или Tor меняет то, кто что наблюдает, а позиция в цепочке решает, какой участок видит шифротекст.

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

Поддельный адрес — не один из вариантов

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

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

Решайте по протоколам и именам

Выбирайте прокси, когда одному веб-клиенту нужен один веб-сервис и у него есть настройки прокси. Выбирайте SSH-туннель, когда достаточно нескольких известных TCP-сервисов и доступ по SSH уже есть. Выбирайте VPN, когда несколько приложений, не-TCP трафик, частный DNS или многоразовый путь входят в требование.

Затем проверяйте настоящим клиентом и настоящим именем. Загрузка страницы через прокси ничего не говорит вам об UDP, а работа одного инструмента через SOCKS ничего не говорит о системном резолвере. Прочитайте, какой локальный адрес привязал процесс и какой резолвер ответил. В этом разница между путём, который работает, и тем, который случайно сработал однажды.