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कुनै नियमले हरेक पटक टनेल खस्दा पूलसँग सीधा जडान रोक्छ भने त्यसलाई पूलको अन्तिम बिन्दुमा स्पष्ट अवरोधका रूपमा व्यक्त गर्नुहोस्। जो क्लाइन्ट चुपचाप भौतिक लिंकबाट फेरि प्रयास गर्छ त्यसले खनन जारी राख्छ र त्यो नियमको उल्लङ्घन जारी राख्छ, र त्यसको स्थिति स्क्रिनले यो उल्लेख गर्दैन। नियम जाँच्नुहोस् टनेल जानाजान खसालेर र पूलको पोर्ट बिल्कुलै पुग्न नसकिने पुष्टि गरेर।