VPN으로 마이닝 풀: 세션을 올바른 경로에 유지하기

마이닝 소프트웨어는 하나의 소켓을 하나의 주소로 열어 두며, 터널과 경로, 적립된 작업에 관한 모든 질문은 그 소켓에 매달려 있습니다. 그 소켓은 풀 엔드포인트로 향하는 나가는 클라이언트 세션이며 피어를 받아들이는 리스너가 아닙니다. 아래의 여정은 풀이 발급한 네 값에서 풀이 실제로 기록한 몫까지 그것을 따라가며 호스트의 다른 서비스는 건드리지 않습니다. 각 단계는 비교할 수 있는 답을 내놓지 인상을 내놓지 않습니다.

풀이 실제로 발급한 엔드포인트에서 시작하십시오

풀은 계약 전체를 이루는 네 값을 줍니다: 호스트 이름이나 주소, 포트, 프로토콜 변형, 계정 문자열입니다. 이들은 풀의 대시보드나 온보딩 메시지에서 가져오고 다른 풀을 위한 자습서에서 가져오지 마십시오. 같은 서비스에도 지역 샤드가 있으므로 오래된 안내서에서 복사한 호스트 이름도 여전히 접속될 수 있고 당신이 한 번도 쓰려 하지 않은 계정에 여전히 적립될 수 있습니다. 네 값을 마이너 구성에 그대로 복사하십시오. 다시 입력한 계정 문자열은 구분자를 잃기 때문입니다.

당신이 라우팅하는 흐름은 Bitcoin 개발자 안내서가 Stratum 세션이라고 부르는 것입니다: 풀이 작업을 분배하고 마이너가 몫을 돌려주는 지속적인 양방향 TCP 연결입니다. 이것은 전체 노드의 피어 연결이나 지갑의 체인 동기화와 같은 흐름이 아니며, 이들을 하나의 트래픽 클래스로 접는 것이 대부분의 혼란이 시작되는 지점입니다. 이 정책에는 첫 번째만 속합니다.

풀이 TLS를 제공하는 곳에서는 그 문서가 요구하는 서버 검증을 유지하십시오. 터널은 당신의 기계에서 VPN 서버까지의 홉을 암호화하고 거기서 끝납니다. 반대편에서 누가 응답하는지 보증하지 않습니다. 세션이 침해된 출구를 견디길 원한다면 양 끝에 두 검증을 모두 유지하십시오.

터널을 프로세스에 붙이십시오, 가정에 붙이지 마십시오

붙이는 지점은 두 가지입니다: VPN 클라이언트를 마이너가 쓰는 네트워크 네임스페이스 안에서 실행하거나, 그 네임스페이스에 트래픽을 터널로 가져가는 게이트웨이를 주십시오. 두 배치 모두 풀이 보기 전에 세션을 경로 위에 둡니다. 흔한 실패는 호스트의 클라이언트, 자체 브리지를 가진 컨테이너의 마이너, 그리고 컨테이너가 결코 묻지 않는 호스트 경로입니다. 클라이언트 창은 건강해 보이지만 풀은 당신의 집 주소를 기록합니다.

무엇이든 제한하기 전에 터널 자체의 전송을 확인하십시오. 클라이언트는 하위 계층을 통해 서버에 도달해야 하므로 모든 패킷을 잡는 정책은 터널을 세울 패킷도 잡습니다. 그러면 터널이 시작될 수 없고 다른 것도 나가지 않습니다. 클라이언트의 분할 터널 기능으로 터널에 무엇이 들어가는지 고르십시오. 기본 경로를 손으로 고치는 것이 하위 계층이 사라지는 방식입니다.

정책이 자리 잡으면 마이너가 속한 네임스페이스에서 소켓 표를 읽으십시오. 풀 포트로 가는 흐름은 터널 인터페이스에 있어야 하며 두 명령이 그 질문에 답합니다. 아래의 포트는 예시입니다. 풀이 발급한 포트로 바꾸십시오.

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

경로와 리졸버를 마이너 자신의 문맥에서 읽으십시오

