Jūsų Bitcoin mazge už VPN nėra įeinančių peer'ų?

Jūsų mazgas sinchronizuotas, VPN praneša apie ryšį, o getpeerinfo rodo aštuonis ar dešimt peer'ų. Nė vienas jų neturi inbound nustatyto į true. Toks derinys yra normalus ir tai ne gedimas: išeinantys ryšiai įrodo, kad mazgas gali pasiekti kitus, ir niekas juose neįrodo, kad kas nors gali pasiekti jus. Jei tikslas yra mazgas, priimantis įeinančius P2P ryšius per VPN, šią kryptį reikia tikrinti atskirai.

Sekite paketą nuo peer'o iki savo klausytuvo

Įeinantis P2P yra keturių dalykų grandinė, ir ji trūksta silpniausioje grandyje, o ne įdomiausioje.

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

Core P2P numatytoji reikšmė pagrindiniame tinkle yra 8333, tačiau teikėjas gali duoti kitą viešą prievadą ir kitą paskirties tašką kliento pusėje. Užsirašykite viešą adresą, išorinį prievadą ir vietą, kur teikėjas iš tikrųjų pristato srautą. Tada patvirtinkite, kad jūsų planas ir paskyra apskritai leidžia įeinančius ryšius, nes skirtasis išėjimo adresas nėra prievadų persiuntimo sutartis.

Šis skirtumas pagauna tuos, kurie perka statinį IP tikėdamiesi pasiekiamumo. Tai, kad adresas stabilus, nieko nesako apie tai, ar teikėjas persiunčia įeinantį prievadą į jūsų sesiją.

Pirmiau patikrinkite klausytuvą, o ne teikėją

Core turi klausytis adreso ir prievado, į kuriuos pristato susiejimas, o pagrindinio kompiuterio užkarda turi tai leisti. Jei mazgas veikia konteineryje ar kitame LAN kompiuteryje, tolesnis šuolis ir jo atsakymo maršrutas taip pat priklauso grandinei.

Vietinė užkardos taisyklė negali sukurti susiejimo pas teikėją, kuris meta įeinančius paketus, o teikėjo susiejimas negali pasiekti proceso, susieto tik su loopback. Abi pusės turi sutarti dėl to paties kortežo, todėl pirmas žingsnis yra kortežą užrašyti, o ne jį spėlioti.

Laikykite skelbiamą galinį tašką suderintą su veikiančiu susiejimu. Statinis adresas nepadaro priskirto prievado ar jo nuomos nuolatiniu per prisijungimus iš naujo, todėl prieš mėnesius paskelbtas galinis taškas dabar gali nieko nerodyti. Perskaitykite teikėjo puslapį po kiekvieno prisijungimo iš naujo ir palyginkite jį su tuo, ką skelbia jūsų mazgas. Jei prievadas pasikeitė, senasis galinis taškas dabar yra arba niekieno, arba kažkieno kito.

Skaitykite įėjimo žymę, o ne bendrą ryšių skaičių

Iš įgalioto vietinio RPC konteksto ši tik skaitymo užklausa išvardija peer'us:

bitcoin-cli getpeerinfo

RPC žinynas inbound kaip true įeinančiam ryšiui ir false išeinančiam. Pažiūrėkite į tą lauką. Bendra suma virš dešimt nieko neįrodo apie kryptį, o sumos ir kategorijos ir taip kinta su konfigūracija bei versija.

Tada išbandykite susietą galinį tašką iš išorės nauju pasiekiamumo patikrinimu, kurį turite teisę vykdyti, ir pažiūrėkite, ar atsiranda atitinkamas įeinantis peer'as. Būkite atsargūs su išvestimi, kurią įklijuojate į palaikymo giją: peer'ų adresai yra kitų žmonių ryšio duomenys, ir jų nereikia skelbti, kad į jūsų klausimą būtų atsakyta.

Nespręskite to atskleisdami RPC

Bitcoin Core RPC dokumentacija aiškiai įspėja neatskleisti RPC sąsajos viešajame internete. Ryšiai su peer'ais ir autentifikuotas administravimas yra skirtingos paslaugos, o P2P pasiekiamumo užtikrinimas skelbiant RPC iškeičia ryšio problemą į kur kas blogesnę.

Jei verčiau visai nepriklausytumėte nuo įeinančio P2P, dokumentuota alternatyva yra onion paslauga, ir ji turi savo prielaidas: prieinamas Tor, sukonfigūruotas valdymo autentifikavimas ir klausymosi nustatymai, leidžiantys sukurti paslaugą. Ji neatsiranda vien todėl, kad atsitiktinai veikia VPN.

Core išskyrimas iš VPN yra trečiasis sprendimas ir kai kuriems operatoriams teisėtas, tačiau jis perkelia peer'ų srautą į jūsų įprastą ryšį. Tai nėra įeinanti prieiga per VPN, o maršrutizatoriui ar viršutiniam NAT vis tiek gali prireikti savo leidžiamo įrašo. Nuspręskite, kurią iš trijų iš tikrųjų tikrinate, prieš keisdami ką nors kita.