Geen inkomende peers op je Bitcoinnode achter een VPN?

Je node is gesynchroniseerd, de VPN meldt verbonden, en getpeerinfo toont acht of tien peers. Geen enkele heeft inbound op true staan. Die combinatie is normaal en het is geen fout: uitgaande verbindingen bewijzen dat de node anderen kan bereiken, en niets eraan bewijst dat iemand jou kan bereiken. Als het doel een node is die inkomende P2P-verbindingen via een VPN accepteert, moet je die richting apart testen.

Volg het pakket van de peer naar je listener

Inkomende P2P is een keten van vier dingen, en hij breekt bij de zwakste schakel, niet bij de interessantste.

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

De P2P-standaard van Core op het mainnet is 8333, maar de provider kan je een andere openbare poort en een andere bestemming aan de clientzijde geven. Noteer het openbare adres, de externe poort en de plek waar de provider het verkeer daadwerkelijk aflevert. Bevestig daarna dat je abonnement en account inkomende verbindingen überhaupt toestaan, want een toegewezen exitadres is geen port-forwardingcontract.

Dat onderscheid vangt mensen die een statisch IP kopen in de verwachting van bereikbaarheid. Dat het adres stabiel is, zegt niets over of de provider een inkomende poort naar jouw sessie doorstuurt.

Controleer de listener voordat je de provider controleert

Core moet luisteren op het adres en de poort waar de mapping naartoe levert, en de firewall van de host moet dat toestaan. Draait de node in een container of op een andere machine in het LAN, dan horen de volgende hop en de bijbehorende terugroute ook bij de keten.

Een lokale firewallregel kan geen mapping maken bij een provider die inkomende pakketten weggooit, en een providermapping kan geen proces bereiken dat alleen aan loopback gebonden is. Beide helften moeten het over dezelfde tuple eens zijn, en daarom is de eerste stap de tuple opschrijven in plaats van hem te raden.

Houd het aangekondigde endpoint in overeenstemming met de actuele mapping. Een statisch adres maakt een toegewezen poort of de lease ervan niet permanent tussen herverbindingen, dus een endpoint dat maanden geleden is gepubliceerd, wijst nu misschien naar niets. Lees de pagina van de provider opnieuw na elke herverbinding en vergelijk die met wat je node aankondigt. Als de poort is verschoven, is het oude endpoint nu of van niemand of van iemand anders.

Lees de inkomende vlag, niet het totale aantal verbindingen

Vanuit een geautoriseerde lokale RPC-context somt deze alleen-lezenquery peers op:

bitcoin-cli getpeerinfo

De RPC-referentie definieert inbound als true voor een inkomende verbinding en false voor een uitgaande. Kijk naar dat veld. Een totaal boven de tien bewijst niets over de richting, en de totalen en categorieën verschuiven toch met configuratie en versie.

Test daarna het gemapte endpoint van buitenaf met een nieuwe bereikbaarheidscontrole die je mag uitvoeren, en kijk of er een overeenkomstige inkomende peer verschijnt. Wees voorzichtig met de uitvoer die je in een supportthread plakt: peeradressen zijn verbindingsgegevens van anderen, en die hoeven niet gepubliceerd te worden om je vraag beantwoord te krijgen.

Los het niet op door RPC bloot te stellen

De RPC-documentatie van Bitcoin Core waarschuwt uitdrukkelijk tegen het blootstellen van de RPC-interface aan het openbare internet. Peerverbindingen en geauthenticeerd beheer zijn verschillende diensten, en P2P bereikbaar maken door RPC te publiceren ruilt een connectiviteitsprobleem tegen een veel erger probleem.

Als je liever helemaal niet van inkomende P2P afhankelijk wilt zijn, is een oniondienst het gedocumenteerde alternatief, en die heeft eigen voorwaarden: Tor beschikbaar, controlauthenticatie geconfigureerd en luisterinstellingen die toestaan dat de dienst wordt aangemaakt. Hij verschijnt niet omdat er toevallig een VPN draait.

Core buiten de VPN houden is een derde ontwerp, en voor sommige beheerders legitiem, maar het zet peerverkeer op je gewone verbinding. Dat is geen inkomende toegang via de VPN, en een router of upstream-NAT kan nog steeds zijn eigen toegestane invoer nodig hebben. Kies welke van de drie je werkelijk test voordat je iets anders verandert.