Nebula punchy 설정: NAT 문제를 고치는 것은 어느 쪽인가

두 피어가 등대를 통해 서로를 찾은 뒤 직접 경로를 만들지 못할 때, 첫 반응은 모든 punchy 옵션을 켜는 것입니다. 그 반응이 만드는 것은 세 가지 변경을 담은 설정이며, 어느 것이 중요했는지는 알 수 없습니다. 설정은 서로 다른 질문에 답하는데, 하나는 이미 있는 매핑을 유지하고 다른 하나는 반대 방향으로 핸드셰이크를 시도합니다. 둘 중 어느 것도 건드리기 전에 자신의 질문이 무엇인지 정하세요.

타이밍보다 먼저 엔드포인트를 확인하세요

예상 주소에 절대 나타나지 않는 피어는 punch 조정으로 구제되지 않습니다. 오래된 bootstrap 주소나 실수로 공개된 사설 주소는 모든 통과 기법을 무력화하므로, 등대가 그 피어에 대해 무엇을 아는지, 피어 자신의 설정이 무엇을 광고하는지 확인하세요. 신뢰되지 않는 신원은 NAT가 문제가 되기 훨씬 전에 대화를 멈추므로, 인증서가 신뢰되는지도 확인하세요. 그다음 UDP가 등대에 닿기는 하는지 확인하세요. 타이밍 값은 가장 먼저 볼 것이 아니라 가장 나중에 볼 것입니다.

나중 비교에서 다른 두 장비가 아니라 같은 피어를 쓰기 위해, 시험 중인 엔드포인트 쌍을 기록해 두세요.

punch는 매핑을 유지하고 respond는 방향을 엽니다

punch 옵션은 이미 터널이 있는 피어의 언더레이 주소로 빈 패킷을 주기적으로 보냅니다. 그 목적은 화려하지 않은데, 상태를 가진 NAT나 방화벽이 직접 경로가 의존하는 매핑을 만료시키지 않게 하는 것입니다. respond 옵션은 등대 알림에서 일어나는 일을 바꾸어, 호스트가 자신에게 도달하려는 피어 쪽으로 역방향 핸드셰이크를 시도하게 만듭니다. 서로 다른 실패 방식을 가진 서로 다른 메커니즘입니다.

직접 경로가 동작하다가 나중에 약해지면 punch를 고르세요. 경로가 한 방향으로조차 형성되지 않으면 respond를 고르세요. 둘 다 켜고 기대는 것은 오 분짜리 수정을 일주일짜리 조정으로 만드는 방법입니다.

지연은 언제를 정하지, 되는지 여부를 정하지 않습니다

지연 값은 시점을 옮기는데, 하나는 알림 후에 보내는 패킷에, 다른 하나는 역방향 핸드셰이크 시도에 적용됩니다. 어느 것도 막힌 방향을 동작하게 만들지 않습니다. 둘을 한꺼번에 바꾸면 하려던 비교가 무너집니다.

메커니즘이 맞을 때까지 그대로 두세요. 그다음 하나만 조정하고, 이전 값을 적어 두세요.

릴레이가 정직한 답일 때

일부 NAT 조합은 타이밍을 어떻게 배열해도 직접 경로를 지원할 수 없습니다. 양쪽이 대칭 NAT이거나, 요청되지 않은 인바운드 트래픽을 완전히 버리는 방화벽이라면 뚫을 것이 남지 않습니다.

도달 가능한 주소를 가진 릴레이 노드는 그 피어들에게 통과 성공에 의존하지 않는 경로를 줍니다. 그 노드를 지나는 대역폭을 쓰므로, 이는 우회가 아니라 용량에 관한 결정입니다. 릴레이 자체가 어려운 NAT 뒤에 있으면 아무것도 달라지지 않으므로, 릴레이를 의도적으로 구성하고 피어가 거기에 도달할 수 있는지 확인하세요. 직접 경로는 나타날 수 없었으므로, 그다음 그 쌍에 대한 punch 설정 조정을 그만두세요.

실패한 쌍을 유휴 상태 후에 시험하세요

망가진 조건을 재현하려면, 같은 간격만큼 쌍을 유휴 상태로 두거나 예전에 실패하던 핸드셰이크 순서를 반복하세요. 그다음 등대에 보내는 요청이 아니라, 그 두 피어 사이에서 애플리케이션을 실행하세요. 등대의 응답은 제어 경로를 증명할 뿐 데이터 경로에 대해서는 아무것도 말해 주지 않습니다.

어떤 설정이 바뀌었는지, 시각, 그리고 직접 경로가 나타났는지 트래픽이 릴레이에 남았는지 기록하세요. 남았다면 답은 릴레이와 용량 메모이며, 그것은 충분히 좋은 결과입니다. 나타났다면, 매핑이 약해지는 것이 바로 punch가 존재하는 이유이므로, 다음 질문은 한 시간 유휴를 견디는지입니다.