Оверлей N2N — не проксі: намалюйте обидва з’єднання

Firefox указує на 127.0.0.1:8000, край N2N працює, вузол відповідає на ping за своєю адресою в оверлеї, а браузер усе ще повідомляє, що проксі відмовив у з’єднанні. У цьому ланцюжку немає суперечності. Оверлей дає хосту доступну адресу в приватній мережі; він не створює процес, який говорить протоколом проксі. Браузер не просить маршрут до вузла. Він просить локальний слухач.

Тут плутають два з’єднання, і якщо намалювати їх окремо, більша частина плутанини розвіється за хвилину.

Два з’єднання, а не одне

Перше з’єднання йде від браузера до того, що слухає на петльовому порту. Це локальний сокет, і якщо ним ніхто не володіє, з’єднання відхиляється ще до того, як хоч один пакет досягне N2N. Друге йде від процесу проксі до джерела, яке він отримує. Цей шлях вибирає таблиця маршрутизації хоста проксі, і це може бути звичайний аплінк, інший тунель або маршрут політики, що не має нічого спільного з оверлеєм.

Ping до вузла доводить, що оверлей уміє доставляти пакети між адресами країв. Він нічого не доводить про слухача на порту 8000 і про те, чи може цей хост дістатися до джерела. Окремі збої, окремі виправлення.

Де має жити слухач

Проксі, прив’язаний до 127.0.0.1, навмисно локальний: він приймає з’єднання лише з машини, на якій працює. Це правильне значення за замовчуванням для особистого проксі й неправильна форма для спільного використання через оверлей. Обслуговування вузлів оверлея вимагає або адреси прив’язки на інтерфейсі оверлея, або компонента пересилання, який завершує петльове з’єднання й передає його далі. У будь-якому разі явна політика має вирішувати, яким джерелам оверлея дозволено користуватися сервісом, бо відкритий проксі в спільній мережі — це запрошення.

Перевіряйте фактичну прив’язку списком сокетів, а не файлом конфігурації. Демон, запущений до підняття оверлея, може досі бути прив’язаним до адреси, якої вже немає.

localhost — не вузол

У полі проксі браузера localhost указує на машину самого браузера. Це не край, не супервузол і не хост на далекому кінці тунелю. Якщо проксі працює на іншому вузлі, впишіть у поле доступну адресу оверлея й порт цього вузла, потім переконайтеся, що слухач приймає з’єднання з адреси вашого краю.

Супервузли допомагають краям знаходити одне одного; вони не є службою проксі. Ставлення до адреси супервузла як до кінцевої точки проксі дає ту саму відмову з додатковим кроком плутанини.

Маршрут не може виконати рукостискання

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

Якщо мета — просто дістатися до служби на вузлі, приберіть налаштування проксі й використовуйте адресу служби в оверлеї напряму.

Перевіряйте межі по порядку

Переконайтеся, що адреса оверлея відповідає, потім переконайтеся, що на налаштованому порту є слухач, і запишіть його адресу прив’язки. Зробіть один контрольований запит і прочитайте журнал проксі, щоб знати, де збій: у слухачі чи в подальшому отриманні. Нарешті, перевірте маршрут хоста проксі й політику DNS для джерела.

Проєкт N2N документує краї й супервузли як компоненти оверлея. Він не перетворює край на прикладний проксі, і жодна конфігурація маршрутизації не додає обробник протоколу, який ніхто не запускав.