VPN पर माइनिंग पूल: सत्र को सही रास्ते पर रखें
पूल माइनर एक आउटबाउंड Stratum सत्र खोलता है, peer पोर्ट नहीं। टनल को उस प्रक्रिया के नीचे रखें और मार्ग तथा रिज़ॉल्वर उसके नेमस्पेस से पढ़ें।
माइनिंग सॉफ़्टवेयर एक ही सॉकेट को एक ही पते की ओर खुला रखता है, और टनल, मार्ग तथा जमा किए गए काम से जुड़ा हर सवाल उसी सॉकेट पर टिका है। वह सॉकेट पूल के अंतिम बिंदु की ओर जाने वाला आउटबाउंड क्लाइंट सत्र है, peer स्वीकार करने वाला श्रोता नहीं। नीचे की यात्रा उसे पूल द्वारा जारी चार मानों से उस हिस्से तक ले जाती है जिसे पूल ने वास्तव में दर्ज किया, और मेज़बान की बाकी सेवाओं को नहीं छेड़ती। हर कदम ऐसा उत्तर देता है जिसकी आप तुलना कर सकें, कोई अनुभूति नहीं।
उसी अंतिम बिंदु से शुरू करें जो पूल ने वास्तव में जारी किया
पूल आपको चार मान देता है जो पूरा अनुबंध बनाते हैं: होस्ट नाम या पता, पोर्ट, प्रोटोकॉल प्रकार और खाता स्ट्रिंग। इन्हें पूल के डैशबोर्ड या स्वागत संदेश से लें, किसी दूसरे पूल के ट्यूटोरियल से नहीं। उसी सेवा के लिए क्षेत्रीय शार्ड मौजूद हैं, इसलिए पुरानी मार्गदर्शिका से कॉपी किया गया होस्ट नाम अब भी जुड़ सकता है और अब भी ऐसे खाते में जमा हो सकता है जिसे आप कभी इस्तेमाल नहीं करना चाहते थे। चारों मान बिल्कुल वैसे ही माइनर की कॉन्फ़िगरेशन में कॉपी करें, क्योंकि दोबारा टाइप की गई खाता स्ट्रिंग एक विभाजक खो देती है।
जिस प्रवाह को आप रूट कर रहे हैं वही है जिसे Bitcoin डेवलपर गाइड Stratum सत्र कहता है: एक स्थायी दो-तरफ़ा TCP कनेक्शन जिसमें पूल काम बाँटता है और माइनर हिस्से वापस भेजता है। यह पूरे नोड के peer कनेक्शन या वॉलेट के चेन सिंक जैसा प्रवाह नहीं है, और इन सबको एक ही ट्रैफ़िक वर्ग में मोड़ना ही वह जगह है जहाँ से अधिकतर उलझन शुरू होती है। इस नीति के अंतर्गत केवल पहला आता है।
जहाँ पूल TLS देता है, वहाँ वह सर्वर सत्यापन रखें जिसकी उसके दस्तावेज़ माँग करते हैं। टनल आपकी मशीन से VPN सर्वर तक की छलांग को एन्क्रिप्ट करता है और वहीं समाप्त होता है; यह दूसरी ओर जवाब देने वाले की गारंटी नहीं देता। यदि आप चाहते हैं कि सत्र समझौता किए गए निकास से बचा रहे तो दोनों जाँच रखें, हर सिरे पर एक।
टनल को प्रक्रिया से बाँधें, घर से नहीं
जोड़ने के दो बिंदु काम करते हैं: VPN क्लाइंट को उसी नेटवर्क नेमस्पेस के भीतर चलाएँ जिसका माइनर उपयोग करता है, या उस नेमस्पेस को ऐसा गेटवे दें जो उसका ट्रैफ़िक टनल में ले जाए। दोनों व्यवस्थाएँ सत्र को पूल के देखने से पहले रास्ते पर रख देती हैं। सामान्य विफलता यह है कि क्लाइंट मेज़बान पर हो, माइनर अपने पुल वाले कंटेनर में हो, और मेज़बान का मार्ग ऐसा हो जिसे कंटेनर कभी न पूछे। क्लाइंट की खिड़की स्वस्थ दिखती है जबकि पूल आपके घर का पता दर्ज कर रहा होता है।
कुछ भी सीमित करने से पहले टनल का अपना परिवहन जाँचें। क्लाइंट को अपने सर्वर तक निचली परत से पहुँचना होता है, इसलिए हर पैकेट पकड़ने वाली नीति वे पैकेट भी पकड़ती है जो टनल बनाते। तब टनल शुरू नहीं हो सकता और कुछ और भी बाहर नहीं जाता। क्लाइंट की विभाजित टनल सुविधा से चुनें कि टनल में क्या जाए; डिफ़ॉल्ट मार्गों को हाथ से बदलना ही वह तरीका है जिससे निचली परत गायब हो जाती है।
नीति स्थापित होने के बाद, उस नेमस्पेस में सॉकेट तालिका पढ़ें जिसका मालिक माइनर है। पूल के पोर्ट की ओर प्रवाह टनल इंटरफ़ेस पर होना चाहिए, और दो कमांड इस सवाल का जवाब देते हैं। नीचे का पोर्ट एक उदाहरण है; उसे उससे बदलें जो पूल ने जारी किया।
sudo nsenter -t "$(pidof cgminer)" -n ss -tnp state established 'dport = :3333'
sudo nsenter -t "$(pidof cgminer)" -n ip route get 203.0.113.10मार्ग और रिज़ॉल्वर को माइनर के अपने संदर्भ से पढ़ें
रूटिंग और नाम हल करना हर नेमस्पेस के लिए है, इसलिए सामान्य शेल में चलाई गई जाँच गलत मशीन का वर्णन करती है जब भी माइनर कंटेनर में हो। पहले नेमस्पेस में जाएँ, फिर पूछें कि कौन सा इंटरफ़ेस पैकेट को पूल के पते तक ले जाएगा और कौन सा रिज़ॉल्वर उसके होस्ट नाम का जवाब देगा। मेज़बान के जवाब स्थानांतरित नहीं होते, और उनके बीच का अंतर गलत जगह पर लगाए गए दोष का आम स्रोत है।
जिस इंटरफ़ेस पर आप पहुँचें उसका नाम बताएँ: टनल का अर्थ है सत्र इच्छित मार्ग पर है, जबकि भौतिक लिंक का अर्थ है कि कोई नियम आपकी अपेक्षा से पहले मेल खा गया। उपसर्ग की लंबाई पहले तय करती है, फिर मीट्रिक, फिर नीति के नियम, इसलिए कई डिफ़ॉल्ट प्रविष्टियों वाली तालिका पैकेटों को दोगुना नहीं करती, बस हार जाती है।
रिज़ॉल्वर मार्गों से अलग विफल होते हैं। /etc/resolv.conf को फिर से लिखने वाला टनल नेमस्पेस को ऐसे रिज़ॉल्वर की ओर इंगित छोड़ सकता है जो केवल टनल के भीतर से पहुँच योग्य है, और यह किसी भी TCP हैंडशेक से पहले विफल हो जाता है। पूल के होस्ट नाम को नेमस्पेस के भीतर हल करें और प्रकाशित पते से तुलना करें। यदि खोज समय-समाप्त हो जाए या कुछ और लौटाए, तो मार्गों को छूने से पहले हल करना ठीक करें।
पूल के क्लाइंट और नोड के श्रोता को अलग रखें
पोर्ट 8333 Bitcoin Core का peer पोर्ट है, जहाँ पूरा नोड आने वाले कनेक्शन सुनता है; पूल माइनर को यह कभी खुला नहीं चाहिए, और इसे खोलने से बाहर जाने वाली खराबी ठीक नहीं होती। आने वाले श्रोता और जाने वाले सत्र विपरीत भूमिकाएँ हैं विपरीत भरोसा-मान्यताओं के साथ। माइनर की कॉन्फ़िगरेशन में कुछ भी उस पोर्ट को नहीं बाँधता, इसलिए बंद पोर्ट किसी भी ऐसी त्रुटि की व्याख्या नहीं कर सकता जो वह बताता है। इसलिए नोड की पहुँच के लिए लिखी गई सलाह ऐसे मेज़बान पर सार्वजनिक सेवा चलती छोड़ सकती है जिसे केवल हिस्से भेजने थे।
यदि एक ही मशीन वास्तव में दोनों करती है, तो हर भूमिका को अपने अभिगम निर्णय वाली अलग सेवा मानें। नोड का श्रोता उस नीति के पीछे है जो आप सार्वजनिक सेवाओं पर लगाते हैं, और माइनर का सत्र उस बाहर जाने वाली नीति से संबंधित है जो टनल चुनती है। दर्ज करें कि मेज़बान कौन सी भूमिका निभाता है और जब यह बदले तो दूसरी भूमिका के नियम हटा दें, क्योंकि बचा हुआ अनुमति नियम अपने कारण से अधिक जीता है।
साबित करें कि पूल को काम मिला
व्यस्त पंखा और बढ़ता हैशरेट दिखाते हैं कि माइनर गणना कर रहा है, न कि कुछ पूल तक पहुँचा। प्रमाण क्लाइंट के प्रेषण काउंटरों में या पूल के डैशबोर्ड पर है: स्वीकृत हिस्से, अस्वीकृत हिस्से और हर अस्वीकृति के साथ जुड़ा कारण। वे संख्याएँ तीन ऐसी विफलताएँ अलग करती हैं जो बाहर से एक जैसी दिखती हैं: कोई सत्र नहीं, बिना जमा के सत्र, और ऐसा सत्र जो लगातार दोबारा जुड़ता है। कोई भी कॉन्फ़िगरेशन बदलने से पहले उन्हें पढ़ें।
विस्तृत लॉग के साथ एक कनेक्शन प्रयास देखें और अंतिम चरण लिखें जो सफल हुआ। जिस चरण पर क्रम रुकता है वह आसपास के किसी भी एक संदेश से अधिक उपयोगी है:
| Last stage reached | What it rules out | Probe to run next |
|---|---|---|
| Name lookup completed | Resolver and namespace reachability | ip route get for the returned address |
| TCP connect completed | Route and egress filtering | ss -tnp on the tunnel interface |
| Subscription returned a job | Endpoint or protocol mismatch | Accepted against rejected counts |
फिर क्लाइंट को एक निश्चित विंडो तक चलने दें और उसके लॉग से दोनों परिणाम गिनें। हर काउंटर के लिए एक grep पर्याप्त है, और उनकी तुलना उसी विंडो पर धीमे पूल को टूटे मार्ग से अलग करती है। मार्ग को वहाँ समायोजित करें जहाँ आपका क्लाइंट लिखता है, क्योंकि दोनों गिनती स्थान पर निर्भर नहीं हैं:
grep -c Accepted /var/log/miner.log
grep -c Rejected /var/log/miner.logयदि कोई नियम हर बार टनल गिरने पर पूल से सीधा संपर्क मना करता है, तो उसे पूल के अंतिम बिंदु पर स्पष्ट अवरोध के रूप में व्यक्त करें। ऐसा क्लाइंट जो चुपचाप भौतिक लिंक से दोबारा कोशिश करता है, खनन जारी रखेगा और उस नियम का उल्लंघन जारी रखेगा, और उसकी स्थिति स्क्रीन इसका ज़िक्र नहीं करेगी। नियम को टनल को जानबूझकर गिराकर और यह सुनिश्चित करके परखें कि पूल का पोर्ट बिल्कुल पहुँच योग्य नहीं है।