Nebula 중계가 설정되었지만 사용되지 않음: 확인해야 할 세 가지 설정

중계 경로는 세 호스트의 세 문장이 일치해야 합니다. 먼저 중계 역할, 목적지의 중계 목록, 피어의 권한을 확인하십시오.

중계 호스트를 추가하고 그 Nebula 주소를 설정에 넣었지만 두 피어는 여전히 통신하지 않습니다. 이는 중계 경로가 세 개의 별도 문장이 일치해야 하고, 그중 하나만 당신이 편집했을 가능성이 큰 머신에 있기 때문입니다. 저는 이 문제를 두 번 추적했습니다: 한 번은 전달 호스트에 중계 역할이 전혀 부여되지 않은 경우였고, 다른 한 번은 설정이 연결의 반대편에 기록된 경우였습니다. 아래 순서는 역할, 광고, 권한을 그 순서대로 확인하며 각 단계에는 계속할지 알려 주는 명령이 있습니다.

설정을 편집하기 전에 세 가지 역할을 정리하십시오

Nebula는 모든 호스트에 하나의 역할을 부여하며 역할은 상속되지 않습니다. 등대는 '이 피어가 어디 있는가'라는 질문에 답해 호스트들이 서로를 찾게 합니다. 중계는 작동하는 직접 경로가 없는 두 피어 사이에서 트래픽을 전달합니다. 일반 호스트는 둘 다 하지 않습니다. 중요한 세 가지 설정은 서로 다른 세 머신에 있으므로 완벽해 보이는 클라이언트 설정이 두 피어를 모두 기다리게 할 수 있습니다.

# on the discovery host
lighthouse:
  am_lighthouse: true
  hosts: []

# on every other host, point at the discovery host's Nebula address
lighthouse:
  hosts:
    - 10.42.0.1

하나의 증상이 두 가지 실패 유형을 구분합니다. 두 피어가 서로를 목록에 올리고 로그에 끝나지 않는 핸드셰이크 시도가 보인다면 탐색은 작동하며 데이터 경로가 NAT나 방화벽에 의해 차단된 것입니다. 피어가 상대 주소를 전혀 알지 못한다면 문제는 등대나 그 정적 호스트 맵에 있으며 중계 설정으로는 고칠 수 없습니다.

다른 무엇을 편집하기 전에 각 호스트가 실제로 어떤 설정을 불러왔는지 확인하십시오. 편집한 파일과 다른 경로를 읽는 유닛은 '변경이 아무것도 하지 않았다'는 흔하고 창피한 원인입니다:

systemctl cat nebula | grep ExecStart
nebula -version
journalctl -u nebula -n 20 --no-pager

혼합된 환경에서는 버전 줄이 중요합니다. 중계 처리, 펀칭 동작, 허용되는 설정 키는 릴리스마다 동일하지 않으므로 오래된 빌드가 자신을 위해 작성되지 않은 섹션을 이해한다고 가정하지 마십시오. 호스트를 같은 마이너 계열로 맞추고, 각 호스트에서 nebula -test -config /etc/nebula/config.yml 를 실행한 뒤 코드가 구현하지 않는 전송을 디버그하기 전에 출력을 비교하십시오.

중계 호스트에서 전달 역할을 활성화하십시오

중계 역할은 전달 호스트의 플래그 하나이며 등대인 것과는 별개입니다. 탐색이 켜지고 중계 전달이 꺼진 호스트는 여전히 탐색 서비스일 뿐입니다. 중계에서:

relay:
  am_relay: true

이 플래그는 의도를 선언할 뿐 도달 가능성을 만들지 않습니다. 중계는 두 피어 모두에서 도달 가능해야 하며, 실제로는 공인 주소, 호스트 방화벽과 모든 클라우드 보안 그룹에서 Nebula 포트의 인바운드 UDP가 열려 있을 것, 앞에 이중 NAT가 없을 것이 필요합니다. 수신 소켓을 확인한 다음 피어의 패킷이 도착하는지 관찰하십시오:

ss -lunp | grep nebula
tcpdump -ni any udp port 4242 and host 198.51.100.7

두 가지 한계가 나중에 시간을 아껴 줍니다. 다른 중계를 거쳐 중계에 도달할 수는 없으므로 설정의 중계 이름 체인은 전달 호스트에 쓸 만한 경로를 주는 것을 대신하지 못합니다. 그리고 중계는 패킷을 전달할 뿐 권한을 주지 않으므로 중계된 흐름이 허용되는지는 목적지 자체의 인바운드 규칙이 결정합니다. 역할과 요구 사항은 중계 설정 문서에 정리되어 있습니다.

중계는 클라이언트가 아니라 목적지에서 광고하십시오

가장 많은 시간을 잡아먹는 반전입니다. 중계 목록은, 그 호스트에 도달하는 데 어떤 중계를 써도 되는지 다른 피어에게 알려 주기 때문에 도달하려는 호스트에 있어야 합니다. 연결을 시작하는 클라이언트에 두면 클라이언트가 필요한 방향에는 아무 효과가 없습니다:

