Nebula static_host_map: 등대가 줄 수 없는 주소

모든 등대는 등대 자신이 어디에 있는지만 빼고 다른 모든 피어에 대해 호스트에게 알려 줄 수 있다. 오버레이가 존재하기 전에 무언가가 알려져 있어야 하고, Nebula는 그 무언가를 작은 지도 하나에 담는다. 지도는 오버레이 정체성을 평범한 네트워크에서 동작하는 주소와 짝지운다. 나중에 배우는 모든 것은 그 짝이 옳다는 데 달려 있다.

두 가지 역할을 하는 두 주소

모든 Nebula 호스트는 기기가 네트워크 사이를 옮겨 다녀도 고정된 오버레이 주소를 갖는다. 그 주소는 인증서, 방화벽 규칙, 피어 관계가 사용하는 정체성이며, 그 자체로는 어디로도 라우팅하지 않는다. 도달 가능한 엔드포인트는 하위 네트워크의 호스트 이름이나 주소에 UDP 포트를 더한 것이고, 기계가 위치를 바꿀 때마다 바뀐다. 정적 지도는 둘 사이의 이음매다.

지도에는 차가운 상태로 다이얼해야 하는 호스트만 들어가며, 보통 등대와 어쩌면 릴레이 하나를 뜻한다. 그 목록을 짧게 유지하는 것이 설계 목표인데, 수동 항목마다 누군가 유지해야 할 사실이 되기 때문이다. 등대 목록에 넣은 공인 주소가 탐색을 시작하게 하지 않는 것이 두 주소 유형을 혼동하는 흔한 설정 실수다.

정체성은 정체성이 기대되는 곳으로 간다. 도달 가능성은 지도로 간다.

static_host_map:
  "10.42.0.1": ["lighthouse-01.example.net:4242"]

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

지도 항목의 해부

키는 따옴표로 묶인 문자열로 쓴 오버레이 주소이고, 값은 엔드포인트 목록이므로 하나의 정체성에 여러 진입점이 있을 수 있다. 각 엔드포인트는 호스트와 포트를 가지며, 포트는 상대가 실제로 듣는 것과 일치해야 한다. Nebula의 기본값은 UDP 4242이며, 이는 출발점이지 당신의 배포에 대한 약속이 아니다.

등대로 들어오는 길이 둘 이상일 때(예: 공인 주소와 같은 세그먼트 호스트용 사설 주소) 여러 엔드포인트가 유용하다. 클라이언트는 순서대로 시도하므로 가장 신뢰할 수 있는 것을 먼저 둔다. IPv6에서는 포트를 붙이기 전에 주소를 대괄호로 묶는데, 틀리면 잘못된 줄을 가리키는 파싱 오류가 난다.

UDP에는 거절할 핸드셰이크가 없기 때문에 잘못된 포트는 오류 대신 침묵을 낳는다. 그래서 항목 형식은 기억이 아니라 Nebula static_host_map 참조 와 대조해 확인할 가치가 있다. 참조는 엔드포인트 목록과 DNS 갱신 동작도 다룬다.

부트스트랩은 오버레이보다 먼저 동작해야 한다

지도의 DNS 이름은 터널이 존재하기 전에 호스트가 가진 리졸버, 즉 보통의 시스템 리졸버로 해석되어야 한다. 같은 기계에서 부팅 시 오버레이를 멈춘 채로 시험하라. 오버레이 자체의 DNS로만 해석되는 이름은 오버레이를 부트스트랩할 수 없다. 같은 시험이 경로에도 적용되어, 오버레이는 허용하지만 첫 UDP 교환은 허용하지 않는 방화벽 규칙은 첫 패킷을 막는다.

포트가 열려 있다고 가정하지 말고 UDP 도구로 확인하라. 경로의 모든 포트 포워딩이 올바른 내부 호스트를 향하는지, 되돌아오는 경로가 있는지 확인하라. 호스트 이름이 여러 주소로 해석되면 클라이언트가 당신이 확인하지 않은 주소를 고를 수 있으므로 각각을 시험하라.

정적 항목은 직접 다이얼되며 결코 등대에 묻지 않는다. 그래서 여기서의 실패는 피어가 관여하지 않은 평범한 타임아웃처럼 보인다.

첫 핸드셰이크 후에 무슨 일이 일어나는가

호스트가 등대에 도달하면 더 이상의 수동 항목 없이 피어와 그들의 도달 가능한 주소를 배운다. 마지막 연결 이후 이동한 호스트는 그 경로를 통해 발견 가능해진다. 이것이 수동 지도를 작게 유지하는 보상이다.

호스트는 자신의 추가 도달 가능한 주소를 광고할 수도 있다, 그래서 알려진 공인 주소 뒤에 있는 피어가 다른 이들이 그것을 찾도록 돕는다. 그 광고는 배워지는 것이지 정적 지도에 입력되는 것이 아니다.

DNS 이름으로 쓰인 엔드포인트에는 프로세스가 계속 도는 동안 해석된 주소가 바뀔 수 있기 때문에 갱신 동작이 중요하다. Nebula의 설정은 그 조회가 어떻게 이루어지는지, 어떤 리졸버를 쓰는지까지 제어하므로 시스템 기본값을 가정하지 말고 읽어라. 터널이 올라올 때 리졸버가 바뀌는 호스트에서는 잘못된 설정이 동작하던 부트스트랩을 세션 중간에 해석을 멈추는 이름으로 바꿀 수 있다. 조회를 안정된 리졸버에 고정하는 것이 신뢰할 수 있는 오버레이와 간헐적인 오버레이의 차이인 경우가 많다.

탐색은 되는데 한 피어가 안 될 때

등대에 도달할 수 있고 대부분의 피어가 연결된다면 부트스트랩은 문제가 아니다. 남은 쌍은 서로에게 쓸 만한 경로를 찾지 못하거나 도달 가능성 위에서 실패한다. 등대 주소의 또 다른 표기를 더해도 두 경우 중 어느 것도 고쳐지지 않는다.

다른 모든 것이 이미 의존하는 지도를 편집하기 전에 그 쌍을 확인하라. 지도 변경은 모든 호스트를 흔들므로 가장 마지막에 손댈 것이지 처음이 아니다.

거부된 핸드셰이크는 멀리서 보면 도달할 수 없는 피어처럼 보일 수 있으므로 같은 기관의 인증서로 시작하라. 다음으로 그 쌍이 직접 경로를 세울 수 있는지, 직접 트래픽을 거부하는 네트워크를 위한 릴레이가 설정되어 있는지 확인하라. 릴레이는 홉과 의존성을 하나 더하지만 지원되는 답이며, 쌍의 경로를 고치는 것은 탐색을 고치는 것과 다른 작업이다.