Firefox показује на 127.0.0.1:8000, N2N ивица је активна, партнер одговара на ping на својој адреси оверлеја, а прегледач и даље извештава да је прокси одбио везу. Ништа у том ланцу није противречно. Оверлеј даје хосту доступну адресу на приватној мрежи; он не ствара процес који говори прокси протокол. Прегледач не тражи руту до партнера. Он тражи локалног слушаоца.

Овде се мешају две везе, а њихово одвојено цртање разјашњава већину забуне за минут.

Две везе, не једна

Прва веза иде од прегледача до свега што слуша на loopback порту. То је локални socket, и ако га ништа не поседује, веза се одбија пре него што иједан пакет стигне до N2N. Друга иде од прокси процеса до извора који преузима. Тај пут бира таблица рутирања хоста проксија, и то може бити уобичајени uplink, други тунел или рута политике која нема никакве везе са оверлејом.

Ping партнера доказује да оверлеј може да доставља пакете између адреса ивица. Не доказује ништа о слушаоцу на порту 8000, нити о томе да ли тај хост може да достигне извор. Одвојени кварови, одвојене поправке.

Где слушалац мора да живи

Прокси везан за 127.0.0.1 је намерно локалан: прихвата везе само са машине на којој ради. То је исправан подразумевани избор за лични прокси и погрешан облик за његово дељење преко оверлеја. За опслуживање партнера у оверлеју потребна је или bind адреса на интерфејсу оверлеја или компонента за прослеђивање која завршава loopback везу и прослеђује је. У сваком случају, експлицитна политика треба да одлучи који извори оверлеја смеју да користе услугу, јер је отворени прокси на дељеној мрежи позивница.

Проверите стварни bind списком socket-а, а не конфигурационом датотеком. Демон покренут пре него што се оверлеј подигао може и даље бити везан за адресу која више не постоји.

localhost није партнер

У пољу за прокси у прегледачу, localhost показује на машину самог прегледача. То није ивица, није supernode и није хост на далеком крају тунела. Ако прокси ради на другом партнеру, ставите у поље доступну адресу оверлеја и порт тог партнера, затим потврдите да слушалац прихвата везе са адресе ваше ивице.

Supernode-ови помажу ивицама да пронађу једна другу; они нису прокси услуга. Третирање адресе supernode-а као крајње тачке проксија даје исто одбијање уз додатни корак забуне.

Рута не може да изврши handshake

Чак и са тачном адресом, рутирање није проксирање. HTTP прокси веза почиње CONNECT захтевом или линијом захтева у апсолутном облику, а SOCKS прокси почиње преговарањем о верзији и методи. Рутер или оверлеј прослеђује бајтове; он не парсира те поруке и не отвара следећу везу уместо вас. Зато рута која ради за ping и SSH може ипак да не успе за прокси у прегледачу: прегледачу је потребан сараднички процес, а не само доступност.

Ако је циљ само да се стигне до услуге на партнеру, уклоните подешавање проксија и користите адресу услуге у оверлеју директно.

Тестирајте границе по реду

Потврдите да адреса оверлеја одговара, затим потврдите да на конфигурисаном порту постоји слушалац и запишите његову bind адресу. Направите један контролисан захтев и прочитајте дневник проксија, да бисте знали да ли је квар код слушаоца или при даљем преузимању. На крају, проверите руту хоста проксија и DNS политику за извор.

Пројекат N2N документује ивице и supernode-ове као компоненте оверлеја. Он не претвара ивицу у апликацијски прокси, и ниједна конфигурација рутирања не додаје руковаоца протоколом кога нико није покренуо.

Повезани чланци