بركة تعدين عبر VPN: أبقِ الجلسة على المسار الصحيح
يفتح مُعدِّن البركة جلسة Stratum صادرة واحدة، لا منفذ peer. ضع النفق تحت تلك العملية واقرأ المسار والمُحلِّل من فضاء الأسماء الخاص به.
يُبقي برنامج التعدين مقبسًا واحدًا مفتوحًا نحو عنوان واحد، وكل سؤال عن النفق والمسار والعمل المُعتمد معلّق على ذلك المقبس. ذلك المقبس جلسة عميل صادرة إلى نقطة نهاية البركة، لا مستمعًا يقبل أقرانًا. يتبعه السرد أدناه من القيم الأربع التي أصدرتها البركة إلى حصة سجّلتها البركة فعليًا، ولا يمسّ بقية خدمات المضيف. كل خطوة تُنتج جوابًا يمكن مقارنته، لا انطباعًا.
ابدأ من نقطة النهاية التي أصدرتها البركة فعليًا
تمنحك البركة أربع قيم تشكّل العقد كله: اسم المضيف أو العنوان، والمنفذ، وصيغة البروتوكول، وسلسلة الحساب. خذها من لوحة البركة أو من رسالة الترحيب، لا من درس مخصص لبركة أخرى. توجد شرائح إقليمية للخدمة نفسها، لذا قد يتصل اسم مضيف نُسخ من دليل قديم وقد يعتمد حسابًا لم تكن تريد استخدامه أبدًا. انسخ القيم الأربع حرفيًا إلى إعداد المُعدِّن، لأن سلسلة حساب أُعيد كتابتها تفقد فاصلًا.
التدفق الذي توجّهه هو ما يسميه دليل مطوّر Bitcoin جلسة Stratum: اتصال TCP ثنائي الاتجاه دائم يوزّع فيه البركة العمل ويعيد المُعدِّن الحصص. هذا ليس التدفق نفسه الذي تمثله اتصالات الأقران في عقدة كاملة أو مزامنة سلسلة محفظة، ودمجها في فئة حركة واحدة هو موضع بداية معظم الالتباس. الأول وحده يخضع لهذه السياسة.
حيث تتيح البركة 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، حيث يستمع عقدة كاملة للاتصالات الواردة؛ لا يحتاج مُعدِّن البركة إليه مفتوحًا أبدًا، وفتحه لا يصلح عطلًا صادرًا. المستمعات الواردة والجلسات الصادرة أدوار متعاكسة بافتراضات ثقة متعاكسة. لا شيء في إعداد المُعدِّن يربط ذلك المنفذ، لذا لا يمكن لمنفذ مغلق أن يفسّر أي خطأ يبلغ عنه. لذلك قد تترك نصيحة كُتبت من أجل وصول عقدة خدمةً عامة تعمل على مضيف كان المفروض أن يرسل الحصص فقط.
إذا كانت آلة واحدة تؤدي الأمرين فعلًا، فتعامل مع كل دور كخدمة خاصة به وقرار وصول خاص به. مستمع العقدة يقع خلف السياسة التي تطبقها على الخدمات العامة، وجلسة المُعدِّن تنتمي إلى سياسة الخروج التي تختار النفق. سجّل أي دور يؤديه المضيف وأزل قواعد الدور الآخر عند تغيّر ذلك، لأن قاعدة السماح المتبقية تعيش أطول من سببها.
أثبت أن البركة استلمت العمل
مروحة مشغولة ومعدل تجزئة صاعد يظهران أن المُعدِّن يحسب، لا أن شيئًا وصل إلى البركة. الدليل في عدّادات الإرسال لدى العميل أو في لوحة البركة: حصص مقبولة وحصص مرفوضة والسبب المرفق بكل رفض. تفصل تلك الأرقام ثلاثة أعطال تبدو متطابقة من الخارج: لا جلسة، وجلسة بلا اعتماد، وجلسة تعيد الاتصال بلا توقف. اقرأها قبل تغيير أي إعداد.
راقب محاولة اتصال واحدة مع تسجيل مفصل ودوّن المرحلة الأخيرة التي نجحت. المرحلة التي يتوقف عندها التسلسل أنفع من أي رسالة منفردة حولها:
| 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إذا كانت قاعدة تحظر اتصالًا مباشرًا بالبركة كلما سقط النفق، فعبّر عنها كحظر صريح على نقطة نهاية البركة. العميل الذي يعيد المحاولة بهدوء عبر الرابط الفيزيائي سيستمر في التعدين وسيستمر في خرق تلك القاعدة، ولن تذكر شاشة حالته ذلك. اختبر القاعدة بإسقاط النفق عمدًا والتأكد من أن منفذ البركة غير قابل للوصول إطلاقًا.