재귀 라우팅: 터널이 자신의 패킷을 가로챌 때

터널이 올라오고 로그에는 핸드셰이크가 완료되었다고 찍히지만, 일 초 뒤 같은 세션이 끊기고 루프처럼 다시 연결됩니다. 이 패턴에는 분명한 원인이 있습니다 — 서버로 가는 경로가 이제 터널 안쪽을 가리키므로, 터널을 실어 나르는 패킷이 터널을 통해 전송되는 것입니다. 인증은 아무것도 바뀌지 않았기 때문에 자격 증명을 다시 넣어도 소용이 없습니다. 경로가 바뀌기 전과 후의 바깥 경로를 비교하면 재귀가 바로 보입니다.

먼저 바깥 경로를 확인하십시오

관련된 패킷은 하나가 아니라 둘입니다. 안쪽 패킷은 애플리케이션의 것이며 암호화되어야 하고, 바깥 패킷은 서버로 향하며 터널에 의존하지 않는 경로로 도달해야 합니다.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

터널이 올라온 뒤 커널에 서버 주소로 가는 경로를 물어보고, 기본 경로가 바뀐 뒤에 다시 물어보십시오. 다음 홉이 터널 장치로 떨어진다면 그것이 바로 재귀이며 패킷 캡처 없이도 보입니다. 인터페이스 바인딩, 마크, 네트워크 네임스페이스가 있으면 단순 조회는 불완전해질 수 있으므로 클라이언트 자신이 쓰는 문맥으로 확인하십시오. 답이 맞아 보이는데도 세션이 계속 루프한다면, 메인 테이블만이 아니라 라우팅 정책 규칙을 읽어 보십시오.

세션이 잠깐 버티는 이유

새 경로가 설치되기 전에 핸드셰이크가 끝나므로 첫 몇 초는 정상으로 보입니다. 클라이언트가 기본 경로를 추가하는 순간 다음 바깥 패킷이 그 경로를 따라, 그 패킷이 지나가야 할 인터페이스로 들어갑니다. 서버는 아무것도 받지 못하고 클라이언트는 다시 보내며, 시도는 시간 초과로 끝나거나 세션을 끊고 처음부터 시작합니다.

이 순서가 노트북에서는 되고 라우터에서는 실패하는 이유, 그리고 연결 시점이 아니라 트래픽이 시작될 때 장애가 생기는 이유를 설명하고, 루프도 설명합니다. 재시작할 때마다 경로가 불가능하게 만들기 전에 세션이 다시 살아나는 것입니다.

끝점 예외의 주인을 찾으십시오

지원되는 클라이언트는 스스로 예외를 마련합니다. 원래 게이트웨이를 거쳐 서버로 가는 호스트 경로를 두거나, 바깥 소켓을 터널 밖에 두는 마크를 씁니다만, 문제는 다른 무언가가 그것을 지웠는지 덮어썼는지입니다.

경로 기반 IPsec에서는 어떤 패킷이 터널로 들어가는지 결정하는 정책 선택자를 살피고 피어 주소가 제외되어 있는지 확인하십시오. WireGuard에서는 인터페이스의 방화벽 마크와 정책 규칙이 전송 패킷을 터널 밖에 두므로, 손으로 추가한 기본 경로가 그 배치를 깨뜨릴 수 있습니다. 두 번째 VPN 프로필이나 기본 경로를 다시 쓰는 관리 스크립트가 흔한 원인입니다. 넓은 우회 규칙을 하나씩 추가하는 것이 늘 있는 결과이며, 그것은 라우팅 버그를 아무도 유지할 수 없는 표로 바꿔 놓습니다.

네트워크가 바뀐 뒤 다시 확인하십시오

Wi-Fi 게이트웨이를 거치는 호스트 경로는 기기가 다른 네트워크로 옮겨가기 전까지는 맞습니다. 그러면 같은 증상이 설정을 전혀 바꾸지 않았는데도 돌아옵니다.

끝점 주소와 연결 전후의 경로, 그리고 각각이 사용한 인터페이스를 기록하십시오. 이 세 가지 사실이 보통 클라이언트 버그와 덮어쓰기를 갈라 주며, 기록한 사람이 떠난 뒤에도 남습니다.

새 네트워크에서 다시 연결하고 같은 조회를 반복하십시오. 예외가 또 빠져 있다면 고칠 곳은 그것을 가진 프로필이며, 장애 중에 입력한 일회성 명령이 아닙니다.