VPN이 이전했습니다: OpenVPN 클라이언트가 여전히 옛 IP로 접속하는 이유

공급자가 공용 주소를 바꾸고 동적 DNS 레코드를 갱신했는데도 클라이언트가 여전히 연결하지 못합니다. 밖에서 보면 레코드가 전파되지 않은 것처럼 보입니다. 대부분 레코드는 정상이고 클라이언트는 이전 전에 해석한 주소로 접속합니다. 실행 중인 터널과 저장된 프로필은 각각 서버가 어디 있는지에 대한 나름의 생각을 가지고 있기 때문입니다. 세 계층이 합의해야 하며, 갱신 주기도 서로 다릅니다.

DNS가 말하는 것이 아니라 프로필이 접속하는 곳을 보세요

실제로 사용하는 연결을 열고 remote 줄을 읽으세요. 그곳의 숫자 주소는 레코드가 아무리 정확해져도 호스트 이름 갱신을 따르지 않습니다.

그다음 편집한 프로필이 클라이언트가 불러온 것인지 확인하세요. 가져온 프로필은 흔합니다. 관리자가 몇 달 전에 복사본을 만들어 자기 버전을 보관했다면 다운로드 폴더의 파일과 앱의 항목이 다를 수 있습니다. DNS를 디버그하기 전에 클라이언트 자체의 연결 세부 정보에서 엔드포인트를 비교하세요.

파일 두 개, 엔드포인트 하나 — 여기서 흔히 나오는 결론입니다.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

클라이언트의 다음 연결 시도를 읽으세요

자세한 로깅으로 연결을 다시 시작하고 접속할 주소를 명시한 줄을 읽으세요. 중요한 것은 그 값이며, 브라우저가 해석한 값이 아닙니다.

리졸버 캐시에는 이전 응답이 남아 있을 수 있고, 일부 네트워크는 레코드의 TTL이 요구하는 것보다 오래 보관합니다. 다른 곳에서 시험한 공용 리졸버가 아니라 클라이언트가 실제로 사용하는 리졸버에 질의하세요.

로그에 새 주소가 보이는데도 연결이 실패한다면 문제가 옮겨간 것입니다. 패킷은 어딘가로 가고 아무도 응답하지 않습니다. 이는 리스너, 방화벽, 포트 포워딩의 문제이며 클라이언트의 해석 경로가 아니라 서버 쪽에 있으니, 이 두 실패를 분리해 두세요. 도달할 수 없는 리스너를 DNS 문제로 다루면 같은 고리를 두 번 도는 셈입니다.

어떤 재시작을 하는지 아세요

모든 재시작이 같은 상태를 보존하지는 않으므로, 프로세스가 어떻게 재활용되는지에 따라 주소 변경의 동작이 달라질 수 있습니다. 신호로 촉발된 소프트 재시작은 이전 세션의 문맥을 더 많이 유지하고, 완전한 중지와 시작은 구성에서 다시 시작합니다. 클라이언트가 다시 해석하는지 시험한다면 구성에서 시작하는 경로를 원합니다.

지속성 설정도 인증된 것을 유지하도록 설계된 것이지 새 주소를 쫓기 위한 것이 아니므로 중요합니다.

가장 깨끗한 시험은 의도한 프로필에서 새로 시작한 뒤 엔드포인트를 명시한 로그 줄을 보는 것입니다. 부분적으로 보존된 세션에서 배우는 것은 그 세션에 대한 진술일 뿐입니다.

네 가지 옵션과 각자의 역할

호스트 이름이 있는 remote는 재해석을 가능하게 하는 설정입니다. 그 줄에 리터럴 주소가 있으면 불가능해집니다. resolv-retry는 조회가 실패할 때의 동작을 제어하며, 2.6은 이미 기본값을 무한으로 둡니다. 따라서 추가해도 아무것도 바뀌지 않고, 다른 응답을 위한 주기적 점검을 예약하지도 않습니다. 새 주소를 폴링한다고 말하는 사람은 복구와 최신성을 혼동한 것입니다.

persist-remote-ip는 최신성이 아니라 연속성에 관한 것입니다. 마지막으로 인증한 엔드포인트를 지원하는 소프트 재시작 전반에 걸쳐 재사용합니다. 이전을 시험하는 동안에는 원하는 것의 반대입니다. 빌드가 이를 활성화한다면 시험 동안 끄고, 새 엔드포인트가 증명되면 복원하세요. 켜 둔 채로는 성공적인 재연결이 DNS에 대해 아무것도 알려주지 않을 수 있습니다.

float는 세션 중간에 주소가 바뀐 인증된 피어를 허용하며, 이를 지원하는 구성에서만 그렇습니다. DNS를 새로 고치지 않고, 공급자 변경을 스스로 따르지도 않습니다. 로밍하는 피어를 위한 복원력 기능으로 취급하고, 서버를 위한 동적 주소 메커니즘으로 보지 마세요.

클라이언트를 탓하기 전에 새 엔드포인트를 확인하세요

네트워크 밖에서 새 주소가 구성된 포트에 리스너를 두고 있는지, 공급자의 포워딩이 그곳을 가리키는지 확인하세요. 열린 포트가 없는 머신에 대한 올바른 A 레코드는 사람들이 캐싱 탓으로 돌리는 증상을 정확히 만들어 냅니다.

그다음 다시 연결해 두 가지를 확인하세요. 클라이언트가 예상한 서버 인증서로 인증되었는지, 세션이 의도한 리소스에 도달하는지입니다. 주소 변경은 신원 요구를 낮추지 않으며, 잘못된 엔드포인트로 성공하는 연결은 실패하는 연결보다 나쁩니다. OpenVPN 2.6 설명서는 네 가지 옵션을 각자의 범위와 함께 나열하며, 프로필 옆에 두어야 할 점검 목록입니다.

관리 접근을 운반하는 터널을 다시 시작하기 전에 서버로 들어가는 대역 밖 경로를 확보하세요. 그 하나의 예방 조치가 이 시나리오가 만드는 대부분의 사고를 막습니다.