Майнінгавы пул праз 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

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