Nema dolaznih peerova na vašem Bitcoin čvoru iza VPN-a?

Odlazni peerovi i sinkronizirani lanac ne dokazuju dolaznu dostupnost. Provjerite mapiranje, listener i inbound zastavicu prije nego što okrivite VPN.

Vaš čvor je sinhroniziran, VPN prijavljuje vezu, a getpeerinfo prikazuje osam ili deset peerova. Nijedan od njih nema inbound postavljeno na true. Ta kombinacija je normalna i nije kvar: odlazne veze dokazuju da čvor može doći do drugih, a ništa u vezi s njima ne dokazuje da neko može doći do vas. Ako je cilj čvor koji prihvata dolazne P2P veze kroz VPN, taj smjer morate testirati zasebno.

Pratite paket od peera do svog listenera

Dolazni P2P je lanac od četiri stvari i puca na najslabijoj karici, a ne na najzanimljivijoj.

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

Zadani P2P port Corea na glavnoj mreži je 8333, ali vam provajder može dati drugi javni port i drugu odredišnu točku na strani klijenta. Zapišite javnu adresu, vanjski port i mjesto na koje provajder zapravo dostavlja promet. Zatim potvrdite da vaš plan i račun uopće dopuštaju dolazne veze, jer namjenska izlazna adresa nije ugovor o prosljeđivanju portova.

Ta razlika hvata ljude koji kupuju statičnu IP adresu očekujući dostupnost. To što je adresa stabilna ne govori ništa o tome prosljeđuje li provajder dolazni port na vašu sesiju.

Provjerite listener prije nego provajdera

Core mora slušati na adresi i portu na koje mapiranje dostavlja, a host firewall to mora dopuštati. Ako čvor radi u kontejneru ili na drugom računalu u LAN-u, sljedeći skok i njegova povratna ruta također pripadaju lancu.

Lokalno pravilo firewalla ne može stvoriti mapiranje kod provajdera koji odbacuje dolazne pakete, a mapiranje provajdera ne može doći do procesa vezanog samo za loopback. Obje strane moraju se složiti oko iste tuple, zato je prvi korak zapisati tuple, a ne nagađati o njemu.

Držite objavljeni endpoint usklađen sa stvarnim mapiranjem. Statična adresa ne čini dodijeljeni port ni njegov zakup trajnim kroz ponovne veze, pa endpoint objavljen prije nekoliko mjeseci sada možda ne pokazuje ni na što. Ponovno pročitajte stranicu provajdera nakon svake ponovne veze i uporedite je s onim što vaš čvor objavljuje. Ako se port premjestio, stari endpoint sada ili nije ničiji ili je nečiji drugi.

Čitajte inbound zastavicu, ne ukupan broj veza

Iz ovlaštenog lokalnog RPC konteksta ovaj upit samo za čitanje navodi peerove:

bitcoin-cli getpeerinfo

RPC referenca inbound definira kao true za dolaznu vezu i false za odlaznu. Pogledajte to polje. Ukupan broj iznad deset ne dokazuje ništa o smjeru, a ukupni brojevi i kategorije se ionako mijenjaju s konfiguracijom i izdanjem.

Zatim testirajte mapirani endpoint izvana novom provjerom dostupnosti za koju imate ovlaštenje i pogledajte pojavljuje li se odgovarajući dolazni peer. Pazite s izlazom koji lijepite u temu podrške: adrese peerova su podaci o vezama drugih ljudi i ne treba ih objavljivati da bi vam se odgovorilo.

Ne rješavajte to izlaganjem RPC-a

RPC dokumentacija Bitcoin Corea izričito upozorava na izlaganje RPC sučelja javnom internetu. Veze s peerovima i autentificirana administracija različite su usluge, a činjenje P2P dostupnim objavljivanjem RPC-a mijenja problem povezivosti za mnogo gori.

Ako ne želite uopće ovisiti o dolaznom P2P-u, dokumentirana alternativa je onion usluga i ona ima svoje preduvjete: dostupan Tor, konfiguriranu autentifikaciju upravljanja i postavke slušanja koje dopuštaju stvaranje usluge. Ne pojavljuje se samo zato što VPN radi.

Isključivanje Corea iz VPN-a treći je dizajn i za neke je operatere legitiman, ali stavlja promet peerova na vašu običnu vezu. To nije dolazni pristup kroz VPN, a router ili upstream NAT još uvijek može trebati vlastiti dopušteni unos. Odaberite koji od tri stvarno testirate prije nego što promijenite bilo što drugo.

Povezani članci