Overlay N2N to nie proxy: narysuj oba połączenia

Firefox wskazuje na 127.0.0.1:8000, krawędź N2N działa, peer odpowiada na ping pod swoim adresem overlay, a przeglądarka nadal zgłasza, że proxy odrzuciło połączenie. Nic w tym łańcuchu nie jest sprzeczne. Overlay daje hostowi osiągalny adres w sieci prywatnej; nie tworzy procesu, który mówi protokołem proxy. Przeglądarka nie prosi o trasę do peera. Prosi o lokalny listener.

Mylone są tu dwa połączenia, a narysowanie ich osobno wyjaśnia większość zamieszania w ciągu minuty.

Dwa połączenia, nie jedno

Pierwsze połączenie biegnie od przeglądarki do tego, co nasłuchuje na porcie loopback. To lokalny socket, a jeśli nic go nie posiada, połączenie jest odrzucane, zanim choć jeden pakiet dotrze do N2N. Drugie biegnie od procesu proxy do źródła, które pobiera. Tę ścieżkę wybiera tablica routingu hosta proxy, i może to być zwykły uplink, inny tunel albo trasa polityki, która nie ma nic wspólnego z overlayem.

Pingowanie peera dowodzi, że overlay potrafi dostarczać pakiety między adresami krawędzi. Nie dowodzi niczego o listenerze na porcie 8000 ani o tym, czy ten host dotrze do źródła. Osobne awarie, osobne poprawki.

Gdzie musi mieszkać listener

Proxy związane z 127.0.0.1 jest celowo lokalne: akceptuje połączenia tylko z maszyny, na której działa. To właściwa wartość domyślna dla osobistego proxy i zły kształt do współdzielenia go przez overlay. Obsługa peerów overlaya wymaga albo adresu bind na interfejsie overlaya, albo komponentu przekazującego, który kończy połączenie loopback i przekazuje je dalej. W każdym razie jawna polityka powinna decydować, które źródła overlaya mogą korzystać z usługi, bo otwarte proxy w współdzielonej sieci to zaproszenie.

Sprawdź rzeczywisty bind listą socketów, a nie plikiem konfiguracji. Demon uruchomiony przed podniesieniem overlaya może nadal być związany z adresem, który już nie istnieje.

localhost nie jest peerem

W polu proxy przeglądarki localhost wskazuje maszynę samej przeglądarki. To nie krawędź, nie supernode i nie host na drugim końcu tunelu. Jeśli proxy działa na innym peerze, wpisz w polu osiągalny adres overlay i port tego peera, a następnie potwierdź, że listener akceptuje połączenia z adresu twojej krawędzi.

Supernody pomagają krawędziom się odnajdywać; nie są usługą proxy. Traktowanie adresu supernoda jako punktu końcowego proxy daje tę samą odmowę z dodatkowym krokiem zamieszania.

Trasa nie może wykonać handshake’u

Nawet z poprawnym adresem routing to nie proxying. Połączenie proxy HTTP zaczyna się od żądania CONNECT lub wiersza żądania w formie absolutnej, a proxy SOCKS zaczyna się od negocjacji wersji i metody. Router albo overlay przekazuje bajty; nie parsuje tych komunikatów i nie otwiera za ciebie dalszego połączenia. Dlatego trasa, która działa dla ping i SSH, może nadal zawieść dla proxy przeglądarki: przeglądarka potrzebuje współpracującego procesu, a nie tylko osiągalności.

Jeśli celem jest tylko dotarcie do usługi na peerze, usuń ustawienie proxy i użyj adresu overlay usługi bezpośrednio.

Testuj granice po kolei

Potwierdź, że adres overlay odpowiada, następnie potwierdź, że na skonfigurowanym porcie istnieje listener, i zapisz jego adres bind. Wykonaj jedno kontrolowane żądanie i przeczytaj log proxy, żeby wiedzieć, czy awaria jest w listenerze, czy w dalszym pobieraniu. Na koniec sprawdź trasę hosta proxy i politykę DNS dla źródła.

Projekt N2N dokumentuje krawędzie i supernody jako komponenty overlaya. Nie zamienia krawędzi w proxy aplikacji i żadna konfiguracja routingu nie dodaje obsługi protokołu, której nikt nie uruchomił.