Майнінговий пул через VPN: тримати сесію на правильному шляху

Майнінгове програмне забезпечення тримає один сокет відкритим до однієї адреси, і кожне питання про тунель, маршрут і зараховану роботу висить на цьому сокеті. Цей сокет — вихідна клієнтська сесія до кінцевої точки пулу, а не слухач, що приймає 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 — це peer-порт Bitcoin Core, де повний вузол слухає вхідні з’єднання; пул-майнеру він ніколи не потрібен відкритим, і відкриття його не виправляє вихідну несправність. Вхідні слухачі й вихідні сесії — протилежні ролі з протилежними припущеннями довіри. Ніщо в конфігурації майнера не прив’язує цей порт, тож закритий порт не може пояснити жодної помилки, яку він повідомляє. Порада, написана для доступності вузла, може тому залишити публічну службу працювати на хості, який мав лише надсилати частки.

Якщо одна машина справді робить обидві речі, ставтеся до кожної ролі як до окремої служби з власним рішенням про доступ. Слухач вузла належить за політику, яку ви застосовуєте до публічних служб, а сесія майнера належить до вихідної політики, що вибирає тунель. Запишіть, яку роль відіграє хост, і прибирайте правила іншої ролі, коли це змінюється, бо залишене дозвільне правило переживає свою причину.

Доведіть, що пул отримав роботу

Зайнятий вентилятор і зростаючий hashrate показують, що майнер обчислює, а не що щось дісталося пулу. Доказ у лічильниках надсилання клієнта або на панелі пулу: прийняті частки, відхилені частки й причина, прикріплена до кожного відхилення. Ці числа розділяють три несправності, які зовні виглядають однаково: немає сесії, сесія без зарахування й сесія, що постійно перепідключається. Прочитайте їх, перш ніж змінювати будь-яку конфігурацію.

Спостерігайте за однією спробою з’єднання з докладним логуванням і занотуйте останній етап, що вдався. Етап, на якому послідовність спиняється, корисніший за будь-яке окреме повідомлення навколо нього:

Потім дайте клієнтові пропрацювати фіксоване вікно й порахуйте обидва результати з його логу. Одного grep на лічильник достатньо, і порівняння їх у тому самому вікні відділяє повільний пул від зламаного шляху. Налаштуйте шлях до місця, куди пише клієнт, бо ці два підрахунки не залежать від розташування:

grep -c Accepted /var/log/miner.log
grep -c Rejected /var/log/miner.log

Якщо правило забороняє пряме з’єднання з пулом щоразу, коли тунель падає, висловіть його як явне блокування кінцевої точки пулу. Клієнт, що тихо повторює спробу через фізичне з’єднання, продовжить майнити й продовжить порушувати це правило, а його дисплей стану про це не згадає. Перевірте правило, навмисно скинувши тунель і підтвердивши, що порт пулу зовсім недоступний.