N2N ఓవర్లే ప్రాక్సీ కాదు: రెండు కనెక్షన్లను గీయండి

Firefox 127.0.0.1:8000 వైపు చూపుతుంది, N2N అంచు నడుస్తోంది, పీర్ తన ఓవర్లే చిరునామాలో ping కి జవాబిస్తోంది, మరియు బ్రౌజర్ ఇంకా ప్రాక్సీ కనెక్షన్ను తిరస్కరించిందని నివేదిస్తోంది. ఆ గొలుసులో ఏదీ విరుద్ధం కాదు. ఓవర్లే హోస్ట్కు ప్రైవేట్ నెట్వర్క్లో చేరుకోగల చిరునామా ఇస్తుంది; అది ప్రాక్సీ ప్రోటోకాల్ మాట్లాడే ప్రక్రియను సృష్టించదు. బ్రౌజర్ పీర్ వైపు మార్గం అడగడం లేదు. అది స్థానిక లిసనర్ అడుగుతోంది.

ఇక్కడ రెండు కనెక్షన్లు గందరగోళపడుతున్నాయి, వాటిని విడివిడిగా గీస్తే చాలా గందరగోళం ఒక నిమిషంలో స్పష్టమవుతుంది.

రెండు కనెక్షన్లు, ఒకటి కాదు

మొదటి కనెక్షన్ బ్రౌజర్ నుండి loopback పోర్ట్లో వినిపించే ఏదైనా వైపు వెళ్తుంది. అది స్థానిక సాకెట్, దానిని ఎవరూ కలిగి లేకపోతే ఒక ప్యాకెట్ కూడా N2N చేరుకునే ముందు కనెక్షన్ తిరస్కరించబడుతుంది. రెండవది ప్రాక్సీ ప్రక్రియ నుండి అది తెచ్చుకునే మూలానికి వెళ్తుంది. ఆ మార్గాన్ని ప్రాక్సీ హోస్ట్ రూటింగ్ పట్టిక ఎంచుకుంటుంది, అది సాధారణ అప్లింక్, మరో టన్నెల్, లేదా ఓవర్లేతో ఎటువంటి సంబంధం లేని విధాన మార్గం కావచ్చు.

పీర్కు ping చేయడం ఓవర్లే అంచు చిరునామాల మధ్య ప్యాకెట్లను చేరవేయగలదని నిరూపిస్తుంది. ఇది పోర్ట్ 8000 లోని లిసనర్ గురించి ఏమీ నిరూపించదు, ఆ హోస్ట్ మూలాన్ని చేరుకోగలదా అనేది కూడా కాదు. వేర్వేరు వైఫల్యాలు, వేర్వేరు పరిష్కారాలు.

లిసనర్ ఎక్కడ ఉండాలి

127.0.0.1 కు bind అయిన ప్రాక్సీ ఉద్దేశపూర్వకంగా స్థానికం: అది నడిచే మెషీన్ నుండి మాత్రమే కనెక్షన్లను అంగీకరిస్తుంది. వ్యక్తిగత ప్రాక్సీకి ఇది సరైన డిఫాల్ట్, ఓవర్లే ద్వారా పంచుకోవడానికి తప్పు రూపం. ఓవర్లే పీర్లకు సేవ చేయాలంటే ఓవర్లే ఇంటర్ఫేస్లో bind చిరునామా లేదా loopback కనెక్షన్ను ముగించి పంపే ఫార్వార్డింగ్ ఘటకం అవసరం. ఏదేమైనా, పంచుకున్న నెట్వర్క్లో తెరిచిన ప్రాక్సీ ఆహ్వానం కాబట్టి, ఏ ఓవర్లే మూలాలు సేవను ఉపయోగించవచ్చో స్పష్టమైన విధానం నిర్ణయించాలి.

