Ingen indgående peers på din Bitcoin-node bag en VPN?

Din node er synkroniseret, VPN'en siger forbundet, og getpeerinfo viser otte eller ti peers. Ingen af dem har inbound sat til true. Den kombination er normal og er ikke en fejl: udgående forbindelser beviser, at noden kan nå andre, og intet ved dem beviser, at nogen kan nå dig. Hvis målet er en node, der accepterer indgående P2P-forbindelser gennem en VPN, skal du teste den retning for sig selv.

Følg pakken fra peer'en til din listener

Indgående P2P er en kæde af fire ting, og den fejler ved det svageste led frem for det mest interessante.

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

Cores P2P-standard på mainnet er 8333, men udbyderen kan give dig en anden offentlig port og en anden destination på klientsiden. Skriv den offentlige adresse, den eksterne port og det sted, hvor udbyderen faktisk leverer trafikken, ned. Bekræft derefter, at din plan og konto overhovedet tillader indgående forbindelser, for en dedikeret udgangsadresse er ikke en portforwarding-kontrakt.

Den forskel fanger folk, der køber en statisk IP i forventning om tilgængelighed. At adressen er stabil, siger intet om, hvorvidt udbyderen videresender en indgående port til din session.

Kontroller listeneren, før du kontrollerer udbyderen

Core skal lytte på den adresse og port, som mappingen leverer til, og værtens firewall skal tillade det. Hvis noden kører i en container eller på en anden maskine i LAN'et, hører det næste hop og dets svar-rute også med i kæden.

En lokal firewall-regel kan ikke oprette en mapping hos en udbyder, der dropper indgående pakker, og en udbyder-mapping kan ikke nå en proces, der kun er bundet til loopback. Begge halvdele skal enes om den samme tuple, og derfor er det første skridt at skrive tuple'en ned i stedet for at gætte på den.

Hold det annoncerede endpoint i overensstemmelse med den aktuelle mapping. En statisk adresse gør ikke en tildelt port eller dens leje permanent gennem genopkoblinger, så et endpoint, der blev offentliggjort for måneder siden, peger måske nu på ingenting. Læs udbyderens side igen efter enhver genopkobling, og sammenlign den med det, din node annoncerer. Hvis porten er flyttet, er det gamle endpoint nu enten ingens eller en andens.

Læs inbound-flaget, ikke det samlede antal forbindelser

Fra en autoriseret lokal RPC-kontekst lister denne skrivebeskyttede forespørgsel peers:

bitcoin-cli getpeerinfo

RPC-referencen inbound som true for en indgående forbindelse og false for en udgående. Se på det felt. Et samlet antal over ti beviser intet om retningen, og totalerne og kategorierne ændrer sig alligevel med konfiguration og version.

Test derefter det mappede endpoint udefra med et nyt tilgængelighedstjek, som du har tilladelse til at køre, og se, om en tilsvarende indgående peer dukker op. Vær forsigtig med det output, du indsætter i en supporttråd: peer-adresser er andre folks forbindelsesoplysninger, og de behøver ikke blive offentliggjort, for at dit spørgsmål kan besvares.

Løs det ikke ved at eksponere RPC

Bitcoin Cores RPC-dokumentation advarer udtrykkeligt mod at eksponere RPC-grænsefladen mod det offentlige internet. Peer-forbindelser og autentificeret administration er forskellige tjenester, og at gøre P2P tilgængelig ved at offentliggøre RPC bytter et forbindelsesproblem for et meget værre.

Hvis du hellere vil undgå at afhænge af indgående P2P helt, er en onion-tjeneste det dokumenterede alternativ, og den har sine egne forudsætninger: Tor tilgængelig, kontrolautentificering konfigureret og lytteindstillinger, der tillader, at tjenesten oprettes. Den dukker ikke op, bare fordi en VPN tilfældigvis kører.

At udelukke Core fra VPN'en er et tredje design og et legitimt et for nogle operatører, men det lægger peer-trafikken på din almindelige forbindelse. Det er ikke indgående adgang gennem VPN'en, og en router eller upstream NAT kan stadig have brug for sin egen tilladte post. Vælg, hvilket af de tre du faktisk tester, før du ændrer noget andet.