N2N ઓવરલે પ્રોક્સી નથી: બંને કનેક્શન દોરો

Firefox 127.0.0.1:8000 તરફ નિર્દેશ કરે છે, N2N એજ ચાલુ છે, પીઅર તેના ઓવરલે સરનામા પર ping નો જવાબ આપે છે, અને બ્રાઉઝર હજી પણ જણાવે છે કે પ્રોક્સીએ કનેક્શન નકાર્યું. તે સાંકળમાં કંઈ વિરોધાભાસી નથી. ઓવરલે હોસ્ટને ખાનગી નેટવર્ક પર પહોંચી શકાય તેવું સરનામું આપે છે; તે પ્રોક્સી પ્રોટોકોલ બોલતી પ્રક્રિયા બનાવતું નથી. બ્રાઉઝર પીઅર તરફ રૂટ માંગતું નથી. તે સ્થાનિક લિસનર માંગે છે.

અહીં બે કનેક્શન ભેગા થઈ ગયા છે, અને તેમને અલગ દોરવાથી મોટાભાગની ગૂંચવણ એક મિનિટમાં દૂર થાય છે.

બે કનેક્શન, એક નહીં

પ્રથમ કનેક્શન બ્રાઉઝરથી loopback પોર્ટ પર સાંભળતા કોઈપણ સુધી જાય છે. તે સ્થાનિક સોકેટ છે, અને જો કોઈ તેનું માલિક ન હોય, તો એક પણ પેકેટ N2N સુધી પહોંચે તે પહેલાં કનેક્શન નકારવામાં આવે છે. બીજું પ્રોક્સી પ્રક્રિયાથી તે જે મેળવે છે તે મૂળ સુધી જાય છે. તે માર્ગ પ્રોક્સી હોસ્ટનું રૂટિંગ ટેબલ પસંદ કરે છે, અને તે સામાન્ય અપલિંક, બીજું ટનલ, અથવા ઓવરલે સાથે કોઈ સંબંધ ન હોય તેવો નીતિ-માર્ગ હોઈ શકે છે.

પીઅરને ping કરવું સાબિત કરે છે કે ઓવરલે એજ સરનામાંઓ વચ્ચે પેકેટ પહોંચાડી શકે છે. તે પોર્ટ 8000 પરના લિસનર વિશે કંઈ સાબિત કરતું નથી, અને તે હોસ્ટ મૂળ સુધી પહોંચી શકે છે કે નહીં તે પણ નહીં. અલગ નિષ્ફળતાઓ, અલગ સુધારા.

લિસનર ક્યાં રહેવું જોઈએ

127.0.0.1 સાથે બાઇન્ડ થયેલ પ્રોક્સી જાણી જોઈને સ્થાનિક છે: તે ફક્ત જે મશીન પર ચાલે છે તેના ત્યાંથી જ કનેક્શન સ્વીકારે છે. વ્યક્તિગત પ્રોક્સી માટે તે યોગ્ય ડિફોલ્ટ છે અને ઓવરલે દ્વારા શેર કરવા માટે ખોટો આકાર છે. ઓવરલે પીઅરને સેવા આપવા માટે કાં તો ઓવરલે ઇન્ટરફેસ પર બાઇન્ડ સરનામું, અથવા loopback કનેક્શન સમાપ્ત કરી તેને રિલે કરતો ફોરવર્ડિંગ ઘટક જોઈએ. કોઈપણ રીતે, સ્પષ્ટ નીતિએ નક્કી કરવું જોઈએ કે કયા ઓવરલે સ્રોત આ સેવા વાપરી શકે, કારણ કે શેર કરેલ નેટવર્ક પર ખુલ્લી પ્રોક્સી આમંત્રણ છે.

કન્ફિગરેશન ફાઇલને બદલે સોકેટ સૂચિ સાથે વાસ્તવિક બાઇન્ડ તપાસો. ઓવરલે આવ્યા પહેલાં શરૂ થયેલ ડિમન હવે અસ્તિત્વમાં ન હોય તેવા સરનામા સાથે બંધાયેલું રહી શકે છે.

localhost પીઅર નથી

બ્રાઉઝરના પ્રોક્સી ક્ષેત્રમાં, localhost બ્રાઉઝરની પોતાની મશીન તરફ નિર્દેશ કરે છે. તે એજ નથી, સુપરનોડ નથી, અને ટનલના દૂરના છેડાનું હોસ્ટ પણ નથી. જો પ્રોક્સી બીજા પીઅર પર ચાલે છે, તો તે પીઅરનું પહોંચી શકાય તેવું ઓવરલે સરનામું અને પોર્ટ ક્ષેત્રમાં મૂકો, પછી ખાતરી કરો કે લિસનર તમારા એજ સરનામાથી કનેક્શન સ્વીકારે છે.

સુપરનોડ એજને એકબીજાને શોધવામાં મદદ કરે છે; તેઓ પ્રોક્સી સેવા નથી. સુપરનોડ સરનામાને પ્રોક્સી એન્ડપોઇન્ટ તરીકે ગણવાથી એ જ ઇનકાર મળે છે, સાથે વધારાનું ગૂંચવણનું પગલું.

રૂટ હેન્ડશેક કરી શકતો નથી

સરનામું સાચું હોવા છતાં, રૂટિંગ પ્રોક્સીંગ નથી. HTTP પ્રોક્સી કનેક્શન CONNECT વિનંતી અથવા સંપૂર્ણ-સ્વરૂપ વિનંતી લાઇનથી શરૂ થાય છે, અને SOCKS પ્રોક્સી આવૃત્તિ અને પદ્ધતિની વાટાઘાટથી શરૂ થાય છે. રાઉટર અથવા ઓવરલે બાઇટ્સ ફોરવર્ડ કરે છે; તે તે સંદેશાઓનું વિશ્લેષણ કરતું નથી કે તમારા વતી આગળનું કનેક્શન ખોલતું નથી. તેથી જ ping અને SSH માટે કામ કરતો માર્ગ બ્રાઉઝર પ્રોક્સી માટે નિષ્ફળ થઈ શકે છે: બ્રાઉઝરને સહકાર આપતી પ્રક્રિયા જોઈએ, ફક્ત પહોંચ શકાય તેવું હોવું નહીં.

જો ધ્યેય ફક્ત પીઅર પરની સેવા સુધી પહોંચવાનો હોય, તો પ્રોક્સી સેટિંગ દૂર કરો અને સેવાનું ઓવરલે સરનામું સીધું વાપરો.

સીમાઓ ક્રમમાં ચકાસો

ખાતરી કરો કે ઓવરલે સરનામું જવાબ આપે છે, પછી ખાતરી કરો કે કન્ફિગર કરેલા પોર્ટ પર લિસનર છે અને તેનું બાઇન્ડ સરનામું નોંધો. એક નિયંત્રિત વિનંતી કરો અને પ્રોક્સીનો લોગ વાંચો, જેથી તમે જાણી શકો કે નિષ્ફળતા લિસનર પર છે કે આગળના ફેરવવામાં. અંતે, પ્રોક્સી હોસ્ટનો માર્ગ અને મૂળ માટે DNS નીતિ તપાસો.

N2N પ્રોજેક્ટ એજ અને સુપરનોડને ઓવરલે ઘટકો તરીકે દસ્તાવેજ કરે છે. તે એજને એપ્લિકેશન પ્રોક્સીમાં ફેરવતું નથી, અને કોઈ રૂટિંગ કન્ફિગરેશન એવો પ્રોટોકોલ હેન્ડલર ઉમેરતું નથી જે કોઈએ શરૂ ન કર્યો હોય.