VPN मागील तुमच्या Bitcoin नोडवर कोणतेही इनबाउंड पीअर नाहीत?

तुमचा नोड सिंक झाला आहे, VPN कनेक्टेड असल्याचे सांगते, आणि getpeerinfo आठ किंवा दहा पीअर दाखवते. त्यापैकी कोणत्याहीकडे inbound true वर सेट नाही. हे संयोजन सामान्य आहे आणि ती बिघाड नाही: आउटबाउंड कनेक्शन सिद्ध करतात की नोड इतरांपर्यंत पोहोचू शकतो, आणि त्यांच्यात काहीही सिद्ध करत नाही की कोणी तुमच्यापर्यंत पोहोचू शकतो. लक्ष्य VPN द्वारे इनबाउंड P2P कनेक्शन स्वीकारणारा नोड असेल, तर ती दिशा स्वतंत्रपणे तपासावी लागेल.

पीअरपासून तुमच्या लिसनरपर्यंत पॅकेटचा मागोवा घ्या

इनबाउंड P2P चार गोष्टींची साखळी आहे, आणि ती सर्वात कमकुवत दुव्यावर तुटते, सर्वात मनोरंजक दुव्यावर नाही.

other peer
  -> provider's public address and assigned port
  -> the permitted VPN mapping
  -> Bitcoin Core's P2P listener

मुख्य नेटवर्कवर Core चे P2P डीफॉल्ट 8333 आहे, पण प्रदाता तुम्हाला वेगळा सार्वजनिक पोर्ट आणि क्लायंट बाजूला वेगळे गंतव्य देऊ शकतो. सार्वजनिक पत्ता, बाह्य पोर्ट आणि प्रदाता प्रत्यक्षात ट्राफिक कुठे पोहोचवतो ते लिहून घ्या. नंतर तुमची योजना आणि खाते इनबाउंड कनेक्शनला अजिबात परवानगी देतात का याची खात्री करा, कारण समर्पित एक्झिट पत्ता पोर्ट-फॉरवर्डिंग करार नाही.

हा फरक पोहोचेच्या अपेक्षेने स्टॅटिक IP खरेदी करणाऱ्यांना पकडतो. पत्ता स्थिर असणे याबद्दल काहीही सांगत नाही की प्रदाता तुमच्या सत्रावर इनबाउंड पोर्ट फॉरवर्ड करतो का.

प्रदाता तपासण्यापूर्वी लिसनर तपासा

मॅपिंग ज्या पत्ता आणि पोर्टवर पोहोचवते तिथे Core ने ऐकले पाहिजे, आणि होस्ट फायरवॉलने ते परवानगी दिली पाहिजे. नोड कंटेनरमध्ये किंवा दुसऱ्या LAN मशीनवर चालत असेल, तर पुढील हॉप आणि त्याचा प्रत्युत्तर मार्गही साखळीत येतो.

येणारे पॅकेट टाकून देणाऱ्या प्रदात्याकडे स्थानिक फायरवॉल नियम मॅपिंग तयार करू शकत नाही, आणि प्रदात्याचे मॅपिंग केवळ loopback ला बांधलेल्या प्रक्रियेपर्यंत पोहोचू शकत नाही. दोन्ही अर्ध्यांनी एकाच टपलवर सहमत व्हावे, म्हणूनच पहिले पाऊल टपलचा अंदाज लावणे नाही, तर तो लिहून घेणे आहे.

जाहीर केलेला एंडपॉइंट सध्याच्या मॅपिंगशी सुसंगत ठेवा. स्टॅटिक पत्ता नियुक्त केलेला पोर्ट किंवा त्याची लीज पुन्हा कनेक्ट होण्यांमध्ये कायमची करत नाही, त्यामुळे महिन्यांपूर्वी प्रकाशित केलेला एंडपॉइंट आता काहीही दर्शवत नसू शकतो. कोणत्याही पुन्हा कनेक्शननंतर प्रदात्याचे पान पुन्हा वाचा आणि तुमचा नोड जे जाहीर करतो त्याशी तुलना करा. पोर्ट हलला असेल, तर जुना एंडपॉइंट आता एकतर कोणाचाही नाही किंवा दुसऱ्या कोणाचा आहे.

इनबाउंड फ्लॅग वाचा, कनेक्शनची एकूण संख्या नाही

अधिकृत स्थानिक RPC संदर्भातून, ही फक्त-वाचन क्वेरी पीअरची यादी करते:

bitcoin-cli getpeerinfo

RPC संदर्भ inbound ला येणाऱ्या कनेक्शनसाठी true आणि जाणाऱ्या कनेक्शनसाठी false असे परिभाषित करतो. ते क्षेत्र पहा. दहापेक्षा जास्त एकूण संख्या दिशेबद्दल काहीही सिद्ध करत नाही, आणि एकूण संख्या व श्रेणी कॉन्फिगरेशन व आवृत्तीसोबत बदलतात.

नंतर मॅप केलेला एंडपॉइंट बाहेरून, तुम्हाला चालवण्याचा अधिकार असलेल्या नवीन पोहोच तपासणीने तपासा, आणि संबंधित इनबाउंड पीअर दिसतो का पहा. सपोर्ट थ्रेडमध्ये तुम्ही पेस्ट करता त्या आउटपुटबाबत सावध रहा: पीअरचे पत्ते इतर लोकांच्या कनेक्शनचे तपशील आहेत, आणि तुमच्या प्रश्नाचे उत्तर मिळण्यासाठी ते प्रकाशित करण्याची गरज नाही.

RPC उघड करून हे सोडवू नका

Bitcoin Core चे RPC दस्तऐवज RPC इंटरफेस सार्वजनिक इंटरनेटवर उघड करण्याविरुद्ध स्पष्ट इशारा देते. पीअर कनेक्शन आणि प्रमाणित प्रशासन वेगवेगळ्या सेवा आहेत, आणि RPC प्रकाशित करून P2P पोहोचण्यायोग्य करणे हे कनेक्टिव्हिटीची समस्या त्याहून वाईट समस्येशी बदलते.

जर तुम्हाला इनबाउंड P2P वर अजिबात अवलंबून राहायचे नसेल, तर दस्तऐवजीकृत पर्याय onion सेवा आहे, आणि तिच्या स्वतःच्या पूर्वअटी आहेत: Tor उपलब्ध असणे, कंट्रोल प्रमाणीकरण कॉन्फिगर केलेले असणे आणि सेवा तयार करण्यास परवानगी देणारी ऐकण्याची सेटिंग्ज. केवळ VPN चालू आहे म्हणून ती दिसत नाही.

Core ला VPN मधून वगळणे ही तिसरी रचना आहे, आणि काही ऑपरेटरसाठी ती वैध आहे, पण ती पीअर ट्राफिक तुमच्या नेहमीच्या कनेक्शनवर टाकते. ते VPN द्वारे इनबाउंड प्रवेश नाही, आणि राउटर किंवा अपस्ट्रीम NAT ला अजूनही स्वतःची परवानगी असलेली नोंद लागू शकते. दुसरे काहीही बदलण्यापूर्वी तुम्ही तीनपैकी कोणते प्रत्यक्ष तपासत आहात ते ठरवा.