VPN 이 자꾸 끊기나요? 이 순서대로 점검하세요

클라이언트를 다시 설치하기 전에 세 가지를 적어 두세요: 터널이 얼마나 유지되었는지, 끊길 때 클라이언트가 무엇이라고 했는지, 그 사이에 기기가 잠들었거나 네트워크를 바꿨는지입니다. 그 메모가 나중에 남는 유일한 증거이며, 재설치는 보통 그것을 지웁니다. 반복되는 간격으로 끊기면 타이머나 상태 만료이고, 무작위 시점에 끊기면 경로 문제입니다. 아래 순서를 따르면 세 가지를 한꺼번에 바꾸고 아무것도 배우지 못하는 일을 피할 수 있습니다.

첫 단계: 간격과 오류 문구를 기록하세요

공급업체 대시보드가 아니라 클라이언트 자체 로그에서 시작하세요. Linux 클라이언트에서는 서비스 로그와 터널의 실시간 상태로 대부분이 설명됩니다:

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

아이콘 색이 바뀐 순간만이 아니라 마지막으로 성공한 핸드셰이크의 시각과 트래픽이 멈춘 순간을 기록하세요. 나중에 끊겼다고 말하는 GUI 클라이언트는 커널이 몇 초 전에 도달한 상태를 보고할 뿐일 수 있습니다.

오류의 표현을 그대로 보존하세요. 타임아웃, 인증 거부, 어댑터나 드라이버 오류는 서로 다른 세 계층을 가리키며, 이 문제에서 낭비되는 노력의 대부분은 이들을 하나로 취급하는 데서 나옵니다. 해당 줄을 그대로 메모에 복사하세요.

둘째 단계: 프로필이 아니라 변수 하나를 바꾸세요

기기와 프로필은 고정하고 기기를 다른 액세스 네트워크, 예를 들어 휴대폰 핫스폿으로 옮기세요. 클라이언트를 경로에서 분리하는 가장 저렴한 테스트이며, 원래 실패 간격을 덮을 만큼 오래 실행하세요. 잠깐 안정된 것으로는 삼십 분에 일어나는 끊김을 전혀 증명하지 못합니다.

Ethernet 포트가 있는 노트북은 Wi-Fi 를 완전히 배제한 두 번째 비교를 제공합니다. 두 대안 모두에서 터널이 유지된다면 원래 액세스 네트워크를 의심할 만합니다: 액세스 포인트 간 로밍, 변환 테이블이 만료되는 가정용 공유기, 장기 흐름을 재설정하는 상위 링크 같은 원인입니다.

어떤 변수를 바꿨는지 적으세요. 다른 모든 조건이 같을 때만 비교가 성립하며, 여기에는 서버 엔드포인트와 시간대도 포함됩니다.

셋째 단계: 간격을 계층에 대응시키세요

좋은 세션의 길이는 가지고 있는 가장 정보량이 많은 단일 숫자입니다. 타이머를 건드리기 전에 이 목록과 대조해 보세요:

• 잠들거나 재개한 뒤 끊김: 터널 상태는 일시 중단을 넘겼지만 인터페이스는 넘기지 못했습니다. 재개 시 클라이언트의 재연결 동작과 서비스가 터널을 다시 시작하는지 트래픽을 기다리는지 확인하세요.
• 유휴 상태에서만 끊김: 중간의 무언가가 흐름의 수명을 끝냈습니다. keepalive 는 바로 이 경우를 위해 있습니다.
• 고정된 세션 수명에서 끊김: 재인증이나 키 갱신 이벤트이며 경로 장애가 아닙니다. 정확히 그 간격에 로그의 명시적 거부가 단서입니다.
• 큰 전송이나 큰 페이지 중 끊김: MTU 와 단편화를 의심하고 유휴 타이머를 의심하지 마세요.

유휴 상황에서는 설정이 프로토콜마다 다르고 양쪽 끝이 모두 중요합니다. 서버의 OpenVPN keepalive 10 60 은 10 초마다 핑을 보내고 핑이 없으면 60 초 뒤 연결을 다시 시작하며, NAT 뒤의 WireGuard 클라이언트는 피어 블록에서 PersistentKeepalive = 25 을 사용합니다. OpenVPN 은 타이머로 데이터 채널을 다시 협상하며, reneg-sec 은 2.x 에서 기본값이 3600 초입니다.

다른 공급업체 안내서에서 공격적인 값을 복사하지 마세요. 손실이 있는 모바일 링크에서 짧은 타임아웃은 막아야 했던 끊김을 오히려 만들어 내며, 서버가 밀어 넣는 값은 클라이언트 프로필에서 설정한 값을 덮어씁니다.

넷째 단계: 지원되는 대안 하나를 비교하세요

운영자가 UDP 와 TCP 프로필을 모두 제공한다면 같은 기기와 네트워크로 다른 쪽을 실행하세요. 복사한 프로필에서 전송 방식을 편집하는 대신 실제로 맞는 파일을 사용하세요. UDP 가 재설정되는 경로에서 TCP 프로필이 안정적이라면 문제를 그 경로로 좁힐 수 있지만, TCP 가 어디서나 더 나은 전송이라는 증명은 아닙니다.

같은 논리가 엔드포인트에도 적용됩니다. 다른 서버를 시도하고 원래 결과를 옆에 두세요. 한 출구만 세션을 재설정한다면 그것은 그 엔드포인트에 대한 증거이며, 노트북의 모든 어댑터를 다시 만드는 이유는 아닙니다.

어떤 변경 후든 원래 트리거를 반복하고 트래픽이 실제로 어디로 가는지 확인하세요. 되찾은 인터넷 접속은 터널 안의 트래픽과 같은 결과가 아니며, 조용히 직접 경로로 떨어진 클라이언트는 브라우저에서는 정상으로 보입니다.

수정을 검증하고 롤백을 남겨 두세요

수정은 성공한 연결이 아니라 원래 트리거를 재현해 검증합니다. 이전 실패 간격을 넘겨 터널을 유휴 상태로 두고, 한 번 일시 중단했다가 재개한 뒤 핸드셰이크 경과 시간과 출구 주소를 확인하세요:

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

새 동작이 온전한 근무일을 버틸 때까지 이전 프로필과 이전 타이머 값을 유지하세요. 끊김이 돌아오면 백업을 복원하고, 두 번째 시도가 알려진 상태에서 시작하도록 변경을 하나씩 다시 적용하세요.

로그가 깨끗한데 터널이 여전히 반복되는 간격으로 끊긴다면 다음 정류장은 그 세션의 서버 측입니다. 클라이언트 세션 식별자와 정확한 끊김 시각을 함께 가져가야 그 두 가지로 서버 로그를 검색할 수 있습니다. 프로토콜의 링크 옵션은 OpenVPN 2.6 설명서 에 문서화되어 있으니 값의 정확한 의미가 필요할 때 참고하세요.