WireGuard 피어가 잘못된 WAN으로 나갑니다: 다섯 가지 점검 순서

업링크 두 개, 게이트웨이 하나, 그리고 트래픽이 자꾸 백업 회선에 나타나는 WireGuard 피어가 있습니다. 핸드셰이크는 내내 정상입니다. 그래서 이 증상을 라우팅 문제가 아니라 WireGuard 결함으로 잘못 읽기 쉽습니다.

아래 점검을 순서대로 수행하십시오. 각각 정지 조건이 있으며, 앞질러 가면 대개 자신감 있게 틀린 답이 나옵니다.

핸드셰이크와 전달된 흐름을 분리하십시오

암호화된 피어 교환에는 서버의 공용 주소로 가는 엔드포인트 경로가 있습니다. 전달된 클라이언트 트래픽은 목적지가 다르고 마크나 정책 규칙으로 선택될 수 있습니다. 하나의 인터페이스를 공유하는 두 가지 라우팅 결정입니다. 하나를 다른 하나에 대한 증거로 다루는 것이 첫 번째 실수입니다.

핸드셰이크로 추론하고 있다는 것을 알아차리는 즉시 멈추십시오. 그것은 엔드포인트 경로에 대한 증거일 뿐입니다.

기본 테이블이 아니라 정책 규칙을 읽으십시오

기본 테이블은 어떤 정책 규칙도 일치하지 않을 때 벌어지는 일을 보여 줍니다. 소스, 마크, 목적지로 라우팅하는 게이트웨이에서는 결정하는 규칙이 다른 곳에 있습니다. 평범한 테이블은 얼핏 완전히 합리적으로 보일 수 있지만 실제 선택은 그 위에서 이루어집니다.

ip rule show
ip route show table main
ip -4 route get 203.0.113.9 from 10.30.8.2

정책 규칙과 그것이 가리키는 테이블을 읽으십시오. 그다음 테스트 흐름에 어떤 규칙이 일치하는지 확인하십시오. 더 이상 의도한 업링크를 나르지 않는 인터페이스를 가리키는 규칙은 세부 사항이 아니라 발견 사항입니다. 마지막의 경로 조회는 테이블을 읽고 추측하는 것보다 훨씬 빠르게 답을 보여 줍니다.

마크와 변환을 함께 점검하십시오

정책 라우팅은 체인에서 더 앞서 설정된 패킷 마크에 의존합니다. 마킹 규칙이 트래픽을 놓치면 흐름은 메인 테이블로 떨어지고 그곳의 기본값으로 나갑니다. 전달된 패킷은 로컬에서 생성된 트래픽용으로 작성된 체인을 자주 건너뜁니다.

nft list chain inet filter prerouting
conntrack -L -s 10.30.8.2 2>/dev/null | head
ip -s link show dev eth1

변환은 흐름을 나르는 업링크와 일치해야 합니다. 패킷이 백업 회선으로 나가는데 기본 주소로 변환하는 규칙은 흐름이 한 번도 쓰지 않은 인터페이스로 향하는 응답을 만듭니다. 변환 규칙 자체의 인터페이스 조건을 점검하십시오. 무조건 규칙은 두 번째 업링크가 쓰일 때까지 동작하고, 그다음에는 간헐적으로 보이는 방식으로 실패합니다.

어느 인터페이스가 응답을 나르는지 보십시오

요청 하나가 실행되는 동안 두 업링크 모두에서 캡처하십시오. 어느 인터페이스가 요청을 나르고 어느 쪽이 응답을 나르는지 적으십시오. 비대칭 경로는 예측하기보다 보는 것이 훨씬 쉽습니다.

응답이 잘못된 업링크로 도착하면 문제는 WireGuard에서 연결 추적이나 변환으로 옮겨 간 것입니다. 피어 설정을 바꿔도 고쳐지지 않습니다.

되돌아갈 길을 두고 한 가지만 바꾸십시오

게이트웨이에서 정책 규칙을 편집하기 전에 콘솔이나 대역 외 접근을 확보하십시오. 변경은 한 번만 하고, 같은 승인된 목적지를 시험한 뒤 다시 연결해 핸드셰이크가 여전히 의도한 엔드포인트 경로를 쓰는지 확인하십시오. 두 번째 주소 체계에도 숫자 테스트를 추가하십시오. v4만 다루는 정책은 같은 실수를 남겨 두기 때문입니다.

각 흐름이 어느 업링크를 썼는지 기록하십시오. 그 기록은 다음 보고를 반나절이 아니라 두 분 점검으로 바꿉니다. 네임스페이스와 라우팅에 관한 WireGuard의 노트 는 엔드포인트 경로를 터널링된 트래픽과 의도적으로 분리하는 방법을 설명하며, 보통 기본 경로 우회책을 복사하는 것보다 깔끔합니다.