proto udp 또는 tcp-client: 서버는 어느 쪽을 듣는가?

지난달까지 작동하던 프로필이 이제 시간 초과가 나고, 누군가 proto udp 를 proto tcp-client 로 바꾸자고 제안한다. 때로는 그것이 옳은 조치이고, 때로는 서버가 다른 전송 방식으로 설정된 적이 없어 아무것도 듣지 않는 포트로 접속하는 클라이언트가 만들어진다. 이 지시문은 자기 쪽이 어떻게 말하는지를 설명할 뿐, 반대편에 리스너를 만들 수는 없다. 둘 중 하나를 바꾸기 전에 프로필과 서버를 함께 읽어 보자.

선택된 연결이 사용하는 전송 방식을 읽는다

프로필에는 여러 개의 remote 항목이 있을 수 있고, 각 항목이 자신의 전송 방식을 지정할 수 있다. 클라이언트는 이를 순서대로 처리하므로, 처음 보이는 줄이 반드시 적용되는 줄은 아니다.

실제로 시도되는 항목을 찾은 다음 그 전송 방식을 읽는다. 클라이언트가 조용히 다음으로 넘어가지 않으므로 순서가 중요하다. 일부 빌드는 시간 초과 후에만 다음 항목을 시도하므로, 파일 아래쪽의 작동하는 대안은 예상보다 몇 초 늦게 도달한다. 첫 줄이 이겼다고 가정하지 말고 로그에서 어느 종단점이 시도되는지 살펴보자.

파일 위쪽에 proto 줄이 하나 있고 그 아래에 여러 remote 항목이 있다면, 그 줄은 그것을 덮어쓰지 않는 모든 remote의 기본값이다. 기본값을 로컬에서 수정해도 자신의 전송 방식을 지정하는 remote 항목에는 아무 효과가 없다.

grep -nE '^(remote|proto)\b' client.ovpn

UDP와 TCP는 속도 설정이 아니다

UDP는 순서가 있는 스트림을 만들지 않고 데이터그램을 보내므로, 터널 자체의 트래픽이 두 번째 신뢰성 있는 전송으로 감싸지지 않는다. TCP는 UDP를 버리거나 차단하는 네트워크를 통과하는 경로를 주지만, 그 대가로 중첩된 재전송이 생겨 손실이 있는 링크를 더 나쁘게 느끼게 할 수 있다.

이것은 도달 가능성의 교환이지 보편적인 순위가 아니다. 올바른 선택은 클라이언트 앞의 네트워크가 허용하는 것이다. VPN 포트에서 UDP를 버리는 경로는 프로필이 아무리 잘 쓰였어도 절대 협상하지 않는다. 경로를 시험한 다음 전송 방식을 고르자.

측정만으로 둘 중 하나를 고르는 것은 실수다. 답은 앞에 있는 네트워크가 무엇을 허용하는지에 달려 있기 때문이다. 호텔이나 기업 프록시는 443 포트의 아웃바운드 TCP만 허용할 수 있고, 그래서 공급자들이 그 변형을 제공한다. 포트 번호가 익숙하더라도 그것은 HTTPS 세션이 아니라 그 포트에서의 OpenVPN 연결이다.

tcp-client의 실제 의미

클라이언트 측 지시문은 TCP 연결을 시작하는 쪽을 가리킨다. 서버 측은 자신의 수신 형식을 사용하므로, 클라이언트의 단어를 서버 설정에 복사하면 연결을 받는 쪽이 아니라 호출받기를 기대하는 리스너가 만들어진다.

일치한다는 것은 양쪽이 전송 방식에 합의한다는 뜻이지, 같은 문자열을 공유한다는 뜻이 아니다.

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

프로필이 잘못됐다고 가정하기 전에 서버에 무엇을 듣고 있는지 물어보자. UDP 리스너는 TCP 소켓 목록에 나타나지 않으며 그 반대도 마찬가지이므로, 일반적인 보기 대신 프로토콜별 보기를 확인하자.

프로필을 가져왔는데 절대 연결되지 않을 때

즉시 시간 초과가 나는 가져온 프로필은 보통 어떤 인증보다도 먼저 실패한다. 패킷은 리스너가 없는 포트로 가거나, 네트워크가 조용히 버린다.

경로를 가능한 한 단순하게 시험하자. 실패하는 클라이언트와 같은 네트워크에서 프로필이 주장하는 전송 방식으로 같은 호스트와 포트에 연결해 보자.

UDP 시험이 아무것도 얻지 못하고 TCP 시험이 연결된다면, 서버는 다른 전송 방식을 제공하는 것이고 프로필은 그저 오래된 것이다. 둘 다 응답하지 않는다면 문제는 전송 방식 선택보다 상류에 있으며 프로필을 어떻게 편집해도 고쳐지지 않는다. 이 두 경우를 구분하는 데는 일 분이 걸리고, 전혀 관련 없던 인증서 디버깅 한 시간을 아낀다.

작동하는 전송 방식을 기록하자

조합이 작동하면 서버, 포트, 프로토콜과 함께 적어 두고, 어느 네트워크에서 시험했는지 표시하자.

그렇지 않으면 시간 초과를 겪는 다음 사람이 같은 실험을 반대 방향으로 되풀이하고, 어쩌면 멀쩡하던 서버를 바꿔 버릴 것이다.

공급자가 두 변형을 모두 공개한다면 두 파일을 모두 보관하고 맞는 네트워크에 따라 이름을 붙이자. 이름이 분명한 두 프로필은 클라이언트 전송 방식이 그에 맞게 설정된 적 없는 서버 리스너와 우연히 섞이는 것을 막는다.