OpenVPN 프로필이 집에서는 되지만 호텔에서 실패하는 이유

사무실 Wi-Fi와 호텔 객실은 같은 노트북에 아주 다른 두 네트워크를 제공할 수 있고, 그 사이의 프로필은 그 사실을 전혀 모릅니다. 집에서 되는 설정은 관대한 업링크, 정상 동작하는 이름 해석, 터널이 나르는 것과 충돌하지 않는 로컬 서브넷을 전제합니다. 이 전제들은 각각 독립적으로 깨질 수 있습니다.

이 문제를 디버깅하는 유용한 방법은 네트워크를 네 가지 별개의 사실로 보고 순서대로 검사하는 것입니다. 먼저 프로필을 추측하면 보통 아무것도 고치지 못하고 증거를 가리는 변경이 됩니다.

위치에 따라 달라지는 네 가지 네트워크 사실

첫 번째 사실은 로컬 네트워크가 애초에 밖으로 내보내 주는지 여부입니다. 캡티브 포털은 기기를 로그인 페이지로 들여보내고 그 페이지가 끝날 때까지 나머지 전부를 막으므로, 프로필이 아무리 정확해도 터널은 시작할 수 없습니다.

두 번째는 이름 해석입니다. DNS를 가로채는 포털은 모든 질의에 자기 주소로 응답하므로 VPN 호스트 이름이 포털로 해석되고 클라이언트는 웹 페이지로 터널을 세우려 합니다.

세 번째는 전송 필터링입니다. 탐색만 허용하려는 네트워크는 TCP 443을 임의의 목적지로 통과시키고 UDP를 포함한 거의 모든 것을 버립니다.

네 번째는 주소 지정입니다. 로컬 서브넷이 터널 뒤 네트워크와 겹칠 수 있고, 업링크가 쓸 만한 IPv4 경로를 전혀 제공하지 않을 수도 있습니다.

이름 해석과 캡티브 포털

프로필의 호스트 이름을 서버의 숫자 주소로 바꾸고 다시 시도하십시오. IP는 연결되고 이름은 안 되면 이름 해석이 원인이며 프로필 자체는 문제없습니다.

VPN을 건드리기 전에 브라우저를 열어 평범한 HTTP 페이지를 시도하십시오. 로그인 페이지로 리디렉션되면 포털이 아직 남은 것이니, 그것을 완료한 뒤 다시 연결하십시오. 많은 호텔은 몇 시간 뒤 세션도 만료시키는데, 이는 로그인 문제가 아니라 낮중 끊김처럼 보입니다.

숫자 주소도 실패하면 이름 해석이 원인이 아니므로 전송으로 넘어가십시오. 시험한 주소를 기억해 두면, 다음 점검이 패킷이 애초에 기기를 떠났는지 알려 줍니다.

전송 필터링: 먼저 UDP, 예비로 TCP 443

UDP 1194 위의 OpenVPN 흐름은 호텔 방화벽이 알아볼 만한 무엇과도 닮지 않아 오류 없이 버려집니다. 클라이언트는 시간 초과가 끝날 때까지 다시 시도하고, 사용자는 거부 대신 결코 맺어지지 않는 연결을 봅니다. 그렇게 동작하는 방화벽은 버려진 사실을 눈에 보이는 곳에 거의 기록하지 않습니다. 거부가 없다는 것 자체가 단서입니다.

TCP 443은 네트워크가 그것을 평범한 HTTPS와 구별할 수 없기 때문에 신뢰할 만한 예비 수단입니다. 운영자의 TCP 프로필이 있으면, 서버도 그 전송과 포트에서 수신해야 하고 클라이언트만 바꾸면 다른 종류의 실패가 되므로 그것을 쓰십시오. TCP 프로필이 없으면 포트를 고쳐 새로 만들지 말고 운영자에게 물으십시오. 서버 쪽도 동의해야 하고, 불일치는 다시 방화벽 문제처럼 보입니다.

성능 비용을 예상하십시오. TCP 안의 TCP는 손실이 있는 회선에서 재전송을 증폭하므로, 동작하는 TCP 터널도 혼잡한 호텔 네트워크에서는 느리게 느껴질 수 있습니다. 이는 도달성을 위한 맞바꿈이지 쫓아다닐 결함이 아닙니다.

주소 충돌과 IPv4 없는 업링크

터널이 맺어지고도 아무것도 나르지 않을 수 있습니다. 로컬 LAN과 원격 네트워크가 192.168.1.0/24 같은 프리픽스를 공유하면, 클라이언트는 원격 호스트를 직접 연결된 것으로 보고 패킷을 터널 대신 로컬 링크로 보냅니다. 증상은 도달할 수 없는 서브넷 하나가 있는 성공적인 연결이며, 서버 측 경로 문제로 잘못 읽기 쉽습니다.

항구적 해법은 원격 LAN을 흔치 않은 사설 범위로 옮기는 것입니다. 집에서 아무도 쓰지 않는 범위, 예컨대 10.42.0.0/24를 고르면 한 곳이 아니라 앞으로의 모든 위치에서 문제를 막습니다. 현지 임시방편은 그 호텔이나 핫스폿, 라우터를 피하는 것인데 이는 전혀 해법이 아닙니다.

모바일 업링크는 두 가지 변형을 더합니다. 통신사급 NAT는 인바운드 연결이 도착하지 않음을 뜻하며, 서버를 호스팅할 때는 중요하지만 아웃바운드 클라이언트에는 아닙니다. NAT64 변환과 함께 IPv6 전용으로 설정된 APN은 진짜 IPv4 경로를 고집하는 클라이언트를 실패시킬 수 있고, 보통의 처방은 APN 프로토콜을 IPv4나 이중 스택으로 바꾸는 것입니다.

터널이 올라온 뒤의 증상

연결된 뒤 조용해지는 터널은 보통 keepalive나 MTU 문제이지 막힌 포트가 아닙니다. 정해진 분 수 뒤에 끊기는 연결은 keepalive나 재협상 타이머를 가리킵니다. 응답이 멈추면 클라이언트가 상대를 탐지해 다시 시작하도록 설정하고, ping은 통하는데 큰 전송이 멈추면 더 작은 터널 MTU를 시험하십시오.

도움을 청하기 전에 시도한 주소와 응답 여부, 사용한 전송과 포트, 실패한 네트워크의 로컬 서브넷 세 가지를 적어 두십시오. 이들을 함께 보면 이름 해석, 전송 필터링, 주소 충돌을 갈라낼 수 있고, 증거 앞에서 살아남는 원인은 바로 이것들입니다.