Az N2N overlay nem proxy: rajzold fel mindkét kapcsolatot

A Firefox a 127.0.0.1:8000 címre mutat, az N2N él fut, a társ válaszol a pingre az overlay-címén, és a böngésző még mindig azt jelzi, hogy a proxy elutasította a kapcsolatot. Semmi sem ellentmondásos ebben a láncban. Az overlay elérhető címet ad a hosztnak egy privát hálózaton; nem hoz létre olyan folyamatot, amely a proxy protokollját beszéli. A böngésző nem útvonalat kér egy társ felé. Helyi listenert kér.

Itt két kapcsolatot kevernek össze, és külön megrajzolásuk a zavar nagy részét egy perc alatt tisztázza.

Két kapcsolat, nem egy

Az első kapcsolat a böngészőtől a loopback porton figyelő valamihez fut. Ez egy helyi socket, és ha semmi sem birtokolja, a kapcsolat elutasításra kerül, mielőtt egyetlen csomag elérné az N2N-t. A második a proxy folyamatától az általa letöltött origóig fut. Ezt az útvonalat a proxy hoszt útválasztási táblája választja, és lehet a szokásos uplink, egy másik alagút vagy olyan házirend-útvonal, amelynek semmi köze az overlay-hez.

A társ pingelése bizonyítja, hogy az overlay képes csomagokat szállítani az élcímek között. Semmit sem bizonyít a 8000-es porton lévő listenerről, és arról sem, hogy az a hoszt eléri-e az origót. Külön hibák, külön javítások.

Hol kell élnie a listenernek

A 127.0.0.1-hez kötött proxy szándékosan helyi: csak arról a gépről fogad kapcsolatokat, amelyen fut. Ez a helyes alapértelmezés egy személyes proxyhoz, és a rossz forma ahhoz, hogy overlay-en osszuk meg. Az overlay társak kiszolgálásához vagy bind-cím kell az overlay interfészen, vagy olyan továbbító komponens, amely lezárja a loopback kapcsolatot és továbbítja. Akárhogy is, egy explicit házirendnek kell eldöntenie, mely overlay-források használhatják a szolgáltatást, mert egy nyitott proxy megosztott hálózaton meghívás.

A tényleges bindet socketlistával ellenőrizze, ne a konfigurációs fájllal. Az overlay indulása előtt indított daemon még mindig olyan címhez kötve lehet, amely már nem létezik.

A localhost nem a társ

A böngésző proxy mezőjében a localhost a böngésző saját gépére mutat. Nem az él, nem a supernode, és nem az alagút túlsó végén lévő hoszt. Ha a proxy egy másik társan fut, tegye a mezőbe annak a társnak az elérhető overlay-címét és portját, majd erősítse meg, hogy a listener fogad kapcsolatokat az Ön élcíméről.

A supernode-ok segítenek az éleknek megtalálni egymást; nem proxy szolgáltatás. Ha egy supernode címet proxy végpontként kezelünk, ugyanazt az elutasítást kapjuk, egy plusz zavaró lépéssel.

Egy útvonal nem tud kézfogást végrehajtani

Még a helyes címmel is, az útválasztás nem proxylás. Egy HTTP proxy kapcsolat CONNECT kéréssel vagy abszolút formájú kérésvonallal kezdődik, és egy SOCKS proxy verzió- és módszer-tárgyalással kezdődik. Egy router vagy overlay bájtokat továbbít; nem elemzi ezeket az üzeneteket, és nem nyitja meg helyetted a következő kapcsolatot. Ezért egy pinghez és SSH-hoz működő útvonal még mindig meghiúsulhat egy böngészőproxy esetén: a böngészőnek együttműködő folyamatra van szüksége, nem csupán elérhetőségre.

Ha a cél csak egy szolgáltatás elérése a társan, távolítsa el a proxy beállítást, és használja közvetlenül a szolgáltatás overlay-címét.

Tesztelje a határokat sorrendben

Erősítse meg, hogy az overlay cím válaszol, majd erősítse meg, hogy a beállított porton létezik listener, és jegyezze fel a bind-címét. Végezzen egy ellenőrzött kérést, és olvassa el a proxy naplóját, hogy tudja, a listenerben vagy a további letöltésben van-e a hiba. Végül ellenőrizze a proxy hoszt útvonalát és az origó DNS-házirendjét.

Az N2N projekt élekként és supernode-okként dokumentálja az overlay komponenseit. Nem alakítja az élt alkalmazásproxyvá, és egyetlen útválasztási konfiguráció sem ad hozzá olyan protokollkezelőt, amelyet senki sem indított.