OpenVPN이 443에서 여전히 차단되나요? 네트워크가 무엇을 검사하는지 확인하세요

터널은 집 회선에서 연결되고 호텔이나 사무실 네트워크에서 멈추며, 서버를 포트 443으로 옮겨도 아무것도 달라지지 않았습니다. 그 결과는 흔해서 형태가 있습니다. 포트는 쉬운 부분이었고, 나머지 결정은 클라이언트와 서버 사이에 앉은 모든 것에 속합니다. 두 가지 질문이 대부분의 사례를 정리하며, 둘 다 암호에 관한 것이 아닙니다. 네트워크가 그 주소로 TLS 핸드셰이크를 받아들이는가, 그리고 터널이 올라간 동안 클라이언트가 자기 래퍼로 가는 경로를 유지하는가.

핸드셰이크는 번호보다 많은 것을 드러낸다

TCP 443의 네이티브 VPN 리스너는 첫 패킷부터 자기 프로토콜로 말합니다. ClientHello에는 버전 필드, 난수 값, 확장 목록이 있고, 수백 바이트를 읽는 장치는 아무것도 복호화하지 않고 차이를 알아볼 수 있습니다. 포트 번호는 값싸게 만족시킬 수 있고, 필터가 실제로 확인하는 것은 프로토콜의 형태입니다. 규칙은 보통 프로토콜별로도 쓰이므로 TLS를 검사하는 정책은 UDP에 대해 아무 말도 하지 않습니다.

유효한 TLS 세션을 요구하는 투명 프록시는 설정 도중에 연결을 끊습니다. 흔히 TCP 핸드셰이크가 끝난 뒤입니다. 그 세부는 나중에 중요합니다. 소켓이 열린 뒤에 클라이언트 로그가 멈춘다는 뜻이기 때문입니다.

스트림을 감싸면 두 개의 실패 지점이 생긴다

stunnel 같은 TLS 래퍼는 기대한 형태를 되살립니다. 클라이언트는 로컬 리스너에 연결하고, 래퍼는 443에서 서버로 진짜 TLS 세션을 열며, 서버의 두 번째 래퍼가 복호화된 바이트를 VPN 데몬으로 넘깁니다. 바깥 세션은 이제 다른 HTTPS 연결처럼 보입니다. 서버의 VPN 데몬은 loopback에서만 들어야 합니다. 래퍼 밖의 무엇도 거기에 닿을 필요가 없기 때문입니다.

그 설계에는 세 가지가 따로 맞아야 합니다. 클라이언트 프로필이 로컬 리스너를 가리키고, 서버 인증서가 클라이언트가 검증하는 이름과 일치하며, 서버 쪽 전달이 데몬이 실제로 쓰는 포트를 겨냥해야 합니다. 하나라도 틀리면 VPN 계층에 닿기 전에 연결이 죽습니다. 그러면 인증서 불일치는 VPN 오류가 아니라 래퍼 오류로 나타납니다. 그래서 두 로그를 나란히 읽을 가치가 있습니다.

래퍼로 가는 경로가 함정이다

터널이 올라오면 기본 경로가 그 안을 가리키고, 바깥 TLS 세션은 자기가 나르는 터널로 들어가지 않는 길이 필요합니다. 보통의 VPN 클라이언트는 자기가 거는 주소를 보호하지만, 래퍼로 감싼 클라이언트는 자기 loopback에 걸기 때문에 래퍼의 목적지 주소는 그 보호에서 보이지 않습니다.

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

정확한 주소는 직접 채우면 되고, 경로는 시작할 때만이 아니라 연결이 살아 있는 내내 있어야 합니다. 클라이언트 앞에서 경로를 더하고 뒤에서 지우는 작은 래퍼 스크립트가 외워 둔 명령보다 믿을 만합니다.

Android에서는 그 예외에 해당하는 것이 앱별 설정입니다. 래퍼 앱을 터널에서 빼면 그 앱의 트래픽은 모바일 연결로 나갑니다. 빼지 않으면 래퍼가 자기가 만들려는 터널 안으로 들어가고, 재연결 고리는 서버 문제처럼 보입니다.

무엇이든 바꾸기 전에 시간을 읽어라

매번 같은 간격 뒤에 죽는 세션은 암호 실패가 아니라 정책의 서명이며, 장시간 흐름 한도가 바로 그 패턴을 만듭니다. 핸드셰이크 직후에 재설정되는 연결은 인증서 체인이 마음에 들지 않은 프록시를 시사합니다.

두 네트워크에서 평범한 HTTPS 사이트의 인증서 발급자를 비교하세요. 제한된 네트워크에서 발급자가 다르다면 무언가가 중간에서 TLS를 종료하고 있습니다. 그 가로채기를 바꾸지 않고 견디는 래퍼는 없습니다. 같은 비교로 차단이 서버 이름을 겨냥하는지, 그 주소의 모든 TLS 세션을 겨냥하는지도 알 수 있습니다.

관찰한 동작을 적으세요. 세션이 얼마나 갔는지, 소켓이 열렸는지, 래퍼가 핸드셰이크를 기록했는지. 각각이 다음 시험을 좁힙니다.

한 번에 변수 하나씩 시험하라

먼저 UDP를 확인하세요. 일부 네트워크는 그것을 완전히 버리고, UDP 실패는 443에 대해 아무 말도 하지 않습니다. 다음으로 래퍼 없이 TCP 443을, 그다음 443에서 래퍼를 시험하세요. 각 단계에서 클라이언트 로그를 읽고 동작이 바뀌면 바로 멈추세요.

시도마다 요소 하나만 바꾸세요. 새 포트, 새 래퍼, 새 암호를 한 번에 쓰면 셋 중 무엇이 중요했는지 말할 수 없습니다.