Майнинг-пул через VPN: держать сессию на правильном пути

Майнинговое ПО держит один сокет открытым к одному адресу, и каждый вопрос о туннеле, маршруте и зачтённой работе висит на этом сокете. Этот сокет — исходящая клиентская сессия к конечной точке пула, а не слушатель, принимающий пиров. Прогулка ниже ведёт от четырёх значений, которые выдал пул, до доли, которую пул действительно зачёл, и не трогает остальные службы хоста. Каждый шаг даёт ответ, который можно сравнить, а не впечатление.

Начните с конечной точки, которую пул действительно выдал

Пул даёт вам четыре значения, образующие весь контракт: имя хоста или адрес, порт, вариант протокола и строку аккаунта. Возьмите их с панели пула или из приветственного сообщения, а не из руководства для другого пула. Для той же услуги существуют региональные шарды, поэтому имя хоста, скопированное из старого руководства, всё ещё может подключиться и всё ещё зачислить аккаунт, который вы никогда не хотели использовать. Скопируйте четыре значения дословно в конфигурацию майнера, потому что перепечатанная строка аккаунта теряет разделитель.

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

Если одна машина действительно делает и то и другое, относитесь к каждой роли как к отдельной службе с собственным решением о доступе. Слушатель узла относится за политику, которую вы применяете к публичным службам, а сессия майнера относится к исходящей политике, выбирающей туннель. Запишите, какую роль играет хост, и убирайте правила другой роли, когда это меняется, потому что оставленное разрешающее правило переживает свою причину.

Докажите, что пул получил работу

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

Понаблюдайте за одной попыткой соединения с подробным логированием и отметьте последний этап, который удался. Этап, на котором последовательность останавливается, полезнее любого отдельного сообщения вокруг него:

Затем дайте клиенту поработать фиксированное окно и посчитайте оба исхода из его лога. Одного grep на счётчик достаточно, и сравнение их в одном окне отделяет медленный пул от сломанного пути. Настройте путь туда, куда пишет клиент, поскольку два подсчёта не зависят от расположения:

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

Если правило запрещает прямое соединение с пулом всякий раз, когда туннель падает, выразите его как явную блокировку конечной точки пула. Клиент, который тихо повторяет попытку через физическое соединение, продолжит майнить и продолжит нарушать это правило, а его дисплей состояния об этом не упомянет. Проверьте правило, намеренно уронив туннель и подтвердив, что порт пула вообще недоступен.