WireGuard: 서브넷 변경 후 피어로 가는 경로 없음 — 두 가지 출구

wg show의 핸드셰이크는 새것이고, 엔드포인트도 맞고, 키는 한 번도 바뀌지 않았는데 ping은 여전히 피어로 가는 경로가 없다고 말한다. 한 시간 전에 터널 서브넷을 바꿨다. 이 증상은 키 문제가 아니라 프리픽스 불일치의 서명이다. WireGuard는 핸드셰이크를 마친 뒤 출발지 주소가 수신 피어가 받아들일 범위와 더 이상 맞지 않아 데이터를 버렸다. 서브넷 변경을 적용하는 방법은 두 가지가 있고, 실패하는 지점도 서로 다르다.

변경을 적용하는 두 가지 방법과 각각의 비용

방법 A는 제자리 재번호다. 인터페이스 주소, 피어 범위, 경로, 설정의 모든 사본을 편집한 뒤 다시 불러온다. 방법 B는 새 프리픽스에 두 번째 인터페이스를 기존 것 옆에 만들고, 피어를 옮기고, 트래픽이 실제로 이동한 뒤 기존 인터페이스를 제거하는 것이다.

방법 A를 위험하게 만드는 것은 절반만 적용된 상태다. 고장 난 것처럼 보이지 않기 때문이다. 인터페이스는 올라오고 핸드셰이크도 성공하며 데이터 경로만 실패한다. 방법 B는 일이 더 들지만 모든 참조를 찾는 동안 동작하는 경로를 살려 둔다.

당신 쪽에서 함께 움직여야 하는 것

로컬 호스트의 네 가지가 같은 서브넷을 설명하며, 하나를 바꾸는 것은 모두를 바꾸는 것이다. 인터페이스 주소, 각 피어의 AllowedIPs, 시스템이 그 목적지에 쓰는 경로, 그리고 관리 도구가 대신 설정하는 모든 것이다. wg-quick에서는 마지막 두 가지가 인터페이스가 올라올 때마다 설정에서 생성되므로, 오래된 사본이 조용히 예전 프리픽스를 되돌려 놓는다.

둘 중 하나를 믿는 대신 설정된 것과 실제로 살아 있는 것을 비교한다.

wg show
wg showconf wg0
ip addr show wg0
ip route get 10.90.0.5

경로 조회는 사람들이 건너뛰는 단계다. 커널이 어떤 목적지에 실제로 무엇을 할지 답하며, 관리 도구나 컨테이너 런타임이 남긴 더 구체적인 경로도 포함한다. 터널과 다른 인터페이스를 보고한다면 설정이 문제가 아니다.

실행 중인 인터페이스에서는 터널을 뜯지 않고 편집한 파일을 적용한다.

wg syncconf wg0 <(wg-quick strip wg0)

그러면 피어와 범위가 제자리에서 갱신된다. 인터페이스 주소나 경로는 갱신하지 않는다. 그것들은 WireGuard 설정이 아니기 때문이다. 따라서 재번호에는 인터페이스 재생성이나 ip로 주소 변경이 여전히 필요하고, 그다음 경로를 다시 확인해야 한다.

먼 쪽에서 함께 움직여야 하는 것

서브넷 변경이 보통 죽는 곳이 여기다. AllowedIPs는 경로 힌트만이 아니다. 피어가 제시할 수 있는 출발지 주소 목록이기도 하다. 클라이언트를 재번호하면서 서버의 AllowedIPs를 예전 프리픽스에 두면, 서버는 핸드셰이크를 받아들이고 암호화된 패킷을 받은 뒤 버린다. 내부 출발지가 그 피어에 연결된 어떤 범위와도 맞지 않기 때문이다. 오류는 기록되지 않고 클라이언트는 시간 초과를 본다.

그러니 수신 쪽을 의도적으로 갱신한다. 서버의 피어 항목에 새 클라이언트 프리픽스를 적고, 서버 자신의 반환 경로가 그 프리픽스에 대해 터널을 가리키게 하고, 서버 뒤의 하위 네트워크가 새 경로를 배우게 한다. 예전 범위를 지정한 방화벽 정책도 같은 처리가 필요하고, 출발지 기반 선택을 하는 모든 것도 마찬가지다.

두 실패를 구분하는 진단은 싸다. 핸드셰이크가 새것인데 데이터가 없으면 터널은 살아 있고 내부 주소 체계가 어긋난 것이다. 핸드셰이크가 전혀 없으면 도달성이나 키를 보는 것이다. 프리픽스 문제로 키를 돌리지 말라. 동작하던 유일한 것을 초기화한다.

편집보다 오래 사는 오래된 사본

파일을 편집하는 것은 실행 중인 시스템을 바꾸는 것과 같지 않고, 사본은 사람들이 생각하는 것보다 많다. 인터페이스를 소유한 유닛이나 관리 도구, 다른 디렉터리에 있는 같은 이름의 두 번째 프로필, 설정이 이미지에 구워진 컨테이너, 자체 편집본을 보관하는 라우터 UI, 그리고 시작할 때 저장된 터널을 다시 가져오는 클라이언트 앱이다. 어느 것이든 변경이 끝나 보인 뒤에 예전 프리픽스를 복원할 수 있다.

이름도 이동한다. 숫자 경로는 되는데 호스트 이름이 실패한다면 내부 DNS 레코드나 서비스 설정이 아직 예전 터널 주소를 가리키는 것이다. 모든 피어 범위를 넓히는 대신 참조를 고쳐야 한다. 넓히면 진짜 문제를 덮고 동시에 출발지 ACL까지 키운다.

작업하는 동안 복구 경로를 하나 열어 둔다. 호스트로 들어가는 두 번째 길, 시리얼 콘솔, 또는 설정 파일의 예약된 롤백이다. 변경 중인 머신에서 자신을 잠그는 터널 변경이 이 작업을 밤샘으로 만드는 가장 흔한 길이다.

둘 중에서 고르기, 그리고 전환 확인

모든 피어가 내 것이고 수가 적으며 짧은 중단이 허용된다면 A를 고른다. 피어가 내가 통제하지 않는 원격의 손이고, 사이트 간 링크가 살아 있어야 하고, 모든 사본이 한 번에 갱신된다고 보장할 수 없다면 B를 고른다. 그 경우 새 프리픽스를 두 인터페이스에 넣고, 피어를 하나씩 옮기고, 새쪽 트래픽을 지켜본 다음에야 기존 인터페이스와 그 경로를 제거한다.

어느 쪽이든 네 가지 확인이 통과하면 변경은 끝난다. 핸드셰이크가 새것이고, 새 프리픽스 목적지의 경로 조회가 터널을 지목하고, 수백 바이트의 페이로드가 양방향으로 오가고, 호스트나 관리 도구를 재시작한 뒤에도 같아야 한다. 참조는 wg(8) 설명서 이며, AllowedIPs가 각 방향에서 무엇을 뜻하는지 알려 주고, 증상을 없애려고 범위를 넓히기 전에 다시 읽을 가치가 있다.

• 핸드셰이크는 새것인데 데이터가 없다면 키를 만지기 전에 수신 쪽 AllowedIPs를 본다.
• 경로 조회가 엉뚱한 인터페이스를 가리킨다면 경로의 주인은 관리 도구나 컨테이너이며 당신의 파일이 아니다.
• 숫자 주소는 좋고 호스트 이름이 깨졌다면 예전 참조이며 라우팅 루프가 아니다.
• 재시작 뒤에도 새 프리픽스를 쓸 때에야 변경이 완전해진다.