Pool wydobywczy przez VPN: utrzymać sesję na właściwej ścieżce

Oprogramowanie wydobywcze trzyma jedno gniazdo otwarte do jednego adresu, a każde pytanie o tunel, trasę i zaliczoną pracę wisi na tym gnieździe. To gniazdo to wychodząca sesja klienta do punktu końcowego puli, a nie nasłuchujący, który przyjmuje peerów. Poniższa wędrówka prowadzi od czterech wartości wydanych przez pulę do udziału, który pula faktycznie zaksięgowała, i nie rusza innych usług hosta. Każdy krok daje odpowiedź, którą można porównać, a nie wrażenie.

Zacznij od punktu końcowego, który pula faktycznie wydała

Pula daje ci cztery wartości, które tworzą całą umowę: nazwę hosta lub adres, port, wariant protokołu i ciąg konta. Weź je z panelu puli albo z wiadomości powitalnej, a nie z poradnika dla innej puli. Dla tej samej usługi istnieją shardy regionalne, więc nazwa hosta skopiowana ze starego przewodnika nadal może się połączyć i nadal zaliczyć konto, którego nigdy nie chciałeś używać. Skopiuj cztery wartości dosłownie do konfiguracji górnika, bo przepisany ciąg konta traci separator.

Przepływ, który trasujesz, to ten, który przewodnik dewelopera Bitcoina nazywa sesją Stratum: trwałym dwukierunkowym połączeniem TCP, w którym pula rozdziela pracę, a górnik zwraca udziały. To nie ten sam przepływ co połączenia peerów pełnego węzła albo synchronizacja łańcucha portfela, i właśnie składanie ich w jedną klasę ruchu jest źródłem większości zamieszania. Tylko pierwszy należy do tej polityki.

Tam, gdzie pula oferuje TLS, zachowaj weryfikację serwera wymaganą przez jej dokumentację. Tunel szyfruje przeskok z twojej maszyny do serwera VPN i kończy się tam; nie ręczy za tego, kto odpowiada po drugiej stronie. Zachowaj oba sprawdzenia, po jednym na każdym końcu, jeśli sesja ma przetrwać przejęte wyjście.

Przypnij tunel do procesu, nie do gospodarstwa

Działają dwa punkty przypięcia: uruchom klienta VPN w przestrzeni nazw sieci, której używa górnik, albo daj tej przestrzeni bramę, która niesie jej ruch do tunelu. Oba układy stawiają sesję na ścieżce, zanim pula ją zobaczy. Zwykła porażka to klient na hoście, górnik w kontenerze z własnym mostem i trasa hosta, której kontener nigdy nie sprawdza. Okno klienta wygląda zdrowo, podczas gdy pula zapisuje twój domowy adres.

Sprawdź własny transport tunelu, zanim cokolwiek wyznaczysz. Klient musi dotrzeć do swojego serwera przez podłoże, więc polityka, która przechwytuje każdy pakiet, przechwytuje też pakiety, które zbudowałyby tunel. Wtedy tunel nie może wystartować i nic innego też nie wychodzi. Wybierz funkcją split tunelingu klienta, co wchodzi do tunelu; ręczna edycja tras domyślnych to sposób, w jaki podłoże znika.

Gdy polityka jest na miejscu, odczytaj tabelę gniazd w przestrzeni nazw, do której należy górnik. Przepływ do portu puli powinien leżeć na interfejsie tunelu, a dwa polecenia odpowiadają na to pytanie. Port poniżej jest przykładem; podstaw ten, który wydała pula.

sudo nsenter -t "$(pidof cgminer)" -n ss -tnp state established 'dport = :3333'
sudo nsenter -t "$(pidof cgminer)" -n ip route get 203.0.113.10

Czytaj trasę i resolver z własnego kontekstu górnika

Routing i rozwiązywanie nazw są na przestrzeń nazw, więc sprawdzenie uruchomione w zwykłej powłoce opisuje złą maszynę, gdy górnik działa w kontenerze. Wejdź najpierw do przestrzeni nazw, a potem zapytaj, który interfejs niósłby pakiet do adresu puli i który resolver odpowiadałby za jej nazwę hosta. Odpowiedzi hosta nie przenoszą się, a różnica między nimi to częste źródło źle ulokowanej winy.

