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