నిజమైన bind ను కాన్ఫిగరేషన్ ఫైల్కు బదులు సాకెట్ జాబితాతో తనిఖీ చేయండి. ఓవర్లే లేచే ముందు ప్రారంభమైన డీమన్ ఇప్పుడు లేని చిరునామాకు ఇంకా కట్టుబడి ఉండవచ్చు.

localhost పీర్ కాదు

బ్రౌజర్ ప్రాక్సీ ఫీల్డ్లో, localhost బ్రౌజర్ స్వంత మెషీన్ను చూపుతుంది. అది అంచు కాదు, సూపర్నోడ్ కాదు, టన్నెల్ దూర చివరి హోస్ట్ కూడా కాదు. ప్రాక్సీ మరో పీర్లో నడుస్తుంటే, ఆ పీర్ యొక్క చేరుకోగల ఓవర్లే చిరునామా మరియు పోర్ట్ను ఫీల్డ్లో పెట్టి, లిసనర్ మీ అంచు చిరునామా నుండి కనెక్షన్లను అంగీకరిస్తుందని నిర్ధారించుకోండి.

సూపర్నోడ్లు అంచులను ఒకదానికొకటి కనుగొనడంలో సహాయపడతాయి; అవి ప్రాక్సీ సేవ కాదు. సూపర్నోడ్ చిరునామాను ప్రాక్సీ ఎండ్పాయింట్గా పరిగణించడం అదే తిరస్కరణను అదనపు గందరగోళ అడుగుతో ఇస్తుంది.

మార్గం handshake చేయలేదు

చిరునామా సరైనదైనా, రూటింగ్ ప్రాక్సీ చేయడం కాదు. HTTP ప్రాక్సీ కనెక్షన్ CONNECT అభ్యర్థన లేదా సంపూర్ణ రూప అభ్యర్థన పంక్తితో ప్రారంభమవుతుంది, SOCKS ప్రాక్సీ వెర్షన్ మరియు పద్ధతి చర్చతో ప్రారంభమవుతుంది. రౌటర్ లేదా ఓవర్లే బైట్లను ముందుకు పంపుతుంది; అది ఆ సందేశాలను విశ్లేషించదు లేదా మీ తరఫున తదుపరి కనెక్షన్ను తెరవదు. అందుకే ping మరియు SSH కి పనిచేసే మార్గం బ్రౌజర్ ప్రాక్సీకి విఫలమవచ్చు: బ్రౌజర్కు సహకరించే ప్రక్రియ అవసరం, కేవలం చేరుకోగలగడం మాత్రమే కాదు.

లక్ష్యం పీర్లోని సేవను చేరుకోవడం మాత్రమే అయితే, ప్రాక్సీ సెట్టింగ్ను తీసివేసి సేవ యొక్క ఓవర్లే చిరునామాను నేరుగా ఉపయోగించండి.

సరిహద్దులను క్రమంగా పరీక్షించండి

ఓవర్లే చిరునామా జవాబిస్తుందని నిర్ధారించుకోండి, తర్వాత కాన్ఫిగర్ చేసిన పోర్ట్లో లిసనర్ ఉందని నిర్ధారించి దాని bind చిరునామాను గుర్తించండి. ఒక నియంత్రిత అభ్యర్థన చేసి ప్రాక్సీ లాగ్ చదవండి, వైఫల్యం లిసనర్ వద్ద ఉందా లేదా తదుపరి తెచ్చుకోవడంలో ఉందా తెలుసుకోవడానికి. చివరగా, ప్రాక్సీ హోస్ట్ మార్గాన్ని మరియు మూలం కోసం DNS విధానాన్ని తనిఖీ చేయండి.

N2N ప్రాజెక్ట్ అంచులు మరియు సూపర్నోడ్లను ఓవర్లే ఘటకాలుగా రేఖాచిత్రీకరిస్తుంది. అది అంచును అప్లికేషన్ ప్రాక్సీగా మార్చదు, ఏ రూటింగ్ కాన్ఫిగరేషన్ ఎవరూ ప్రారంభించని ప్రోటోకాల్ హ్యాండ్లర్ను జోడించదు.