მაინინგ-პულის VPN: სესია სწორ გზაზე შეინარჩუნე
პულის მაინერი ხსნის ერთ გამავალ Stratum სესიას, არა peer პორტს. მოათავსე გვირაბი ამ პროცესის ქვეშ და წაიკითხე მარშრუტი და გადამწყვეტი მისი სახელების სივრციდან.
მაინინგ პროგრამა ერთ სოკეტს ერთ მისამართზე ღიად ინახავს და გვირაბის, მარშრუტისა და დაკრედიტებული სამუშაოს შესახებ ყველა კითხვა ამ სოკეტზეა დამოკიდებული. ეს სოკეტი პულის საბოლოო წერტილისკენ გამავალი კლიენტის სესიაა და არა მსმენელი, რომელიც 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 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თუ წესი კრძალავს პულთან პირდაპირ კავშირს ყოველ ჯერზე, როცა გვირაბი ვარდება, გამოხატე ის როგორც მკაფიო ბლოკი პულის საბოლოო წერტილზე. კლიენტი, რომელიც ჩუმად ცდილობს ხელახლა ფიზიკური რგოლით, გააგრძელებს მაინინგს და გააგრძელებს ამ წესის დარღვევას, და მისი სტატუსის ეკრანი ამას არ იტყვის. გამოსცადე წესი გვირაბის განზრახ ჩამოშლით და იმის დადასტურებით, რომ პულის პორტამდე საერთოდ ვერ მიხვდები.