라우팅과 이름 해석은 네임스페이스마다 적용되므로 일반 셸에서 실행한 점검은 마이너가 컨테이너에 있을 때마다 틀린 기계를 설명합니다. 먼저 네임스페이스에 들어가고 그다음 어떤 인터페이스가 패킷을 풀 주소로 가져갈지, 어떤 리졸버가 그 호스트 이름에 답할지 물으십시오. 호스트의 답은 전달되지 않으며 그 사이의 간극은 잘못 짚은 비난의 흔한 근원입니다.

얻은 인터페이스를 이름 붙이십시오: 터널은 세션이 의도한 경로에 있다는 뜻이고, 물리 링크는 규칙이 예상보다 일찍 맞았다는 뜻입니다. 프리픽스 길이가 먼저 결정하고 그다음 메트릭, 그다음 정책 규칙이므로 기본 항목이 여럿인 표는 패킷을 복제하지 않고 그저 집니다.

리졸버는 경로와 별개로 실패합니다. /etc/resolv.conf 파일을 다시 쓰는 터널은 네임스페이스를 터널 안에서만 닿을 수 있는 리졸버로 가리키게 남길 수 있고, 이는 어떤 TCP 핸드셰이크도 일어나기 전에 실패합니다. 풀의 호스트 이름을 네임스페이스 안에서 해석하고 공개된 주소와 비교하십시오. 조회가 시간 초과되거나 다른 값을 돌려주면 경로를 건드리기 전에 해석을 고치십시오.

풀 클라이언트와 노드 리스너를 분리하십시오

포트 8333는 Bitcoin Core의 피어 포트이며 전체 노드가 인바운드 연결을 듣는 곳입니다. 풀 마이너는 그것이 열려 있을 필요가 결코 없고 열어도 나가는 고장을 고치지 않습니다. 인바운드 리스너와 아웃바운드 세션은 상반된 신뢰 가정을 가진 상반된 역할입니다. 마이너 구성에서 어느 것도 그 포트를 묶지 않으므로 닫힌 포트는 그것이 보고하는 어떤 오류도 설명할 수 없습니다. 따라서 노드의 도달 가능성을 위해 쓰인 조언은 몫만 보내야 했던 호스트에 공용 서비스를 남겨 둘 수 있습니다.

한 기계가 정말 둘 다 한다면 각 역할을 자체 접근 결정을 가진 별도 서비스로 다루십시오. 노드의 리스너는 당신이 공용 서비스에 적용하는 정책 뒤에 속하고, 마이너의 세션은 터널을 고르는 출구 정책에 속합니다. 호스트가 어떤 역할을 하는지 기록하고 그것이 바뀌면 다른 역할의 규칙을 제거하십시오. 남은 허용 규칙은 그 이유보다 오래 살기 때문입니다.

풀이 작업을 받았음을 증명하십시오

바쁜 팬과 오르는 해시레이트는 마이너가 계산한다는 것을 보여줄 뿐 무언가가 풀에 도달했다는 것을 보여주지 않습니다. 증거는 클라이언트의 제출 카운터나 풀의 대시보드에 있습니다: 수락된 몫, 거부된 몫, 그리고 각 거부에 붙은 이유입니다. 그 숫자들은 밖에서 보면 동일해 보이는 세 가지 고장을 구분합니다: 세션 없음, 적립 없는 세션, 계속 다시 연결하는 세션입니다. 어떤 구성이든 바꾸기 전에 그것들을 읽으십시오.

상세 로깅으로 연결 시도 하나를 관찰하고 성공한 마지막 단계를 적으십시오. 순서가 멈추는 단계가 그 주변의 어느 단일 메시지보다 유용합니다:

그다음 클라이언트를 정해진 창 동안 실행하게 하고 그 로그에서 두 결과를 세십시오. 카운터마다 grep 하나면 충분하고, 같은 창에서 비교하면 느린 풀과 끊긴 경로를 구분합니다. 경로를 클라이언트가 쓰는 위치에 맞추십시오. 두 셈은 위치에 의존하지 않기 때문입니다:

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

규칙이 터널이 떨어질 때마다 풀에 직접 연결하는 것을 금지한다면 그것을 풀 엔드포인트에 대한 명시적 차단으로 표현하십시오. 물리 링크로 조용히 다시 시도하는 클라이언트는 계속 채굴하고 그 규칙을 계속 어기며, 그 상태 표시는 이를 언급하지 않습니다. 터널을 일부러 떨어뜨리고 풀 포트에 전혀 닿을 수 없음을 확인하여 규칙을 시험하십시오.