Nazwij interfejs, który dostajesz: tunel oznacza, że sesja jest na zamierzonej ścieżce, a łącze fizyczne oznacza, że reguła dopasowała się wcześniej, niż się spodziewałeś. Najpierw decyduje długość prefiksu, potem metryka, potem reguły polityki, więc tabela z kilkoma wpisami domyślnymi nie duplikuje pakietów, po prostu przegrywa.

Resolver zawodzi osobno od tras. Tunel, który przepisuje /etc/resolv.conf, może zostawić przestrzeń nazw wskazującą resolver osiągalny tylko od wewnątrz tunelu, co zawodzi, zanim dojdzie do jakiegokolwiek uścisku TCP. Rozwiąż nazwę hosta puli w przestrzeni nazw i porównaj ją z opublikowanym adresem. Jeśli zapytanie przekroczy czas lub zwróci coś innego, napraw rozwiązywanie, zanim dotkniesz tras.

Trzymaj osobno klienta puli i nasłuch węzła

Port 8333 to port peera Bitcoin Core, na którym pełny węzeł nasłuchuje połączeń przychodzących; górnik w puli nigdy nie potrzebuje go otwartego, a otwarcie go nie naprawia awarii wychodzącej. Nasłuchy przychodzące i sesje wychodzące to przeciwne role o przeciwstawnych założeniach zaufania. Nic w konfiguracji górnika nie wiąże tego portu, więc zamknięty port nie może wyjaśnić żadnego zgłoszonego błędu. Porada napisana pod osiągalność węzła może więc zostawić usługę publiczną działającą na hoście, który miał tylko wysyłać udziały.

Jeśli jedna maszyna naprawdę robi jedno i drugie, traktuj każdą rolę jako osobną usługę z własną decyzją o dostępie. Nasłuch węzła należy za politykę, którą stosujesz do usług publicznych, a sesja górnika należy do polityki wyjścia, która wybiera tunel. Zapisz, jaką rolę pełni host, i usuwaj reguły drugiej roli, gdy to się zmieni, bo pozostawiona reguła zezwalająca przeżywa swój powód.

Udowodnij, że pula otrzymała pracę

Zajęty wentylator i rosnący hashrate pokazują, że górnik liczy, a nie że cokolwiek dotarło do puli. Dowód jest w licznikach wysyłki klienta albo w panelu puli: przyjęte udziały, odrzucone udziały i powód przy każdym odrzuceniu. Te liczby rozdzielają trzy awarie, które z zewnątrz wyglądają identycznie: brak sesji, sesję bez zaliczenia i sesję, która ciągle łączy się od nowa. Przeczytaj je, zanim zmienisz jakąkolwiek konfigurację.

Obejrzyj jedną próbę połączenia ze szczegółowym logowaniem i zanotuj ostatni etap, który się udał. Etap, na którym sekwencja się zatrzymuje, jest użyteczniejszy niż jakikolwiek pojedynczy komunikat wokół niego:

Potem pozwól klientowi działać przez stałe okno i policz oba wyniki w jego logu. Jeden grep na licznik wystarczy, a porównanie ich w tym samym oknie oddziela wolną pulę od zepsutej ścieżki. Dostosuj ścieżkę do miejsca, w którym klient pisze, bo oba zliczenia nie zależą od lokalizacji:

grep -c Accepted /var/log/miner.log
grep -c Rejected /var/log/miner.log

Jeśli reguła zabrania bezpośredniego połączenia z pulą za każdym razem, gdy tunel pada, wyraź ją jako jawną blokadę punktu końcowego puli. Klient, który cicho ponawia przez łącze fizyczne, będzie dalej wydobywał i dalej łamał tę regułę, a jego wyświetlacz stanu tego nie wspomni. Przetestuj regułę, celowo zrzucając tunel i potwierdzając, że port puli jest w ogóle nieosiągalny.