# on the DESTINATION host: relays others may use to reach me
relay:
  relays:
    - 10.42.0.5

피어는 등대에 체크인할 때 자신의 주소와 함께 그 목록을 보고하므로 광고는 직접 교환이 아니라 탐색을 통해 퍼집니다. 목적지가 등대에 도달하지 못하면 그 중계 목록은 결코 퍼지지 않고 올바르게 설정된 중계는 유휴 상태로 남습니다. 그 실패는 고장 난 중계와 똑같이 보이지만 고장 난 것이 아닙니다.

같은 단계에서 목적지에 부트스트랩 경로를 주십시오. 정적 호스트 맵은 Nebula 주소를 공인 엔드포인트에 묶어 첫 핸드셰이크가 갈 곳을 만들고, 목적지가 직접 도달할 수 없는 호스트로부터 중계 트래픽을 받아들여야 한다면 중계를 위한 항목도 필요합니다:

static_host_map:
  "10.42.0.5": ["203.0.113.10:4242"]

연결하는 피어가 중계를 사용하도록 허용하십시오

시작하는 쪽에도 자체 권한이 필요합니다. relay.use_relays 는 기본으로 켜져 있으므로 찾아볼 만한 사례는 명시적인 false이며, 흔히 중계 기능이 생기기 전에 작성된 템플릿에서 복사되었거나 직접 경로를 강제하려던 이전 시도의 잔재입니다:

relay:
  use_relays: true

이쪽의 권한이 유일한 관문은 아닙니다. 목적지의 인바운드 규칙은 중계된 패킷에도 적용되며, 규칙이 일치시키는 출처는 중계 자체의 주소가 아니라 터널 안의 정체성입니다. 중계된 핸드셰이크가 완료되어도 애플리케이션이 실패하면 규칙을 다시 쓰기 전에 목적지 로그에서 기록된 출처를 읽으십시오.

NAT 트래버설 설정은 이 모든 것과 상호 작용합니다. punchy.punch 는 두 피어가 직접 경로를 열도록 돕고, 성공하면 관찰할 중계 트래픽이 없으며, 그것은 성공이지 빠진 중계가 아닙니다. 간헐적으로 동작하는 쌍은 보통 펀칭이 가끔 성공한다는 뜻이므로 한 번의 시도로 결론 내리지 말고 그 쌍을 여러 번 시험하십시오.

실패한 쌍으로 검증한 다음 다시 불러오십시오

실제로 실패한 두 호스트를 필요한 애플리케이션과 함께 시험하십시오. 작업 머신에서 중계 자체 서비스로의 성공적인 ping은 다른 두 피어 사이의 전달에 대해 아무것도 증명하지 않으며, 이것이 이 절차 전체에서 가장 흔한 오탐입니다.

journalctl -u nebula -f | grep -iE "relay|handshake"
ping -c 3 10.42.0.9

재시작 대신 다시 불러오고, 실행 중인 프로세스가 편집한 파일을 읽었는지 확인하십시오. 재시작은 모든 터널을 끊어 다음 시험을 읽기 어렵게 만들지만, SIGHUP은 프로세스를 유지한 채 설정을 다시 읽게 합니다:

sudo systemctl kill -s HUP nebula
# same signal when nebula runs in the foreground
kill -HUP $(pidof nebula)

systemctl reload 는 로컬 유닛이 ExecReload를 정의할 때만 동작하며 프로젝트에 포함된 유닛은 정의하지 않으므로, 표준 설치에서 성공하는 단계는 systemctl kill -s HUP 입니다. 다시 불러온 뒤 프로세스가 연 설정 경로를 저널에서 읽어, 가정했던 파일이 아니라 새 파일이 읽혔음을 확인하십시오.

중계 설정과 NAT 펀칭은 둘 다 경로에 작용하며 어느 것도 정체성에는 작용하지 않습니다. 실행 중인 설정에서 am_relay, relays, use_relays 이 확인된 뒤에도 쌍의 핸드셰이크가 실패하면, 두 호스트가 설정된 이름에 대해 발급된 인증서를 제시하는지 그리고 양쪽의 CA가 같은지 확인하십시오. 인증서 편집과 중계 편집이 같은 시험에 섞이면 어느 쪽이 핸드셰이크를 움직였는지 알 수 없으므로 인증서와 방화벽 설정은 고정한 채 전송 설정을 한 번에 하나씩 바꾸십시오. 이름이나 CA 불일치는 결코 발견되지 않은 중계와 같은 지점에서 실패하므로 이 대조 확인도 같은 단계에 속합니다.

그런 다음 각 문장이 속한 파일에 있는지 확인하십시오:

  • 전달 호스트의 am_relay: true 와 그 호스트가 양쪽에서 UDP로 도달 가능할 것.
  • 목적지에서 그 호스트의 Nebula 주소를 지정하는 relays:.
  • 연결을 시작하는 피어의 use_relays: true.
  • 경로가 바뀐 뒤에도 목적지의 인바운드 규칙이 실제 출처를 허용하는지.

관련 글