호텔 Wi-Fi에서 OpenVPN이 연결되지 않나요? TCP 443을 시도하세요

클라이언트를 열고 연결을 누른 뒤, 이어지는 대화 상자 대신 상태 줄을 읽으세요. 호텔, 캠퍼스, 모바일 네트워크를 거친 뒤 연결 중이나 서버 대기 중에서 멈추는 프로필은 보통 경로 어딘가에서 전송 계층을 잃은 것이지 자격 증명을 잃은 것이 아닙니다. 다음으로 유용한 단계는 서버를 건드리기 전에 그 네트워크가 무엇을 실어 나르는지 알아보는 것입니다. 같은 프로필이 다른 곳에서 동작할 때까지 아무것도 바꾸지 마세요.

먼저 휴대폰 핫스팟에서 시험하세요. 거기서 터널이 올라오면 서버, 인증서, 계정이 모두 정상이고 남은 변수는 눈앞의 네트워크뿐입니다.

클라이언트에서 시작하세요: 상태 줄을 읽으세요

상태 줄은 어느 단계에서 실패했는지 알려줍니다. 연결 중에 걸린 클라이언트는 아직 호스트를 확인하거나 바깥 소켓을 여는 중이고, 서버 대기 중에 도달한 클라이언트는 경로는 있지만 응답이 없으며, 인증까지 하고 나서 끊기는 클라이언트는 전혀 다른 문제입니다. 클라이언트 로그와 프로필 자체의 remote 및 proto 필드는 클라이언트가 무엇을 하려는지 보여 주고, 명령줄 클라이언트에서는 --verb 4 가 같은 세부 정보를 출력합니다. 그것을 눈앞의 네트워크와 비교하는 것이 VPN이 차단되었다는 말을 구체적인 주장으로 바꿉니다.

그다음 이미 가진 도구로 네트워크를 조사하세요. nc -vzu 203.0.113.10 1194 는 UDP 데이터그램을 보내고, curl -v telnet://203.0.113.10:443 는 TCP 핸드셰이크가 완료되는지 보고하며, HTTPS 페이지를 불러오는 브라우저는 나가는 443이 그 한 호스트에 도달한다는 것만 증명합니다. 작은 조사는 VPN 클라이언트가 답할 수 없는 것, 곧 어떤 포트와 프로토콜이 애초에 이 네트워크를 빠져나가는지를 답합니다.

세 가지 네트워크 동작은 클라이언트 쪽에서는 비슷해 보이지만 서로 다른 답을 요구합니다. 나가는 443이 열려 있을 수 있고, 프록시만 허용될 수 있으며, 443이 무엇을 실어 나르는지 읽을 수 없는 검사 장비로 투명하게 전달될 수도 있습니다. 첫째는 아래 프로필 변경으로, 둘째는 프록시 설정으로 해결되고, 셋째는 핸드셰이크를 마친 뒤 검사기가 그 스트림을 마뜩잖아할 때 멈출 수 있습니다. 셋 중 무엇을 마주했는지 아는 것이 십 분짜리 변경과 반나절 재설치 사이의 차이입니다.

리스너와 프로필을 함께 옮기세요

서버 쪽에서는 네트워크가 허용하는 것으로 리스너를 맞춥니다: 서버 구성에서 port 443 와 proto tcp 을 지정하고, 서비스를 다시 시작한 뒤 ss -lntp 로 소켓을 확인합니다. 전송 계층과 포트는 터널 밖에 있으므로 클라이언트 쪽에서도 프로필을 맞춰야 하며, .ovpn 의 proto tcp 와 port 443, 또는 앱 설정 화면의 해당 필드가 그것입니다. 여전히 UDP 1194를 향한 프로필은 전과 똑같이 실패하며, 이미 고친 방화벽을 탓하고 싶어집니다. 같은 호스트가 443에서 HTTPS에도 응답하면 두 리스너는 그 주소와 프로토콜을 공유할 수 없으므로, VPN에 두 번째 주소를 주거나 앞에 역다중화 장치를 두세요.

첫 연결을 양쪽 끝에서 tcpdump -ni any port 443 로 지켜보세요. 클라이언트를 떠나 끝내 도착하지 않는 패킷은 결국 네트워크가 필터링하고 있거나 프로필의 주소가 생각한 것과 다르다는 뜻입니다. 응답 없이 도착하는 패킷은 서버 로그로 되돌려 보내며, 거기서 프로토콜 불일치가 즉시 버려진 패킷으로 드러납니다.

프록시만 네트워크를 빠져나갈 때

일부 게스트 네트워크는 HTTP 프록시 외에는 아무것도 허용하지 않으며, 이는 닫힌 포트와 다른 제약이고 OpenVPN보다 더 많은 것을 배제합니다. PPTP, L2TP/IPsec 또는 순수 IPsec만 말하는 클라이언트는 그곳을 통과할 방법이 없는데, 그런 설계는 바깥 프로토콜이 서버에 직접 도달하기를 기대하기 때문입니다. OpenVPN 은 클라이언트 프로필에 http-proxy proxy.example.net 8080 을 넣고 프록시가 당신의 포트로 CONNECT 메서드를 허용한다면 가능합니다. SOCKS 프록시는 안에 무엇이 들었는지 신경 쓰지 않고 스트림을 전달하기 때문에 더 쉽습니다.

클라이언트에 프록시 지원이 없으면 보통 443 위의 SSH 터널이 남습니다. 계층이 하나 더 늘고 네트워크 운영자가 이에 대해 의견을 가질 수 있으므로, 아키텍처가 아니라 한 번의 출장을 위한 다리로 취급하세요.

유지하기 전에 대체 경로의 값을 매기세요

TCP 안의 TCP에는 알려진 비용이 있습니다. 바깥 연결이 TCP이고 페이로드도 TCP이면, 잃어버린 세그먼트가 두 계층 모두에서 재전송을 일으키고 안쪽 연결은 보이지 않는 손실 앞에서 물러납니다. 탐색은 이를 견디지만 대화형 세션과 통화는 이를 느낍니다. TCP 443 리스너는 그것을 요구하는 네트워크를 위한 대체 경로로 남겨 두고, 아직 통과시키는 모든 것에는 UDP를 기본값으로 두세요.

선택을 프로필 이름과 지원 노트에 기록하세요: 어느 포트, 어느 프로토콜, 어느 네트워크가 이를 불러왔는지입니다. 그다음, 조용히 사라지는 대체 경로는 아예 없는 것보다 나쁘므로, 네트워크 관리자에게 다음 장비 교체 후에도 그 포트가 열려 있을지 물어보세요.