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 को अभी भी अपनी अनुमत प्रविष्टि की ज़रूरत हो सकती है। कुछ और बदलने से पहले तय करें कि आप वास्तव में तीनों में से किसे जाँच रहे हैं।