Аверлей N2N — не проксі: намалюйце абодва злучэнні
Аверлей можа дасягнуць партнёра, а браўзер усё яшчэ атрымлівае адмову. Гэта адсутны слухач або няправільная прывязка, а не збой маршрутызацыі ў N2N.
Firefox паказвае на 127.0.0.1:8000, край N2N працуе, партнёр адказвае на ping па сваім адрасе аверлея, а браўзер усё яшчэ паведамляе, што проксі адмовіў у злучэнні. Нічога ў гэтым ланцугу не супярэчыць адно аднаму. Аверлей дае хасту дасягальны адрас у прыватнай сетцы; ён не стварае працэс, які размаўляе на пратаколе проксі. Браўзер не просіць маршрут да партнёра. Ён просіць лакальны слухач.
Тут блытаюць два злучэнні, і калі намаляваць іх асобна, большасць блытаніны знікае за хвіліну.
Два злучэнні, а не адно
Першае злучэнне ідзе ад браўзера да таго, што слухае на петлявым порце. Гэта лакальны сокет, і калі ім ніхто не валодае, злучэнне адхіляецца яшчэ да таго, як хоць адзін пакет дасягне N2N. Другое ідзе ад працэсу проксі да крыніцы, якую ён атрымлівае. Гэты шлях выбірае табліца маршрутызацыі хаста проксі, і ён можа быць звычайным узыходзячым каналам, іншым тунэлем або палітычным маршрутам, які не мае ніякага дачынення да аверлея.
Пінг да партнёра даказвае, што аверлей можа дастаўляць пакеты паміж адрасамі краёў. Ён нічога не даказвае пра слухача на порце 8000 і нічога пра тое, ці можа гэты хаст дасягнуць крыніцы. Асобныя збоі, асобныя выпраўленні.
Дзе павінен жыць слухач
Проксі, прывязаны да 127.0.0.1, наўмысна лакальны: ён прымае злучэнні толькі з машыны, дзе працуе. Гэта правільныя паводзіны па змаўчанні для асабістага проксі і няправільная форма для сумеснага выкарыстання праз аверлей. Каб абслугоўваць партнёраў аверлея, патрэбны альбо адрас прывязкі на інтэрфейсе аверлея, альбо кампанент перасылкі, які завяршае петлявое злучэнне і перадае яго далей. У любым выпадку відавочная палітыка павінна вырашаць, якія крыніцы аверлея могуць карыстацца паслугай, бо адкрыты проксі ў агульнай сетцы — гэта запрашэнне.
Правярайце фактычную прывязку праз спіс сокетаў, а не праз файл канфігурацыі. Дэман, запушчаны да ўздыму аверлея, можа ўсё яшчэ быць прывязаны да адраса, якога ўжо не існуе.
localhost — гэта не партнёр
У полі проксі браўзера localhost паказвае на ўласную машыну браўзера. Гэта не край, не супервузел і не хаст на далёкім канцы тунэля. Калі проксі працуе на іншым партнёры, увядзіце ў поле дасягальны адрас аверлея гэтага партнёра і порт, затым пацвердзіце, што слухач прымае злучэнні з вашага адраса краю.
Супервузлы дапамагаюць краям знаходзіць адно аднаго; яны не з’яўляюцца службай проксі. Стаўленне да адраса супервузла як да канчатковай кропкі проксі дае тую ж адмову з дадатковым скокам блытаніны.
Маршрут не можа выканаць рукапацісканне
Нават калі адрас правільны, маршрутызацыя — гэта не проксі. HTTP-злучэнне проксі пачынаецца з запыту CONNECT або радка запыту ў абсалютнай форме, а SOCKS-проксі пачынаецца з перамоваў пра версію і метад. Маршрутызатар або аверлей перасылае байты; ён не разбірае гэтыя паведамленні і не адкрывае наступнае злучэнне за вас. Менавіта таму маршрут, які працуе для ping і SSH, можа не спрацаваць для проксі браўзера: браўзеру патрэбны супрацоўны працэс, а не проста дасягальнасць.
Калі мэта — проста дасягнуць паслугі на партнёры, выдаліце наладу проксі і выкарыстоўвайце адрас аверлея паслугі напрамую.
Праверце межы па парадку
Пацвердзіце, што адрас аверлея адказвае, затым пацвердзіце, што на наладжаным порце існуе слухач, і запішыце яго адрас прывязкі. Зрабіце адзін кантраляваны запыт і прачытайце журнал проксі, каб ведаць, дзе збой: у слухачы ці ў далейшым атрыманні. Нарэшце, праверце маршрут хаста проксі і палітыку DNS для крыніцы.
Праект N2N дакументуе краі і супервузлы як кампаненты аверлея. Ён не ператварае край у проксі праграмы, і ніякая канфігурацыя маршрутызацыі не дадае апрацоўшчык пратаколу, які ніхто не запускаў.