WAN IP가 바뀌고 터널이 끊겼다: 순서대로 점검하기

WAN 이벤트를 기록한 뒤, 그에 따르지 않은 것을 봅니다. 오래된 변환 항목, 예전 게이트웨이에 묶인 경로, 아직 예전 주소로 보내는 피어입니다.

터널이 끊기고 라우터가 재연결을 기록했지만 LAN에서는 아무것도 움직이지 않았습니다. 새 WAN 주소는 클라이언트의 원본 주소가 바뀌고 예전 NAT 상태가 더 이상 존재하지 않는 원본을 가리키며 원격 피어가 여전히 이전 주소로 보낼 수 있는 상태에서 내부를 바꾸지 않고 외부 연결을 무효화합니다. 복구는 정상 동작이며, 유용한 질문은 어떤 상태가 갱신되지 않았는가입니다.

로그를 읽기 전에 이벤트에 이름을 붙이십시오

액세스 계층에서 실제로 무슨 일이 있었는지 확인하십시오. ISP 임대 갱신은 하나의 이벤트입니다. 다시 연결된 PPPoE 세션은 다른 이벤트입니다. 재부팅된 광 모뎀, 또는 한 업링크에서 다른 업링크로의 WAN 페일오버는 외부 주소나 그 경로를 세 번째 방식으로 바꿉니다. 같은 이벤트가 아니며 같은 잔여물을 남기지 않습니다.

VPN 로그의 재연결 줄도 WAN 변경의 증거가 아닙니다. 유휴 시간 초과, 재인증 간격, 죽은 피어 감지는 모두 주소 변경 없이 재연결을 만듭니다. 무엇이든 결론 내리기 전에 액세스 로그의 타임스탬프를 VPN 로그와 비교하고, 밤사이 일어난 변경까지 잡을 수 있도록 비교 창을 충분히 넓게 유지하십시오.

로밍과 재연결은 서로 다른 프로토콜입니다

WireGuard는 인증된 로밍을 프로토콜에 내장하여, 피어가 새 원본 주소에서 올바르게 인증된 패킷을 받으면 그 피어의 엔드포인트를 갱신합니다. WireGuard 빠른 시작은 이를 가능하게 하는 피어 구성을 설명하며, 그래서 바뀌는 주소의 클라이언트가 눈에 띄는 재시작 없이 복구되는 경우가 많습니다.

OpenVPN은 기본적으로 다르게 동작합니다. UDP 세션은 끝나고 다시 연결될 수 있으며, 선택적인 float 동작은 구성이 허용하는 곳에서 인증된 피어가 새 주소에서 계속하도록 합니다. TCP 기반 터널은 연결 자체가 주소 쌍에 묶여 있기 때문에 더 엄격합니다. 그 차이가 복구가 보이지 않게 보일지, 매번 로그에 자신을 알릴지를 결정합니다.

어느 동작도 내부 애플리케이션에 대해 아무것도 말하지 않습니다. 복구된 터널은 피어가 이미 죽었다고 본 TCP 세션을 되살리지 않습니다.

터널이 소유하지 않는 상태

변환과 라우팅 상태는 사람들을 놀라게 하는 방식으로 재연결을 견딥니다. 예전 원본을 위해 만들어진 conntrack 항목은 응답 경로를 더 이상 존재하지 않는 주소에 고정하며, 터널이 돌아온 때가 아니라 자체 일정에 따라 만료됩니다. 터널 서비스를 재시작해도 그 대기는 짧아지지 않으므로, 수리된 링크가 한동안 여전히 끊긴 것처럼 보일 수 있습니다.

경로와 정책 규칙은 예전 게이트웨이나 인터페이스를 참조할 수 있습니다. WAN 전환 전에 올바르던 규칙 집합이 지금은 내려간 장치를 가리킬 수 있고, 그러면 연결되었다고 보고하는 터널과 어디로도 가지 않는 트래픽이 생깁니다. 호스팅하는 서버의 동적 DNS는 새 원본을 얻는 클라이언트와는 별개의 문제입니다. 원격 클라이언트가 여러분을 찾으려면 레코드를 갱신해야 하며, 상류 변환이 전달하지 않을 주소를 클라이언트 측 구성으로 보상할 수는 없습니다.

점검을 바깥에서 안쪽으로 배열하십시오

아래 순서는 외부 연결에서 안쪽으로 진행되며, 첫 실패 단계에서 멈출 때 유용한데, 각 점검은 그 위 계층을 배제하기 때문입니다. 결함이 뻔해 보여도 이 순서를 지키십시오.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

첫 번째 명령은 각 피어의 현재 엔드포인트와 핸드셰이크 경과 시간을 보여 줍니다. 두 번째와 세 번째는 외부 인터페이스와 엔드포인트로 가는 경로가 아직 말이 되는지 보여 줍니다. conntrack 수는 이전 주소에서 남은 상태에 대한 대략적인 점검이고, 저널은 재연결 사유가 기록되는 곳입니다.

다음으로 라우터가 아니라 LAN 클라이언트에서 시험하십시오. 라우터 자체가 보낸 ping은 전달되는 트래픽과 다른 경로를 사용하므로, 라우터에서의 성공한 ping은 터널이 존재함을 증명할 뿐 클라이언트 도달성에 대해서는 아무것도 말하지 않습니다.

기대하는 동작을 정하고 적어 두십시오

대부분의 배포에서 재연결은 올바른 동작이므로 목표는 이를 막는 것이 아닙니다. 대신 끊긴 동안 트래픽을 멈추거나 붙잡아 두거나 다른 경로로 페일오버할지 정하십시오. 그 결정은 방화벽과 라우팅 정책에 속하며 VPN 프로필에 속하지 않습니다.

일주일 동안 액세스 이벤트와 재연결 시각을 함께 기록하십시오. 대응하는 액세스 이벤트 없이 반복되는 변경은 액세스 서비스를 가리키며, VPN 프로필을 바꿔도 계속 재협상하는 업링크는 고쳐지지 않습니다. 같은 분에 기록된 한 쌍의 항목이 그 사건의 질문을 정리하고 다음 사건에 기준선을 줍니다.

관련 글