VPN артындагы Bitcoin түйүнүңүздө кирүүчү пирлер жокпу?

Түйүнүңүз синхрондуу, VPN туташканын билдирет, жана getpeerinfo сегиз же он пирди көрсөтөт. Алардын эч биринде inbound true маанисине коюлган эмес. Бул айкалыш кадимки жана бузулуу эмес: чыгуучу байланыштар түйүн башкаларга жете аларын далилдейт, жана алардагы эч нерсе бирөөнүн сизге жете аларын далилдебейт. Максат VPN аркылуу кирүүчү P2P байланыштарын кабыл алган түйүн болсо, бул багытты өзүнчө текшерүү керек.

Пакетти пирден өз угуучуңузга чейин көзөмөлдөңүз

Кирүүчү P2P — төрт нерсенин чынжыры, жана ал эң кызыктуу звенодо эмес, эң алсыз звенодо үзүлөт.

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

Core'дун негизги тармактагы P2P демейкиси 8333, бирок провайдер сизге башка публикалык порт жана кардар тарапта башка дарек бере алады. Публикалык даректи, сырткы портту жана провайдер трафикти чындыгында кайда жеткирерин жазып алыңыз. Андан кийин планыңыз менен эсебиңиз кирүүчү байланыштарга такыр уруксат берерин ырастаңыз, анткени өзүнчө чыгуу дареги портту багыттоо келишими эмес.

Бул айырма жеткиликтүүлүккө ишенип статикалык IP сатып алгандарды кармайт. Даректин туруктуулугу провайдердин кирүүчү портту сессияңызга багыттайбы же жокпу тууралуу эч нерсе айтпайды.

Провайдерди текшерүүдөн мурун угуучуну текшериңиз

Core карталоо жеткирген дарек менен портто угууга тийиш, жана хосттун файрволу муну уруксат кылышы керек. Эгер түйүн контейнерде же LAN'дын башка машинасында иштесе, кийинки секирик жана анын жооп маршруту да чынжырга кирет.

Жергиликтүү файрвол эрежеси кирүүчү пакеттерди ыргыткан провайдерде карталоо түзө албайт, ал эми провайдердин карталоосу loopback'ке гана байланган процесске жете албайт. Эки жарым бирдей tuple боюнча макулдашууга тийиш, ошондуктан биринчи кадам tuple'ду болжолдоо эмес, жазып алуу.

Жарыяланган endpoint'ти азыркы карталоого шайкеш кармаңыз. Статикалык дарек бөлүнгөн портту же анын ижарасын кайра туташуулар арасында туруктуу кылбайт, ошондуктан айлар мурун жарыяланган endpoint азыр эч нерсеге көрсөтпөшү мүмкүн. Ар бир кайра туташуудан кийин провайдердин баракчасын кайра окуп, түйүнүңүз жарыялаган нерсе менен салыштырыңыз. Эгер порт жылса, эски endpoint азыр же эч кимдики эмес, же башка бирөөнүкү.

Кирүүчү желекчени окуңуз, байланыштардын жалпы санын эмес

Ыйгарылган жергиликтүү RPC контекстен бул тек-окуу суроосу пирлерди тизмелейт:

bitcoin-cli getpeerinfo

RPC маалымдамасы inbound дегенди кирүүчү байланыш үчүн true, чыгуучу байланыш үчүн false деп аныктайт. Ошол талаага караңыз. Ондон ашкан жалпы сан багыт тууралуу эч нерсе далилдебейт, жана жалпы сандар менен категориялар конфигурация жана версия менен баары бир өзгөрөт.

Андан кийин карталанган endpoint'ти сырттан, өзүңүзгө уруксат берилген жаңы жеткиликтүүлүк текшерүүсү менен сынап, тиешелүү кирүүчү пир пайда болорун караңыз. Колдоо темасына чаптаган чыгарылыш менен этият болуңуз: пирлердин даректери башка адамдардын байланыш маалыматы жана сурооңузга жооп алуу үчүн аларды жарыялоонун кереги жок.

Муну RPC'ни ачык кылуу менен чечпеңиз

Bitcoin Core'дун RPC документтери RPC интерфейсин публикалык интернетке ачууга каршы ачык эскертет. Пирлер менен байланыштар жана аутентификацияланган башкаруу ар башка кызматтар, ал эми P2P'ни RPC жарыялоо менен жеткиликтүү кылуу байланыш маселесин андан да жаман маселеге алмаштырат.

Кирүүчү P2P'ге такыр көз каранды болгуңуз келбесе, документтелген альтернатива — onion кызматы, анын өз шарттары бар: Tor жеткиликтүү, башкаруунун аутентификациясы конфигурацияланган жана кызматты түзүүгө мүмкүндүк берген угуу параметрлери. Ал жөн гана VPN иштеп тургандыктан пайда болбойт.

Core'ду VPN'ден чыгаруу — үчүнчү долбоор жана айрым операторлор үчүн мыйзамдуу, бирок ал пирлердин трафигин кадимки байланышыңызга салат. Бул VPN аркылуу кирүүчү жеткиликтүүлүк эмес, жана маршрутизатор же жогорку NAT өзүнүн уруксат берилген жазуусун дагы эле талап кылышы мүмкүн. Башка нерсени өзгөртүүдөн мурун үчөөнүн кайсынысын чындап текшерип жатканыңызды тандаңыз.