공용 IP가 바뀌자 VPN이 트래픽을 통과시키지 못했다

ISP의 재접속이나 상위 구간의 변환 변경은 VPN 세션의 공용 출발지를 바꾸지만, 클라이언트의 로컬 사설 주소는 보통 원래 그대로 남습니다. 그러면 터널은 연결된 것처럼 보이는데 그 안으로 유용한 것이 지나가지 않습니다. 두 관찰이 동시에 참이라는 점이 이 보고를 혼란스럽게 만듭니다.

네 가지 점검을 순서대로 진행하고 처음 실패하는 지점에서 멈추세요.

실제로 바뀐 주소는 무엇인가

로컬 인터페이스 상태를 원격 끝점이 보는 출발지와 비교하되, 살펴볼 권한이 있는 지점에서 하세요. 새 공용 주소가 새 로컬 게이트웨이를 뜻하지는 않으며, 로컬 인터페이스의 변화도 공용 출발지가 이동했다는 것을 보장하지 않습니다. 그 사이의 변환이 있으므로 둘은 독립적인 사실입니다. 정확한 경로와 관찰한 시각을 기록하세요. 오래된 보고에서 복사한 위치 정보 라벨은 다른 질문에 답하기 때문입니다.

바깥 출발지가 바뀌었는지, 안쪽 터널 주소가 바뀌었는지, 아니면 둘 다인지 분명히 물으세요. 첫 번째만이 더 이상 존재하지 않는 경로로 계속 보내는 상대를 설명합니다.

이동은 프로토콜이 처리하게 두세요

상대가 이동했음을 알아내는 방식은 프로토콜마다 다릅니다. 그리고 그 차이는 애초에 개입해야 하는지에 영향을 줍니다. WireGuard는 해당 상대의 키로 인증되는 패킷을 받으면 그 상대의 끝점을 갱신하므로, 설정 없이도 주소 변경을 흡수할 수 있습니다. IKEv2에는 같은 목적의 MOBIKE가 있어 양쪽 끝이 지원하면 쓸 수 있습니다. 오래된 설계는 대신 터널을 다시 만들어 복구합니다.

해서는 안 되는 일은 인증되지 않은 메시지를 상대의 신원이 이동했다는 증거로 받아들이는 것입니다. 새 주소를 주장하는 데이터그램을 위조하는 것은 쉬우며, 클라이언트는 공격자의 끝점으로 유도될 수 있다고 믿게 됩니다. 수단은 인증된 프로토콜이고, 알림은 아닙니다.

wg show wg0 endpoints
wg show wg0 latest-handshakes
conntrack -L -p udp --dport 51820 | head -n 10

오래된 바깥 바인딩을 지우세요

프로토콜이 로밍을 지원하는데도 트래픽이 계속 실패하면, 장애물은 대개 중간에 있는 상태 유지 장비입니다 또는 먼 쪽의 정책입니다. 예전 흐름을 추적하던 방화벽은 오래된 항목을 남길 수 있고, 예전 출발지에 묶인 서버 측 접근 규칙은 새 것을 조용히 버립니다. 매핑을 지우고 규칙을 다시 확인하는 편이 자격 증명을 바꾸는 것보다 빠릅니다.

조사하는 동안 필요한 차단은 유지하세요. 터널이 복구되는지 시험하려고 정책을 크게 열어도 원인에 대해 배우는 것이 없고, 배포를 발견했을 때보다 나쁘게 남깁니다.

새 요청으로 다시 시험하세요

변경 전에 맺은 애플리케이션 세션은 살아남지 못합니다. 기반이 된 네 개 항목이 더 이상 존재하지 않기 때문입니다. 복구 후 새 요청을 만들어 완료되는지 확인하세요. 오래된 다운로드가 더 진행되지 않는 것을 보고 터널이 여전히 고장이라고 결론 내리지 마세요. 바로 이 구분이 이런 보고의 상당 부분을 해결합니다.

그다음 진단의 두 부분을 모두 기록하세요. 상위에서 무엇이 바뀌었는지, 어떤 지원되는 복구 단계가 흐름을 되살렸는지. 다음에는 더 빨라질 것이고, 그 메모가 더 빠르게 만듭니다.

새 요청이 성공하고 예전 요청이 다시 시작되지 않는다면, 터널은 고쳐졌고 애플리케이션은 다시 연결하기만 하면 됩니다.