VPN-ის უკან მყოფ თქვენს Bitcoin კვანძზე შემომავალი peer-ები არ არის?

გამავალი peer-ები და სინქრონიზებული ჯაჭვი შემომავალ ხელმისაწვდომობას არ ამტკიცებს. VPN-ის დადანაშაულებამდე შეამოწმეთ mapping-ი, listener-ი და inbound დროშა.

თქვენი კვანძი სინქრონიზებულია, VPN ამბობს, რომ დაკავშირებულია, და getpeerinfo აჩვენებს რვა ან ათ peer-ს. არც ერთ მათგანს არ აქვს inbound true-ზე დაყენებული. ეს კომბინაცია ნორმალურია და ხარვეზი არ არის: გამავალი კავშირები ამტკიცებს, რომ კვანძს შეუძლია სხვებამდე მიაღწიოს, და მათში არაფერი ამტკიცებს, რომ ვინმეს შეუძლია თქვენამდე მიაღწიოს. თუ მიზანია კვანძი, რომელიც VPN-ის მეშვეობით შემომავალ P2P კავშირებს იღებს, ეს მიმართულება ცალკე უნდა შეამოწმოთ.

მიჰყევით პაკეტს peer-იდან თქვენს listener-ამდე

შემომავალი P2P ოთხი რამის ჯაჭვია და ის ყველაზე სუსტ რგოლზე წყდება, არა ყველაზე საინტერესოზე.

other peer
  -> provider's public address and assigned port
  -> the permitted VPN mapping
  -> Bitcoin Core's P2P listener

Core-ის P2P ნაგულისხმევი მთავარ ქსელში 8333-ია, მაგრამ პროვაიდერმა შეიძლება მოგცეთ სხვა საჯარო პორტი და სხვა დანიშნულება კლიენტის მხარეს. ჩაწერეთ საჯარო მისამართი, გარე პორტი და ადგილი, სადაც პროვაიდერი ტრაფიკს რეალურად აწვდის. შემდეგ დაადასტურეთ, რომ თქვენი გეგმა და ანგარიში საერთოდ უშვებს შემომავალ კავშირებს, რადგან გამოყოფილი გასასვლელი მისამართი პორტის გადამისამართების ხელშეკრულება არ არის.

ეს განსხვავება იჭერს მათ, ვინც სტატიკურ IP-ს ყიდულობს ხელმისაწვდომობის იმედით. მისამართის სტაბილურობა არაფერს ამბობს იმაზე, გადასცემს თუ არა პროვაიდერი შემომავალ პორტს თქვენს სესიაზე.

listener-ი შეამოწმეთ პროვაიდერამდე

Core-მა უნდა მოუსმინოს იმ მისამართსა და პორტს, სადაც mapping-ი აწვდის, და host-ის firewall-მა ეს უნდა დაუშვას. თუ კვანძი კონტეინერში ან LAN-ის სხვა მანქანაზე მუშაობს, შემდეგი ნახტომი და მისი პასუხის მარშრუტიც ჯაჭვში შედის.

ლოკალური firewall-ის წესი ვერ შექმნის mapping-ს იმ პროვაიდერთან, რომელიც შემომავალ პაკეტებს აგდებს, და პროვაიდერის mapping-ი ვერ მიაღწევს პროცესამდე, რომელიც მხოლოდ loopback-ზეა მიბმული. ორივე ნახევარმა ერთსა და იმავე tuple-ზე უნდა შეთანხმდეს, ამიტომ პირველი ნაბიჯი tuple-ის გამოცნობა კი არა, ჩაწერაა.

შეინარჩუნეთ გამოცხადებული endpoint-ი მოქმედ mapping-ის შესაბამისად. სტატიკური მისამართი გამოყოფილ პორტს ან მის იჯარას გადაერთებებს შორის მუდმივს არ ხდის, ამიტომ თვეების წინ გამოქვეყნებული endpoint-ი ახლა შეიძლება არაფერზე მიუთითებდეს. ყოველი გადაერთების შემდეგ ხელახლა წაიკითხეთ პროვაიდერის გვერდი და შეადარეთ იმას, რასაც თქვენი კვანძი აცხადებს. თუ პორტი გადაადგილდა, ძველი endpoint-ი ახლა ან არავისია, ან სხვისია.

წაიკითხეთ შემომავალი დროშა, და არა კავშირების საერთო რაოდენობა

უფლებამოსილი ლოკალური RPC კონტექსტიდან ეს მხოლოდ-წაკითხვის მოთხოვნა peer-ებს ჩამოთვლის:

bitcoin-cli getpeerinfo

RPC ცნობარი inbound განსაზღვრავს როგორც true შემომავალი კავშირისთვის და false გამავალი კავშირისთვის. შეხედეთ ამ ველს. ათზე მეტი ჯამი მიმართულებაზე არაფერს ამტკიცებს, და ჯამები და კატეგორიები კონფიგურაციასა და ვერსიასთან ერთად მაინც იცვლება.

შემდეგ გამოსცადეთ mapping-ით მიღებული endpoint-ი გარედან ახალი ხელმისაწვდომობის შემოწმებით, რომლის გაშვებაც ნებადართული გაქვთ, და ნახეთ, გამოჩნდება თუ არა შესაბამისი შემომავალი peer. ფრთხილად იყავით იმ გამოტანილ მონაცემებთან, რომელსაც მხარდაჭერის თემაში აკრავთ: peer-ების მისამართები სხვა ადამიანების კავშირის დეტალებია და მათი გამოქვეყნება არ არის საჭირო, რომ თქვენს კითხვას უპასუხონ.

ნუ მოაგვარებთ RPC-ის გამჟღავნებით

Bitcoin Core-ის RPC დოკუმენტაცია ცალსახად აფრთხილებს RPC ინტერფეისის საჯარო ინტერნეტში გამჟღავნების წინააღმდეგ. peer-ებთან კავშირები და აუთენტიფიცირებული ადმინისტრირება სხვადასხვა სერვისია, და P2P-ის ხელმისაწვდომობა RPC-ის გამოქვეყნებით კავშირის პრობლემას ბევრად უარესზე ცვლის.

თუ გირჩევნიათ საერთოდ არ იყოთ დამოკიდებული შემომავალ P2P-ზე, დოკუმენტირებული ალტერნატივა onion სერვისია და მას თავისი წინაპირობები აქვს: Tor ხელმისაწვდომი, კონტროლის აუთენტიფიკაცია კონფიგურირებული და მოსმენის პარამეტრები, რომლებიც სერვისის შექმნას უშვებს. ის მხოლოდ იმიტომ არ ჩნდება, რომ შემთხვევით VPN მუშაობს.

Core-ის VPN-იდან გამორიცხვა მესამე დიზაინია და ზოგიერთი ოპერატორისთვის ლეგიტიმური, მაგრამ peer-ების ტრაფიკს თქვენს ჩვეულებრივ კავშირზე აყენებს. ეს VPN-ის მეშვეობით შემომავალი წვდომა არ არის, და როუტერს ან ზედა NAT-ს შეიძლება მაინც დასჭირდეს საკუთარი დაშვებული ჩანაწერი. სამიდან რომელს ამოწმებთ სინამდვილეში, სხვა რამის შეცვლამდე გადაწყვიტეთ.

დაკავშირებული სტატიები