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

Овде се мешаат две врски, а нивното одделно цртање го разјаснува најголемиот дел од конфузијата за една минута.

Две врски, не една

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

Пингувањето на партнерот докажува дека слојот може да доставува пакети меѓу адресите на работ. Тоа не докажува ништо за слушател на портата 8000, ниту за тоа дали тој домаќин може да стигне до изворот. Одделни дефекти, одделни поправки.

Каде мора да живее слушателот

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

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

localhost не е партнерот

Во полето за прокси на прелистувачот, localhost покажува на машината на самиот прелистувач. Тоа не е работ, не е supernode и не е домаќинот на далечниот крај на тунелот. Ако проксито работи на друг партнер, ставете ја достапната адреса во слојот и портата на тој партнер во полето, потоа потврдете дека слушателот прима врски од адресата на вашиот работ.

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

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

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

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

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

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

Проектот N2N ги документира рабовите и supernode-овите како компоненти на слојот. Тој не претвора работ во апликациско прокси и ниту една конфигурација за рутирање не додава обработувач на протокол што никој не го стартувал.

Поврзани статии