Մայնինգ-փուլը VPN-ով. սեսիան ճիշտ ուղու վրա պահել
Փուլի մայները բացում է մեկ ելքային Stratum սեսիա, ոչ թե peer պորտ։ Տեղադրեք թունելը այդ պրոցեսի տակ և կարդացեք երթուղին ու լուծիչը նրա անունների տարածությունից։
Մայնինգ ծրագիրը մեկ սոկետ բաց է պահում մեկ հասցեի ուղղությամբ, և թունելի, երթուղու ու հաշվառված աշխատանքի մասին յուրաքանչյուր հարց կախված է այդ սոկետից։ Այդ սոկետը փուլի վերջնակետ ուղղվող ելքային հաճախորդի սեսիա է, ոչ թե listener, որը 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Կարդացեք երթուղին և լուծիչը մայների սեփական համատեքստից
Երթուղավորումը և անունների լուծումը յուրաքանչյուր անունների տարածության համար են, ուստի սովորական shell-ում գործարկված ստուգումը նկարագրում է սխալ մեքենան, երբ մայները կոնտեյներում է։ Նախ մտեք անունների տարածություն, ապա հարցրեք, թե որ ինտերֆեյսը փաթեթը կտաներ փուլի հասցեին և որ լուծիչը կպատասխաներ նրա հոսթի անվանը։ Հոսթի պատասխանները չեն փոխանցվում, և նրանց միջև եղած բացը սխալ տեղ դրված մեղքի սովորական աղբյուր է։
Անվանեք ստացված ինտերֆեյսը. թունելը նշանակում է, որ սեսիան նախատեսված ուղու վրա է, մինչդեռ ֆիզիկական կապը նշանակում է, որ կանոնը համընկել է ավելի շուտ, քան սպասում էիք։ Նախածանցի երկարությունը որոշում է առաջինը, ապա մետրիկան, ապա քաղաքականության կանոնները, ուստի մի քանի լռելյայն գրառում ունեցող աղյուսակը փաթեթները չի կրկնապատկում, այն պարզապես տանուլ է տալիս։
Լուծիչները ձախողվում են առանձին երթուղիներից։ Թունելը, որը վերագրանցում է /etc/resolv.conf-ը, կարող է անունների տարածությունը թողնել ցույց տալով լուծիչի, որը հասանելի է միայն թունելի ներսից, ինչը ձախողվում է նախքան որևէ TCP ձեռքսեղմում տեղի ունենալը։ Լուծեք փուլի հոսթի անունը անունների տարածության ներսում և համեմատեք հրապարակված հասցեի հետ։ Եթե որոնումը ժամկետանց է կամ այլ բան է վերադարձնում, ուղղեք լուծումը նախքան երթուղիներին դիպչելը։
Առանձին պահեք փուլի հաճախորդը և հանգույցի լսողը
Պորտ 8333-ը Bitcoin Core-ի peer պորտն է, որտեղ լիարժեք հանգույցը լսում է մուտքային կապերը, փուլի մայներին այն երբեք բաց պետք չէ, և դրա բացումը չի վերանորոգում ելքային խափանումը։ Մուտքային լսողները և ելքային սեսիաները հակադիր դերեր են հակադիր վստահության ենթադրություններով։ Մայների կոնֆիգուրացիայում ոչինչ չի կապում այդ պորտը, ուստի փակ պորտը չի կարող բացատրել ոչ մի սխալ, որը նա հաղորդում է։ Հանգույցի հասանելիության համար գրված խորհուրդը կարող է այդպիսով հանրային ծառայություն թողնել աշխատելիս հոսթի վրա, որը պետք է միայն բաժիններ ուղարկեր։
Եթե մեկ մեքենա իրոք անում է երկուսն էլ, վերաբերվեք յուրաքանչյուր դերին որպես իր սեփական ծառայության՝ իր սեփական մուտքի որոշմամբ։ Հանգույցի լսողը պատկանում է հանրային ծառայությունների վրա կիրառվող քաղաքականության հետևում, իսկ մայների սեսիան պատկանում է ելքային քաղաքականությանը, որը ընտրում է թունելը։ Գրանցեք, թե ինչ դեր է խաղում հոսթը, և հեռացրեք մյուս դերի կանոնները, երբ դա փոխվում է, քանի որ մնացած թույլատրող կանոնը ապրում է իր պատճառից ավելի երկար։
Ապացուցեք, որ փուլը ստացել է աշխատանքը
Զբաղված օդափոխիչը և աճող hashrate-ը ցույց են տալիս, որ մայները հաշվարկում է, ոչ թե որ ինչ-որ բան հասել է փուլին։ Ապացույցը հաճախորդի ուղարկման հաշվիչներում է կամ փուլի վահանակում՝ ընդունված բաժիններ, մերժված բաժիններ և յուրաքանչյուր մերժմանը կցված պատճառը։ Այդ թվերը բաժանում են երեք խափանում, որոնք դրսից նույնն են երևում. սեսիա չկա, սեսիա առանց կրեդիտի և սեսիա, որն անընդհատ նորից միանում է։ Կարդացեք դրանք նախքան որևէ կոնֆիգուրացիա փոխելը։
Դիտեք մեկ կապի փորձ մանրամասն լոգավորմամբ և նշեք հաջողված վերջին փուլը, և այն փուլը, որտեղ հաջորդականությունը կանգ է առնում, ավելի օգտակար է, քան շուրջը եղած ցանկացած առանձին հաղորդագրությունը։
| 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Եթե կանոնը արգելում է ուղիղ կապը փուլի հետ ամեն անգամ, երբ թունելն ընկնում է, արտահայտեք այն որպես հստակ արգելափակում փուլի վերջնակետի վրա։ Հաճախորդը, որը լուռ նորից փորձում է ֆիզիկական կապով, կշարունակի մայնինգ անել և կշարունակի խախտել այդ կանոնը, և նրա կարգավիճակի էկրանը դա չի հիշատակի։ Փորձարկեք կանոնը թունելը դիտավորյալ գցելով և հաստատելով, որ փուլի պորտին ընդհանրապես հնարավոր չէ հասնել։