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एखादा नियम प्रत्येक वेळी टनेल पडल्यावर पूलशी थेट जोडणी प्रतिबंधित करत असेल, तर तो पूलच्या शेवटच्या टोकावर स्पष्ट अडथळा म्हणून व्यक्त करा। जो क्लायंट शांतपणे भौतिक दुव्यावरून पुन्हा प्रयत्न करतो तो खाणकाम चालू ठेवेल आणि त्या नियमाचे उल्लंघन चालू ठेवेल, आणि त्याची स्थिती स्क्रीन याचा उल्लेख करणार नाही। नियम टनेल जाणीवपूर्वक पाडून आणि पूलचा पोर्ट अजिबात पोहोचण्यायोग्य नाही याची खात्री करून तपासा।