WireGuard AllowedIPs: NetworkManager가 끝내 추가하지 않은 경로

핸드셰이크 카운터는 갱신되고, 인터페이스는 주소를 유지하며, 반대편으로 보낸 ping은 어디에도 도달하지 않습니다. 이 조합이 사람들을 혼란스럽게 하는 이유는, 동작하는 핸드셰이크가 터널이 준비되었다는 증거처럼 보이기 때문입니다. 그렇지 않으며, 터널은 완전히 협상되었는데도 트래픽을 그 안으로 보낼 경로가 하나도 없을 수 있고, 이는 서로 다른 두 상태 조각이 수행하는 서로 다른 두 작업입니다. 해결은 둘 중 무엇이 빠졌는지에 전적으로 달려 있으므로 첫 단계는 그것을 알아내는 것입니다.

wg-quick은 요청받지 않아도 둘 다 수행합니다. NetworkManager의 내장 WireGuard 지원도 기본적으로 peer 경로를 설치하므로, 용의자는 비활성화된 옵션, 다른 라우팅 테이블, 또는 다른 무언가를 통해 가져온 설정으로 좁혀집니다.

경로를 쫓기 전에 터널을 확인하십시오

wg show은 인터페이스, peer, 끝점, 마지막 핸드셰이크의 경과 시간을 출력하고, ip addr show은 주소가 존재함을 확인합니다. 최근 핸드셰이크는 키와 끝점, UDP 경로가 동작한다는 뜻입니다. 고장 난 것은 그 아래, 즉 라우팅, 필터링, 이름 해석에 있습니다.

그다음 커널에 가상의 목적지가 아니라 실제 목적지로 무엇을 할지 ip route get 10.42.7.9로 물어보십시오. 답은 나가는 인터페이스와 패킷이 지닐 출발지 주소를 알려 줍니다. 물리 어댑터를 알려 준다면 핸드셰이크가 아무리 건강해 보여도 패킷은 터널로 들어가지 않습니다.

AllowedIPs는 필터이자 경로 목록입니다

AllowedIPs의 접두사는 두 가지 일을 합니다. 어떤 peer가 나가는 목적지를 나를지 고르고, 들어오는 패킷의 출발지 주소를 검증하는데, 이것이 암호 키 라우팅의 경계입니다. wg-quick에서는 경로 자동 설치도 이끌며, 바로 이 추가 동작이 같은 설정이 터미널에서는 되고 데스크톱 클라이언트에서는 되지 않는 이유입니다.

이 글 뒤에 있는 사례에서는 프로필이 내장 지원이 아니라 서드파티 플러그인을 통해 가져와졌고, 인터페이스는 접두사 경로 없이 올라왔습니다. 테이블을 나열하면 즉시 드러납니다: ip route show에는 인터페이스 주소의 연결 경로만 있고 원격 범위에 대한 것은 없습니다.

peer 경로가 아예 켜져 있는지 물어보십시오

무엇이든 바꾸기 전에 nmcli -f wireguard.peer-routes,ipv4.route-table connection show work-wg로 설정을 읽으십시오. peer-routes가 no을 보여 주면 지원되는 복구는 nmcli connection modify work-wg wireguard.peer-routes yes이며 그 뒤에 다시 연결합니다. 대신 정적 경로를 추가하면 다음 활성화까지 동작하고 조용히 사라지는데, 그 사라짐이 단서입니다. 매일 아침 수수께끼처럼 돌아오는 경로는 프로필이 설치하는 것이 아닙니다.

옵션이 이미 켜져 있다면 ip route show table all | grep 10으로 접두사가 다른 테이블에 있는지 확인하십시오. 기본 테이블이 아닌 곳의 경로는 없는 것이 아니라, 기본 테이블만 보는 조회에 보이지 않을 뿐입니다. 그 위에 중복 항목을 쌓지 말고 정책 라우팅을 고치십시오.

접두사를 실행 중인 시스템이 아니라 연결에 추가하십시오

연결 편집기에서 WireGuard 페이지는 peer와 그 AllowedIPs를 담고, IPv4 페이지는 추가 경로를 담습니다. 거기서 추가한 경로는 프로필에 속하므로 다시 연결해도 살아남습니다. 명령줄에서 같은 일은 빈 게이트웨이 형식으로 연결에 경로를 덧붙인 뒤, 변경이 적용되도록 연결을 내렸다 올리는 것입니다.

필요한 호스트를 덮는 가장 좁은 접두사를 고르십시오. 공급자의 예시 /8을 복사하면 그 안에 우연히 들어 있는 로컬 범위를 삼킬 수 있고, 그 결과 생기는 장애는 너무 넓은 경로가 아니라 고장 난 터널처럼 보입니다.

분할 터널링은 접두사 목록이 결정합니다

분할 터널 스위치는 없고, 접두사 목록이 결정입니다. 사무실 LAN용 범위 하나와 연구실 네트워크용 범위 하나를 가진 peer는 정확히 그 목적지만 터널로 보내고 나머지는 그대로 둡니다. 단일 호스트에는 /32가 필요하고, 두 사이트에서 겹치는 범위는 누군가 서브넷 번호를 다시 매길 때까지 호스트 접두사가 필요합니다.

터널로 아무것도 보내지 않기로 하는 선택은 같은 결정을 극한까지 밀어붙이는 것으로, 최소 목록은 링크를 올려 둔 채로 두고 평범한 트래픽은 평소 경로를 따릅니다. 의도를 적어 두십시오: 그렇지 않으면 다음 독자가 짧은 목록을 실수로 보고 친절히 늘려 버릴 것입니다.

라우팅 테이블의 소유자는 하나

wg-quick과 NetworkManager는 둘 다 인터페이스의 경로를 자기가 소유한다고 믿습니다. wg-quick용으로 작성된 설정을 가져온 뒤 wg-quick 서비스까지 시작하면, 어느 쪽이 마지막으로 실행되었는지에 따라 동작이 달라지는 중복되거나 충돌하는 항목이 생깁니다. 소유자를 하나 고르고 다른 쪽을 제거하되, NetworkManager가 연결을 관리한다면 그 인터페이스의 wg-quick 유닛을 비활성화하고 같은 장치에 두 번째 프로필을 절대 추가하지 마십시오.

분할이 목적지가 아니라 물리 어댑터를 따라야 한다면 정책 라우팅으로 넘어간 것이며, 정책 라우팅에도 작성자가 하나만 필요합니다. ip route get을 반복하고, 그다음 원격 접두사 안의 호스트에 그것이 고른 출발지 주소를 출력하는 무언가로 도달해 확인하십시오. 프로필이 둘 중 하나를 담고 있다면 IPv6와 DNS를 따로 확인하십시오.