Подключение только по IPv6, служба IPv4: пусть SOCKS-прокси станет мостом

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

Два сокета, два семейства адресов

Запрос SOCKS5 называет назначение в одной из трёх форм: буквальный адрес v4, буквальный адрес v6 или имя, которое прокси должен разрешить. Запрос описывает, куда прокси следует подключиться, а не как выглядит соединение клиента с прокси.

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

Контролируемый пример с SSH

Возьмите SSH-хост, который вам разрешено использовать, отвечающий по IPv6 и способный сам достичь службы HTTPS, существующей только на v4. Динамическое перенаправление OpenSSH помещает локальный SOCKS-слушатель на вашу машину, пока сеанс входа идёт по v6.

ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]

Хост и учётная запись выше — примеры, а привязка к loopback удерживает слушатель на этом компьютере. Не заменяйте её привязкой к подстановочному адресу, чтобы офис мог совместно использовать прокси без аутентификации. ExitOnForwardFailure=yes существует для того, чтобы неудачное перенаправление завершало сеанс, а не оставляло тихо работающую команду в фоне.

Когда сеанс запущен, запрос выглядит так:

curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/

Соединение через loopback не является интернет-путём IPv4. С вашей машины уходит сеанс входа по v6, и именно удалённая сторона открывает сокет назначения. Форма socks5h также передаёт разрешение имён той стороне, что важно, когда у клиента нет собственного пути к резолверу IPv4.

Что на самом деле видит назначение

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

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

Это не DNS64 и не NAT64

DNS64 отвечает синтезированными записями, заменяющими назначения v4, а NAT64 переписывает пакеты по настроенному пути. Ни то, ни другое не описывает происходящее здесь, где один транспортный разговор заканчивается и начинается другой и никакой синтезированный адрес не объясняет результат. Поэтому успешный запрос ничего не говорит о том, какие службы трансляции эксплуатирует ваш провайдер, а прокси может выполнять обычный NAT на своём собственном выходе.

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

Знайте рамки, прежде чем обещать их

Динамическое перенаправление OpenSSH несёт TCP-соединения, а не произвольный IP-трафик, поэтому UDP, ICMP и любой протокол, игнорирующий прокси, нуждаются в другом поддерживаемом решении. Сохраняйте проверку ключа хоста SSH, ограничения перенаправления сервера и проверку сертификата HTTPS, потому что прокси — это дополнительный доверенный участник, а не повод ослаблять проверку личности. Если цель — пронести внешний транспорт VPN через прокси, проверьте, что оба конца поддерживают этот транспорт, вместо того чтобы предполагать, будто любой SOCKS-слушатель может его переслать.

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