Overlay N2N bukan proksi: lukis kedua-dua sambungan
Overlay boleh sampai ke rakan sebaya sementara pelayar masih menerima penolakan. Itu pendengar yang hilang atau bind yang salah, bukan kegagalan penghalaan dalam N2N.
Firefox menunjuk ke 127.0.0.1:8000, tepi N2N aktif, rakan sebaya menjawab ping pada alamat overlaynya, dan pelayar masih melaporkan bahawa proksi menolak sambungan itu. Tiada apa-apa yang bercanggah dalam rantaian itu. Overlay memberikan hos alamat yang boleh dicapai pada rangkaian peribadi; ia tidak mencipta proses yang bertutur protokol proksi. Pelayar tidak meminta laluan ke rakan sebaya. Ia meminta pendengar tempatan.
Dua sambungan dikelirukan di sini, dan melukisnya secara berasingan menjelaskan sebahagian besar kekeliruan dalam satu minit.
Dua sambungan, bukan satu
Sambungan pertama berjalan dari pelayar ke apa sahaja yang mendengar pada port loopback. Itu soket tempatan, dan jika tiada apa yang memilikinya, sambungan ditolak sebelum satu paket pun sampai ke N2N. Yang kedua berjalan dari proses proksi ke asal yang diambilnya. Laluan itu dipilih oleh jadual penghalaan hos proksi, dan ia boleh menjadi uplink biasa, terowong lain, atau laluan dasar yang tiada kaitan dengan overlay.
Ping rakan sebaya membuktikan overlay boleh menyampaikan paket antara alamat tepi. Ia tidak membuktikan apa-apa tentang pendengar pada port 8000, dan tidak juga sama ada hos itu boleh sampai ke asal. Kegagalan berasingan, pembaikan berasingan.
Di mana pendengar mesti tinggal
Proksi yang diikat kepada 127.0.0.1 sengaja tempatan: ia hanya menerima sambungan daripada mesin tempat ia berjalan. Itu lalai yang betul untuk proksi peribadi dan bentuk yang salah untuk berkongsinya melalui overlay. Melayani rakan sebaya overlay memerlukan sama ada alamat bind pada antara muka overlay atau komponen pemajuan yang menamatkan sambungan loopback dan memajukannya. Walau apa pun, dasar eksplisit harus memutuskan sumber overlay mana yang boleh menggunakan perkhidmatan itu, kerana proksi terbuka pada rangkaian kongsi ialah jemputan.
Periksa bind sebenar dengan senarai soket dan bukan fail konfigurasi. Daemon yang dimulakan sebelum overlay naik mungkin masih terikat pada alamat yang tidak lagi wujud.
localhost bukan rakan sebaya
Dalam medan proksi pelayar, localhost menunjuk ke mesin pelayar itu sendiri. Ia bukan tepi, bukan supernode, dan bukan hos di hujung jauh terowong. Jika proksi berjalan pada rakan sebaya lain, letakkan alamat overlay yang boleh dicapai dan port rakan sebaya itu dalam medan, kemudian sahkan bahawa pendengar menerima sambungan daripada alamat tepi anda.
Supernode membantu tepi menemui satu sama lain; ia bukan perkhidmatan proksi. Menganggap alamat supernode sebagai titik akhir proksi menghasilkan penolakan yang sama dengan satu langkah kekeliruan tambahan.
Laluan tidak boleh melakukan handshake
Walaupun alamat betul, penghalaan bukan pemproksian. Sambungan proksi HTTP bermula dengan permintaan CONNECT atau baris permintaan bentuk mutlak, dan proksi SOCKS bermula dengan rundingan versi dan kaedah. Penghala atau overlay memajukan bait; ia tidak menghurai mesej itu atau membuka sambungan seterusnya untuk anda. Itulah sebabnya laluan yang berfungsi untuk ping dan SSH masih boleh gagal untuk proksi pelayar: pelayar memerlukan proses yang bekerjasama, bukan sekadar kebolehcapaian.
Jika matlamatnya hanya untuk sampai ke perkhidmatan pada rakan sebaya, buang tetapan proksi dan gunakan alamat overlay perkhidmatan itu secara langsung.
Uji sempadan mengikut urutan
Sahkan alamat overlay menjawab, kemudian sahkan pendengar wujud pada port yang dikonfigurasikan dan catat alamat bindnya. Buat satu permintaan terkawal dan baca log proksi, supaya anda tahu sama ada kegagalan itu pada pendengar atau pada pengambilan seterusnya. Akhir sekali, periksa laluan hos proksi dan dasar DNS untuk asal.
Projek N2N mendokumentasikan tepi dan supernode sebagai komponen overlay. Ia tidak menjadikan tepi sebagai proksi aplikasi, dan tiada konfigurasi penghalaan menambah pengendali protokol yang tiada siapa mulakan.