Таны зангилаа синхрончлогдсон, VPN холбогдсон гэж мэдээлж байна, мөн getpeerinfo найм эсвэл арван peer харуулж байна. Тэдний алинд нь ч inbound true гэж тохируулагдаагүй. Энэ хослол хэвийн бөгөөд гэмтэл биш: гарч буй холболтууд зангилаа бусдад хүрч чадна гэдгийг нотолдог бөгөөд тэдгээрт хэн нэгэн танд хүрч чадна гэдгийг юу ч нотлохгүй. Хэрэв зорилго нь VPN-ээр дамжуулан ирж буй P2P холболтыг хүлээн авдаг зангилаа бол энэ чиглэлийг тусад нь шалгах ёстой.

Пакетыг peer-ээс өөрийн сонсогч хүртэл дагаарай

Ирж буй P2P нь дөрвөн зүйлийн хэлхээ бөгөөд энэ нь хамгийн сонирхолтой холбоос дээр биш, хамгийн сул холбоос дээр тасардаг.

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

Үндсэн сүлжээ дэх Core-ийн P2P анхдагч нь 8333 боловч үйлчилгээ үзүүлэгч танд өөр нийтийн порт, харилцагчийн талд өөр очих газрыг өгч болно. Нийтийн хаяг, гадаад порт болон үйлчилгээ үзүүлэгч трафикийг бодитоор хаана хүргэдэг газрыг бичиж аваарай. Дараа нь таны багц, бүртгэл ирж буй холболтыг ер нь зөвшөөрдөг эсэхийг баталгаажуулаарай, учир нь тусгай гарцын хаяг нь порт дамжуулах гэрээ биш.

Энэ ялгаа нь хүртээмж хүлээж статик IP худалдаж авдаг хүмүүсийг барьдаг. Хаяг тогтвортой байх нь үйлчилгээ үзүүлэгч ирж буй портыг таны сесс рүү дамжуулж байгаа эсэх талаар юу ч хэлэхгүй.

Үйлчилгээ үзүүлэгчийг шалгахаас өмнө сонсогчийг шалгаарай

Core нь зураглал хүргэдэг хаяг, порт дээр сонсож байх ёстой бөгөөд хост firewall үүнийг зөвшөөрөх ёстой. Хэрэв зангилаа контейнерт эсвэл LAN-ийн өөр машинд ажиллаж байгаа бол дараагийн үсрэлт болон түүний хариу маршрут ч хэлхээнд багтана.

Ирж буй пакетыг хаядаг үйлчилгээ үзүүлэгчийн дээр локал firewall дүрэм зураглал үүсгэж чадахгүй, үйлчилгээ үзүүлэгчийн зураглал нь зөвхөн loopback-т холбогдсон процесс руу хүрч чадахгүй. Хоёр тал нэг ижил tuple дээр санал нийлэх ёстой, тиймээс эхний алхам нь tuple-ийг таамаглах биш, бичиж авах юм.

Зарлагдсан endpoint-ийг бодит зураглалтай нийцүүлэн байлгаарай. Статик хаяг нь олгогдсон порт эсвэл түүний түрээсийг дахин холбогдох үед байнгын болгодоггүй, тиймээс сарын өмнө нийтэлсэн endpoint одоо юу ч заахгүй байж болно. Дахин холбогдсон бүрийн дараа үйлчилгээ үзүүлэгчийн хуудсыг дахин уншиж, зангилааны зарлаж буйтай харьцуулаарай. Хэрэв порт шилжсэн бол хуучин endpoint одоо эсвэл хэний ч биш, эсвэл өөр хэн нэгнийх.

Ирж буй төрийг уншаарай, холболтын нийт тоог биш

Эрх бүхий локал RPC контекстээс энэ зөвхөн-унших асуулга peer-үүдийг жагсаана:

bitcoin-cli getpeerinfo

RPC лавлах inbound-ийг ирж буй холболтод true, гарч буй холболтод false гэж тодорхойлдог. Тэр талбарыг хараарай. Араваас дээш нийт тоо чиглэлийн талаар юу ч нотлохгүй, нийт тоо болон ангилал нь тохиргоо, хувилбартайгаа хамт өөрчлөгддөг.

Дараа нь зурагласан endpoint-ийг гаднаас, өөрт тань ажиллуулах эрх бүхий шинэ хүртээмжийн шалгалтаар туршиж, тохирох ирж буй peer гарч ирэх эсэхийг хараарай. Дэмжлэгийн thread-д буулгаж буй гаралтын талаар болгоомжтой байгаарай: peer-ийн хаягууд нь бусдын холболтын мэдээлэл бөгөөд асуултад тань хариу авахын тулд тэдгээрийг нийтлэх шаардлагагүй.

RPC-ийг ил гаргаж үүнийг бүү шийд

Bitcoin Core-ийн RPC баримт бичиг нь RPC интерфейсийг нийтийн интернетэд ил гаргахыг тодорхой анхааруулдаг. Peer-тэй холболт болон нэвтрүүлэлттэй удирдлага нь өөр үйлчилгээ бөгөөд P2P-ийг RPC нийтлэх замаар хүртээмжтэй болгох нь холболтын асуудлыг хамаагүй дор асуудлаар солилцдог.

Хэрэв та ирж буй P2P-ээс огт хамааралгүй байхыг хүсвэл, баримтжуулсан хувилбар нь onion үйлчилгээ бөгөөд өөрийн урьдчилсан нөхцөлтэй: Tor байгаа, хяналтын нэвтрүүлэлт тохируулагдсан, үйлчилгээг үүсгэхийг зөвшөөрдөг сонсох тохиргоо. VPN ажиллаж байгаа учраас л тэр гарч ирдэггүй.

Core-ийг VPN-ээс хасах нь гурав дахь загвар бөгөөд зарим операторт хууль ёсны, гэхдээ peer-ийн трафикийг таны энгийн холболт дээр тавьдаг. Энэ нь VPN-ээр дамжуулан ирж буй нэвтрэлт биш бөгөөд чиглүүлэгч эсвэл дээд NAT-д өөрийн зөвшөөрөгдсөн бичлэг хэрэгтэй хэвээр байж болно. Өөр юу ч өөрчлөхөөс өмнө гурвын алийг нь үнэхээр шалгаж байгаагаа сонгоорой.

Холбоотой нийтлэлүүд