OpenVPN 안에서 TLS가 어디에 있고 무엇이 형태를 바꾸는가

OpenVPN이 실제로 TLS를 쓴다는 것은 사실이다. 다만 사람들은 여기서 지탱할 수 없는 주장으로 나아간다. 터널이 그래서 브라우저가 사이트를 방문하는 것처럼 보인다는 주장이다. 앞부분은 맞다. 뒷부분은 아니다. 여기서 TLS는 OpenVPN 자체 컨테이너 안을 지나는 제어 채널에 속하며, 전혀 다른 암호학을 쓰는 페이로드 채널이 옆에 있다. 그래서 시작 바이트를 들여다보는 사람은 OpenVPN을 본다.

한 봉투 안의 두 대화

세션을 하나의 봉투를 공유하는 두 대화로 생각해 보자. 하나는 인증서를 검증하고 키 자료를 도출한다. 다른 하나는 실제로 보내는 것을 첫 번째가 만들어 낸 것으로 암호화한다.

봉투가 곧 프로토콜이다. 모든 패킷은 자기 종류를 밝히는 작은 헤더로 시작하고, 그 헤더가 무엇보다 먼저 도착한다.

실제로 무엇이 먼저 도착하는가

그 순서 때문에 회선 위의 첫 번째 것은 TLS 레코드가 아니다. OpenVPN의 헤더이고, 그다음 헤더가 알리는 채널의 내용이 온다. ClientHello는 그 안에 있지만 맨 앞 바이트는 아니다. 차이를 알아채는 데 복호화는 필요 없다. 형태만으로 드러나기 때문이다.

기본값도 여기서 중요하다. 프로필이 TCP를 고르지 않으면 흐름은 UDP로 1194로 간다. 어느 쪽이든 겉모습은 터널이지 웹 요청이 아니다.

형태를 바꾸는 세 가지 정직한 방법

stunnel 같은 TLS 종단기는 양 끝의 포트에서 TLS를 받아 복호화한 스트림을 로컬에서 OpenVPN에 넘기므로, 네트워크에는 그 포트로 가는 TLS가 보인다. 첫 바이트부터 TLS인 프로토콜은 또 다르게 동작한다. ocserv가 구현하는 AnyConnect 호환 교환은 많은 네트워크가 이미 기대하는 기업 원격 접속과 비슷하다. Windows에 딸려 오는 SSTP도 다른 제품에서 같은 성질을 지닌다.

Linux에서 SSH의 -w 옵션은 SSH 세션 안에서 점대점 링크를 나른다. SSH만 허용된 프로토콜일 때 쓸모가 있다. 그 네트워크에서 SSH가 이미 동작한다면 네 가지 중 가장 저렴하고, 동작하지 않는다면 가장 쓸모없다.

그중 어느 것도 바꾸지 않는 것

이들 중 어느 것도 터널이 닿을 수 있는 범위를 바꾸지 않는다. 차단된 주소를 닿을 수 있게 만들지 않고, 누구도 인증하지 않으며, 경로를 정하지도 않는다.

래퍼는 부품 하나를 더 소비한다. 리스너 둘과 설정 파일 둘이라는 것은 고장 지점이 둘이라는 뜻이고, 둘 다 사용자 자리에서는 똑같아 보인다. 하나를 도입하기 전에 그 비용을 계산에 넣어야 한다. 세션은 한 목적지로 가는 단일한 장기 암호화 흐름으로 남고, 그 부피와 시점은 계속 보인다.

먼저 진단하고, 그 다음 선택하라

그러니 먼저 진단하라. 버려진 UDP에는 TCP 모드로 답하고, 인식된 서명에는 다른 프로토콜이나 래퍼로 답한다. 차단을 알기 전에 도구를 고르는 것이 바로 같은 이유로 모두 실패하는 세 계층을 유지하게 되는 길이다.

웹 포트만 허용하는 네트워크는 선택을 443의 TLS 기반 프로토콜로 좁힌다. 셋을 한꺼번에 적용하면 아무도 디버그할 수 없는 층이 되므로, 한 가지를 바꾸고 같은 흐름을 다시 시험하라.

어느 것도 해당하지 않는다면 정확한 답은 이 네트워크가 당신을 위한 터널을 나르지 않는다는 것이다. 그것은 노력의 실패가 아니라 발견이다. 더 많은 선택지를 돌아도 상류에서 내린 정책 결정이 뒤집히지 않는다.

그 모든 것 앞에 하나의 경계가 있다. 남의 네트워크에서 터널을 돌릴 허가는 정책의 문제이며, 그 메커니즘이 작동하는지와는 별개로 결정된다. 이 사실들은 관찰자가 무엇을 보는지 설명할 뿐, 허가를 주지 않는다.