Минен пул през VPN: задръжте сесията на правилния път

Минният софтуер държи един сокет отворен към един адрес и всеки въпрос за тунела, маршрута и кредитираната работа виси на този сокет. Този сокет е изходяща клиентска сесия към крайна точка на пула, а не слушател, който приема peer-и. Разходката по-долу го проследява от четирите стойности, които пулът е издал, до дял, който пулът наистина е осчетоводил, и оставя другите услуги на хоста на мира. Всяка стъпка дава отговор, който можете да сравните, а не впечатление.

Започнете от крайната точка, която пулът наистина е издал

Пулът ви дава четири стойности, които образуват целия договор: име на хост или адрес, порт, вариант на протокола и низ за акаунт. Вземете ги от таблото на пула или от приветственото съобщение, не от урок за друг пул. За същата услуга има регионални шардове, така че име на хост, копирано от стар наръчник, все още може да се свърже и все още да кредитира акаунт, който никога не сте искали да използвате. Копирайте четирите стойности дословно в конфигурацията на миньора, защото преписан низ за акаунт губи разделител.

Потокът, който рутирате, е този, който ръководството за разработчици на Bitcoin нарича Stratum сесия: постоянна двупосочна TCP връзка, в която пулът разпределя работа, а миньорът връща дялове. Това не е същият поток като peer връзките на пълен възел или синхронизацията на веригата на портфейл, и именно сгъването им в един трафичен клас е мястото, където започва по-голямата част от объркването. Само първият принадлежи под тази политика.

Където пулът предлага TLS, запазете проверката на сървъра, която документацията му изисква. Тунелът криптира хопа от вашата машина до VPN сървъра и свършва там; той не гарантира за този, който отговаря от другата страна. Запазете и двете проверки, по една във всеки край, ако искате сесията да преживее компрометиран изход.

Прикрепете тунела към процеса, а не към домакинството

Две точки на прикрепяне работят: пуснете VPN клиента в мрежовия namespace, който миньорът използва, или дайте на този namespace шлюз, който носи трафика му в тунела. И двете подредби поставят сесията на пътя, преди пулът да я види. Обичайният провал е клиент на хоста, миньор в контейнер със собствен мост и маршрут на хоста, който контейнерът никога не пита. Прозорецът на клиента изглежда здрав, докато пулът записва домашния ви адрес.

Проверете собствения транспорт на тунела, преди да ограничавате каквото и да е. Клиентът трябва да стигне до сървъра си през подложката, така че политика, която прихваща всеки пакет, прихваща и пакетите, които биха изградили тунела. Тогава тунелът не може да стартира и нищо друго също не излиза. Изберете с функцията за разделен тунел на клиента какво влиза в тунела; ръчното редактиране на маршрути по подразбиране е начинът, по който подложката изчезва.

След като политиката е на място, прочетете таблицата със сокети в namespace-а, на който принадлежи миньорът. Потокът към порта на пула трябва да седи на интерфейса на тунела, и две команди отговарят на този въпрос. Портът по-долу е пример; заменете го с този, който пулът е издал.

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

Четете маршрут и резолвер от собствения контекст на миньора

Рутирането и разрешаването на имена са за всеки namespace, така че проверка, пусната в обикновен shell, описва грешната машина, когато миньорът е в контейнер. Влезте първо в namespace-а и после питайте кой интерфейс би пренесъл пакет до адреса на пула и кой резолвер би отговорил за името му на хост. Отговорите на хоста не се прехвърлят и разликата между тях е чест източник на погрешно насочена вина.

Наименувайте интерфейса, който получавате: тунелът означава, че сесията е на предвидения път, докато физическата връзка означава, че правило е съвпаднало по-рано, отколкото сте очаквали. Дължината на префикса решава първа, после метриката, после правилата на политиката, така че таблица с няколко подразбиращи се записа не дублира пакети, просто губи.

Резолверите се провалят отделно от маршрутите. Тунел, който преписва /etc/resolv.conf, може да остави namespace-а да сочи към резолвер, достъпен само от вътрешността на тунела, което се проваля преди какъвто и да е TCP handshake. Разрешете името на хоста на пула вътре в namespace-а и го сравнете с публикувания адрес. Ако заявката изтече или върне нещо друго, поправете разрешаването, преди да пипате маршрутите.

Дръжте отделно клиента на пула и слушателя на възела

Порт 8333 е peer портът на Bitcoin Core, където пълен възел слуша за входящи връзки; пул миньор никога не се нуждае от него отворен и отварянето му не поправя изходяща повреда. Входящите слушатели и изходящите сесии са противоположни роли с противоположни предположения за доверие. Нищо в конфигурацията на миньор не обвързва този порт, така че затворен порт не може да обясни никаква грешка, която той докладва. Съвет, писан за достъпността на възел, може следователно да остави публична услуга работеща на хост, който е трябвало само да изпраща дялове.

Ако една машина наистина прави и двете, третирайте всяка роля като отделна услуга със собствено решение за достъп. Слушателят на възела принадлежи зад политиката, която прилагате към публични услуги, а сесията на миньора принадлежи на изходящата политика, която избира тунела. Отбележете каква роля играе хостът и премахнете правилата на другата роля, когато това се промени, защото останало разрешаващо правило надживява причината си.

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

Зает вентилатор и растящ hashrate показват, че миньорът изчислява, а не че нещо е стигнало до пула. Доказателството е в броячите за изпращане на клиента или на таблото на пула: приети дялове, отхвърлени дялове и причината, прикачена към всяко отхвърляне. Тези числа разделят три повреди, които отвън изглеждат еднакво: няма сесия, сесия без кредит и сесия, която постоянно се свързва наново. Прочетете ги, преди да промените каквато и да е конфигурация.

Наблюдавайте един опит за свързване с подробно логване и отбележете последния етап, който е успял. Етапът, на който последователността спира, е по-полезен от всяко отделно съобщение около него:

След това оставете клиента да работи фиксиран прозорец и пребройте двата изхода от лога му. Един grep на брояч е достатъчен и сравняването им в същия прозорец отделя бавен пул от счупен път. Нагласете пътя към мястото, където пише клиентът ви, тъй като двете бройки не зависят от локацията:

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

Ако правило забранява директна връзка с пула всеки път, когато тунелът падне, изразете го като явно блокиране на крайната точка на пула. Клиент, който тихо опитва отново през физическата връзка, ще продължи да копае и ще продължи да нарушава това правило, а дисплеят му за състояние няма да го спомене. Тествайте правилото, като пуснете тунела нарочно и потвърдите, че портът на пула не е достъпен изобщо.