Brak połączeń przychodzących na Twoim węźle Bitcoin za VPN?

Twój węzeł jest zsynchronizowany, VPN zgłasza połączenie, a getpeerinfo pokazuje osiem lub dziesięć peerów. Żaden z nich nie ma inbound ustawionego na true. Ta kombinacja jest normalna i nie jest awarią: połączenia wychodzące dowodzą, że węzeł może dotrzeć do innych, a nic w nich nie dowodzi, że ktokolwiek może dotrzeć do Ciebie. Jeśli celem jest węzeł przyjmujący przychodzące połączenia P2P przez VPN, musisz przetestować ten kierunek osobno.

Prześledź pakiet od peera do swojego nasłuchiwacza

Przychodzące P2P to łańcuch czterech rzeczy, a pęka on na najsłabszym ogniwie, nie na najciekawszym.

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

Domyślna wartość P2P Core w sieci głównej to 8333, ale dostawca może dać Ci inny port publiczny i inny cel po stronie klienta. Zapisz adres publiczny, port zewnętrzny i miejsce, w którym dostawca faktycznie dostarcza ruch. Następnie potwierdź, że Twój plan i konto w ogóle pozwalają na połączenia przychodzące, bo dedykowany adres wyjściowy nie jest umową na przekierowanie portów.

To rozróżnienie łapie ludzi kupujących statyczny IP w nadziei na osiągalność. Stabilność adresu nie mówi nic o tym, czy dostawca przekierowuje port przychodzący do Twojej sesji.

Sprawdź nasłuchiwacz, zanim sprawdzisz dostawcę

Core musi nasłuchiwać na adresie i porcie, na które dostarcza mapowanie, a firewall hosta musi na to pozwalać. Jeśli węzeł działa w kontenerze lub na innym komputerze w sieci LAN, kolejny skok i jego trasa powrotna też należą do łańcucha.

Lokalna reguła firewalla nie może utworzyć mapowania u dostawcy, który odrzuca pakiety przychodzące, a mapowanie dostawcy nie dotrze do procesu związanego tylko z loopbackiem. Obie połowy muszą się zgodzić co do tej samej krotki, dlatego pierwszym krokiem jest zapisanie krotki, a nie zgadywanie jej.

Utrzymuj ogłoszony punkt końcowy spójny z bieżącym mapowaniem. Statyczny adres nie czyni przypisanego portu ani jego dzierżawy trwałymi między ponownymi połączeniami, więc punkt końcowy opublikowany miesiące temu może teraz nie wskazywać na nic. Przeczytaj ponownie stronę dostawcy po każdym ponownym połączeniu i porównaj ją z tym, co ogłasza Twój węzeł. Jeśli port się przesunął, stary punkt końcowy jest teraz albo niczyj, albo czyjś inny.

Czytaj flagę przychodzącą, nie łączną liczbę połączeń

Z autoryzowanego lokalnego kontekstu RPC to zapytanie tylko do odczytu wyświetla peerów:

bitcoin-cli getpeerinfo

Dokumentacja RPC definiuje inbound jako true dla połączenia przychodzącego i false dla wychodzącego. Spójrz na to pole. Łączna liczba powyżej dziesięciu nic nie dowodzi o kierunku, a sumy i kategorie i tak zmieniają się z konfiguracją i wersją.

Następnie przetestuj zmapowany punkt końcowy z zewnątrz nową kontrolą osiągalności, którą masz prawo uruchomić, i zobacz, czy pojawi się odpowiedni peer przychodzący. Uważaj z danymi wyjściowymi wklejanymi do wątku pomocy technicznej: adresy peerów to dane połączeń innych osób i nie trzeba ich publikować, aby odpowiedzieć na Twoje pytanie.

Nie rozwiązuj tego, wystawiając RPC

Dokumentacja RPC Bitcoin Core wyraźnie ostrzega przed wystawianiem interfejsu RPC do publicznego internetu. Połączenia z peerami i uwierzytelniona administracja to różne usługi, a udostępnianie P2P przez publikowanie RPC zamienia problem z łącznością na znacznie gorszy.

Jeśli wolisz w ogóle nie zależeć od przychodzącego P2P, udokumentowaną alternatywą jest usługa onion, a ona ma własne wymagania wstępne: dostępny Tor, skonfigurowane uwierzytelnianie sterowania i ustawienia nasłuchu pozwalające utworzyć usługę. Nie pojawia się tylko dlatego, że przypadkiem działa VPN.

Wyłączenie Core z VPN to trzeci projekt, i dla części operatorów uzasadniony, ale przenosi ruch peerów na Twoje zwykłe połączenie. To nie jest dostęp przychodzący przez VPN, a router lub nadrzędny NAT nadal może potrzebować własnego dozwolonego wpisu. Zdecyduj, który z trzech naprawdę testujesz, zanim zmienisz cokolwiek innego.