우리는 OpenVPN을 씁니다: 프로토콜, 엔진, 아니면 앱? 대신 무엇을 물어야 할까

«우리는 OpenVPN을 씁니다»라는 문장은 티켓, 구매 양식, 신입 사원 문서에 등장하며, 각각에서 다른 질문에 답합니다. 어떤 때는 전송 프로토콜을 가리키고, 어떤 때는 게이트웨이 위의 소프트웨어를, 또 어떤 때는 신입 사원이 설치해야 할 앱을 가리킵니다. 이 세 가지 사실은 서로 다른 다음 단계로 이어지며, 어느 것을 뜻하는지 묻는 편이 짐작하는 것보다 시간이 덜 듭니다. 나머지 조사는 그 답에서 출발합니다.

브랜드가 세 가지를 모두 덮으므로 역할을 브랜드에서 분리하는 것부터 시작하십시오.

이 이름은 서로 다르게 실패하는 세 역할을 덮고 있습니다

프로토콜로서 OpenVPN은 호환되는 상대가 어떻게 터널을 세우고 그 안을 지나가는 것을 보호하는지 설명합니다. 소프트웨어로서 그것은 그 프로토콜을 클라이언트나 서버 역할로 말하는 구현입니다. 클라이언트로서 그것은 누군가 설치하는 애플리케이션이며, 고유한 버전과 프로필 형식, 플랫폼 특유의 습성을 지닙니다. 한 역할의 고장이 다른 역할의 고장을 뜻하지는 않으므로 «OpenVPN이 내려갔다»에는 주어가 필요합니다.

신고한 사람이 무엇을 볼 수 있는지 물으십시오: 프로필 파일, 설치된 프로그램, 또는 그가 관리하는 게이트웨이입니다. 그 한 가지 세부가 다음 단계가 클라이언트 로그인지, 패키지에 대한 질문인지, 서버 쪽 수신 대기 확인인지를 알려 줍니다.

OpenVPN 2와 OpenVPN 3은 업그레이드 짝이 아닙니다

OpenVPN 2.x는 서버와 클라이언트 역할 모두에서 동작하며, 대부분의 게이트웨이 배포가 아직도 이것을 씁니다. OpenVPN 3은 고유한 설정과 세션 모델을 지닌 별개의 클라이언트 지향 구현이며, 2.x 서버 위에 설치하는 다음 버전이 아닙니다. OpenVPN Connect는 OpenVPN 3 엔진 위에 세워진 클라이언트 애플리케이션입니다. 그중 무엇을 설치해도 인터넷 출구 서비스가 생기지는 않으며, 출구는 운영자가 설정한 것입니다.

프로토콜 수준의 호환성은 프로필 지시문까지 미치지 않으므로, 깨끗하게 가져온 프로필도 클라이언트가 구현하지 않은 지시문에서 실패할 수 있습니다.

전송은 그 안의 애플리케이션이 아닙니다

바깥 연결은 UDP나 TCP 같은 전송을 써서 설정된 수신 대기에 도달하며, 터널이 나르는 모든 것은 그 안을 지납니다. VPN을 통해 하는 웹 요청에는 자체 OpenVPN 수신 대기가 필요하지 않으며, 회선 위에서 OpenVPN 패킷이 되지도 않습니다. TLS 모드에서는 제어 채널이 키 재료를 협상하고 데이터 채널이 페이로드를 보호하므로, 로그를 읽을 때 이 구분을 바로 유지할 가치가 있습니다.

계층을 혼동하면 이미 터널을 통해 동작하는 웹사이트를 위해 포트를 여는 식의 요청이 나옵니다. 포트는 바깥 연결에 속하며 애플리케이션에 속하지 않습니다.

프로필이 약속할 수 있는 것과 없는 것

프로필은 한 클라이언트에게 한 서비스에 도달하는 방법을 알려 줍니다: 종단점, 전송, 신원 재료, 그리고 흔히 몇 가지 라우팅과 DNS 설정입니다. 그 서비스를 누가 운영하는지, 계정이 승인되었는지에 대해서는 아무 말도 하지 않습니다. 경로, 리졸버 설정, 전달 규칙, 접근 정책이 세션이 실제로 어디에 닿는지를 결정합니다. 잘 가져와지는 프로필은 동작하는 연결의 시작이며 그 증거는 아닙니다.

어떤 리소스가 VPN으로 닿는지 묻는다면, 답은 클라이언트의 설정 파일이 아니라 서버의 정책에 달려 있습니다.

마련할 수 있는 것을 요구하십시오

넓은 이름을 세 가지 구체로 바꾸십시오: 클라이언트와 그 버전, 그 클라이언트에 승인된 프로필, 그리고 그 사람이 닿아야 할 리소스입니다. 그것이 있으면 마련은 구체적인 일이 됩니다. 그것이 없으면 모든 답은 질문이 어느 OpenVPN을 뜻했는지에 대한 짐작입니다.

답을 요청 자체에 적어 두십시오. 다음 티켓도 같은 모호한 방식으로 같은 질문을 할 것입니다.