NetworkManager와 wg-quick: WireGuard 경로의 주인은 누구인가?

WireGuard 파일에서 AllowedIPs를 바꾸고 터널을 다시 시작해도 라우팅 테이블은 이전과 똑같아 보입니다. 흔한 대응은 문제되는 경로를 지우고 넘어가는 것이고, 이는 다음 재연결이 그것을 되돌려 놓을 때까지 작동합니다. 편집한 파일이 지금 보고 있는 상태를 만든 객체와 같다는 보장은 없습니다. 두 관리자가 한 머신에서 같은 프로토콜을 실행할 수 있으며, 한 번에 둘 중 하나만 인터페이스를 소유합니다.

오해: 머신에는 WireGuard 구성이 하나뿐이다

wg-quick은 /etc/wireguard/ 아래의 파일을 읽고 인터페이스를 올릴 때 그것을 구성합니다. NetworkManager는 자체 keyfile 형식으로 연결 프로필을 저장하고 활성화할 때 렌더링하며, wg-quick 파일을 가져오면 값이 그 프로필로 복사될 뿐 링크되지는 않습니다. 프로필이 더 이상 그것을 읽지 않으므로 이후 원본을 편집해도 아무것도 바뀌지 않습니다. 따라서 같은 피어와 키 목록이 두 번 존재할 수 있고, 두 번째 사본이 적용됩니다.

기억할 만한 징후: 재부팅은 견디지만 다시 가져오기는 견디지 못하는 편집은 한 저장소에서 왔고, 재부팅 때 사라지는 편집은 다른 저장소에서 왔습니다.

실용적인 예 하나면 분리가 분명해집니다. 다음을 비교하세요: nmcli connection show 그리고 systemctl status wg-quick@wg0, 그다음 경로가 실제로 어느 인터페이스에 매달려 있는지 확인하세요. 서비스는 죽어 있고 인터페이스는 올라와 있다면, 파일이 뭐라고 하든 프로필이 일을 하고 있는 것입니다.

오해: 라우팅 규칙은 WireGuard의 일부다

커널의 WireGuard 장치는 피어와 키를 알지만 정책 라우팅에 대해서는 아무것도 모릅니다. 보이는 ip rule 항목과 추가 테이블은 인터페이스를 올린 도구가 설치한 것입니다. wg-quick은 fwmark와 전용 테이블, 그리고 그것을 가리키는 규칙을 추가할 수 있지만, NetworkManager는 자체 ipv4 설정을 통해 경로를 설치하고 DNS는 시스템이 사용하는 리졸버 백엔드에 맡깁니다. 같은 터널, 다른 부작용.

무언가를 바꾸기 전에 ip rule 와 ip route show table all 를 읽고 각 경로가 어느 테이블에 있는지 기록하세요. 구성하지 않은 테이블 번호는 그것을 만든 도구에 대한 강한 단서입니다.

오해: 경로를 삭제하면 고쳐진다

실행 중에 삭제된 경로는 소유자가 다음 활성화 때 다시 설치할 경로이며, 노트북이 깨어나거나 링크가 흔들리거나 서비스가 재시작되거나 NetworkManager가 자동 연결될 때 등 당신 없이도 활성화가 일어날 수 있습니다. 그래서 같은 경로가 돌아오고, 그래서 임시방편이 틀린 것이 아니라 신뢰할 수 없게 느껴집니다. 먼저 관리자를 식별하고, 그다음 그 관리자가 실제로 읽는 입력을 바꾸세요.

다시 연결하고 관련 서비스를 재시작하는 것이 진짜 수정과 겉만 깔끔한 수정을 가르는 시험입니다.

소유자를 하나 고르고 다른 쪽을 제거하세요

배포가 지원하는 관리자를 고르고, 유휴 상태로 남기를 바라지 말고, 경쟁하는 활성화를 문서화된 제어 수단으로 비활성화하세요. 마스크된 wg-quick 서비스나 삭제된 NetworkManager 프로필은 명시적이지만, 둘 다 활성화한 채 서로 경쟁시키는 것은 그렇지 않습니다. 무언가를 비활성화하기 전에 원격 세션을 나르는 인터페이스가 바로 제거하려는 것일 수 있으므로 작동하는 접근을 확보하세요.

변경 후 포함된 트래픽과 제외된 트래픽, 그다음 DNS, 그다음 한 번 재부팅하여 검증하세요. 단일 관리자로 재부팅 후에도 상태가 유지되면 우연이 아니라 소유자가 있는 것입니다.

어떤 설정이 계속 돌아온다면 결과를 삭제하는 것을 멈추고 그것을 계속 만들어 내는 프로세스를 찾으라는 일반 규칙은 WireGuard 밖에서도 기억할 가치가 있습니다.