Nebula 인증서를 다시 불러와도 IP가 바뀌지 않은 이유
다시 불러오기는 오버레이 주소가 그대로일 때만 호스트 자격 증명을 다시 읽습니다. 주소를 바꾸는 것은 재시작과 네트워크 변경이며, 재시도가 아닙니다.
다른 오버레이 주소로 새 호스트 인증서를 발급하고, 이전 파일 위에 덮어쓰고, 다시 불러오기를 보내도 호스트는 이전 주소에서 계속 응답합니다. 반사적으로는 다시 불러오기가 실패했거나 잘못된 파일을 읽었다고 생각합니다. 보통은 둘 다 아닙니다. 실행 중인 프로세스가 이미 가진 정체성을 의도적으로 유지한 것입니다. 대체 파일이 다시 불러오기로는 적용할 수 없는 무언가를 바꾸었기 때문입니다.
Nebula의 PKI 다시 불러오기 지원은 이 경계와 함께 문서화되어 있으며, 같은 문서가 다른 변경에는 다시 불러오기가 작동한다고 보여 주면 놓치기 쉽습니다.
다시 불러오기가 실제로 다시 읽는 것
호스트 인증서는 SSH 키처럼 단순한 자격 증명이 아닙니다. 오버레이 주소, 호스트 이름, 그룹 소속, 유효 기간을 담고 있으며, 이 모든 것은 CA의 서명으로 묶여 있습니다. 데몬은 그 서명된 내용을 사용해 자신을 어떻게 제시하고 어떤 규칙이 적용되는지 결정합니다.
다시 불러오기를 쓰면 프로세스가 터널을 떨어뜨리지 않고 갱신된 자격 증명을 받아들일 수 있습니다. 정기적인 교체에 유용합니다. 같은 주소, 같은 이름, 같은 그룹, 더 늦은 만료입니다. 제약은 정체성이 같아야 한다는 것입니다. 오버레이 주소를 바꾸면 다시 불러오기 경로가 그것을 적용할 수 없습니다. 주소는 실행 중인 인스턴스가 이미 확정한 내용의 일부이기 때문입니다.
따라서 보신 동작은 문서화된 제한이 제 역할을 한 결과이며, 조용한 실패가 아닙니다. 디스크의 파일은 새것이고, 메모리의 정체성은 옛것이며, 프로세스에는 재시작 없이 그 차이를 조정할 지원되는 방법이 없습니다.
주소, 이름, 그룹은 하나의 정체성
인증서를 개별적으로 편집할 수 있는 필드의 집합이 아니라 하나의 레코드로 보는 편이 이해에 도움이 됩니다. 주소를 옮기는 것은 환경 설정을 바꾸는 것과 다릅니다. 주소는 다른 호스트의 피어 설정, 서비스 바인딩, 그 정체성에 맞서 작성된 정책에 나타나기 때문입니다.
| Field | What changes when you replace it |
|---|---|
| Overlay address | Peers that pinned the old address, service bindings, and any rule written against it |
| Host name | Name-based policy and the identities other hosts expect to see |
| Groups | Which access rules match, even if the address stays identical |
| Validity window | Nothing structural, which is why renewal reloads cleanly |
그룹은 별도의 행을 둘 만합니다. 같은 혼란의 더 조용한 버전을 일으키기 때문입니다. 주소는 유지하면서 그룹을 옮긴 호스트는 재시작 후 다른 서비스에 도달할 수 있고, 이전 주소로 ping만 하는 테스트는 완전히 건강해 보이지만 그 아래의 접근 결정은 바뀌어 있습니다. 도달 가능성만이 아니라 규칙이 적용되는 서비스를 하나 확인하십시오. 터널을 확인하는 것과 정책을 확인하는 것의 차이가 여기에 있습니다.
불러온 인증서와 대체 파일을 비교하십시오
데몬이 파일을 무시했다고 가정하기 전에 둘 다 읽어 보십시오. 불러올 인증서를 출력해 바꿨다고 생각하는 필드를 확인하고, 실행 중인 설정이 그 경로를 가리키는지 다른 곳의 사본이 아닌지 확인합니다.
nebula-cert print -path /etc/nebula/host.crt
systemctl status nebula
ps -o args= -p $(pgrep -f 'nebula -config' | head -1)프로세스 인수는 사람들이 생각하는 것보다 중요합니다. -config /etc/nebula/config.yml 를 전달하는 유닛은 해당 파일의 pki.cert 항목을 읽고 있으며, 임시 디렉터리에 설치한 인증서는 아무것도 바꾸지 않습니다. 실행 중인 명령줄의 경로를 확인하고, 따라온 문서의 경로를 확인하지 마십시오. 둘이 다르면 인증서를 전혀 건드리지 않고 문제를 찾은 것입니다.
새 인증서가 다른 주소를 가지고 프로세스가 이전 주소를 유지했다면, 이제 수수께끼가 아니라 설명이 있습니다. 허용된다면 재시작하고, 주소 변경을 우발적인 것이 아니라 계획된 네트워크 변경으로 다루십시오.
주소 변경은 네트워크 변경
머신을 옮기는 계획처럼 계획하십시오. 다른 호스트가 이전 주소를 설정에 고정해 두었을 수 있고, 서비스가 명시적으로 바인딩되어 있을 수 있으며, 방화벽 규칙이 그 주소를 전제로 작성되었을 수 있습니다. 인증서를 바꾸면 호스트가 옮겨지고, 호스트가 옮겨지면 다른 곳의 전제가 무효가 됩니다.
작업하는 동안 두 번째 관리 경로를 확보해 두십시오. 방해하고 있는 것이 바로 오버레이 연결일 수 있기 때문입니다. 곧 끊을 터널 위에서 작업하는 것은 다섯 분짜리 변경을 현장 방문으로 바꾸는 고전적인 방법입니다.
재시작이 허용되는지는 호스트가 무엇을 하는지에 달려 있고, 이는 기술적 문제가 아니라 일정 문제입니다. 선택 사항이 아닌 것은 다시 불러오기를 다섯 번째 보내는 대신 재시작 요구를 인정하는 것입니다.
이전 자격 증명은 따로 폐기하십시오
한 머신에 대체 인증서를 설치해도 각 피어는 이미 알고 있는 자격 증명을 여전히 신뢰합니다. 변경 이유가 침해였다면 이전 정체성은 신뢰 또는 차단 목록 절차로 폐기해야 피어가 실제로 거부합니다.
이것은 자체 검증이 따르는 별도의 단계입니다. 새 파일이 일을 했다고 가정하는 대신 다른 호스트에서 이전 정체성이 더 이상 작동하지 않음을 확인하십시오. Nebula PKI 설정 문서는 다시 불러올 수 있는 설정과 여기서 설명한 주소 제한을 다루며, 프로덕션에 닿는 무엇이든 교체하기 전에 전체를 읽을 가치가 있습니다.