Оверлей N2N — не прокси: нарисуйте оба соединения

Firefox указывает на 127.0.0.1:8000, край N2N работает, узел отвечает на ping по своему адресу в оверлее, а браузер всё ещё сообщает, что прокси отказал в соединении. В этой цепочке нет противоречия. Оверлей даёт хосту доступный адрес в частной сети; он не создаёт процесс, который говорит по протоколу прокси. Браузер не просит маршрут к узлу. Он просит локальный слушатель.

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

Два соединения, а не одно

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

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

Где должен жить слушатель

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

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

localhost — не узел

В поле прокси браузера localhost указывает на машину самого браузера. Это не край, не суперузел и не хост на дальнем конце туннеля. Если прокси работает на другом узле, впишите в поле доступный адрес оверлея и порт этого узла, затем убедитесь, что слушатель принимает соединения с адреса вашего края.

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

Маршрут не может выполнить рукопожатие

Даже при правильном адресе маршрутизация — это не проксирование. Соединение HTTP-прокси начинается с запроса CONNECT или строки запроса в абсолютной форме, а SOCKS-прокси начинается с согласования версии и метода. Маршрутизатор или оверлей пересылает байты; он не разбирает эти сообщения и не открывает следующее соединение за вас. Именно поэтому маршрут, работающий для ping и SSH, может не сработать для прокси в браузере: браузеру нужен сотрудничающий процесс, а не просто доступность.

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

Проверяйте границы по порядку

Убедитесь, что адрес оверлея отвечает, затем убедитесь, что на настроенном порту есть слушатель, и запишите его адрес привязки. Сделайте один контролируемый запрос и прочитайте журнал прокси, чтобы понять, где сбой: у слушателя или при дальнейшем получении. Наконец, проверьте маршрут хоста прокси и политику DNS для источника.

Проект N2N документирует края и суперузлы как компоненты оверлея. Он не превращает край в прикладной прокси, и никакая конфигурация маршрутизации не добавляет обработчик протокола, который никто не запускал.