VPN 제어 채널과 데이터 채널: 올바른 계층을 확인하세요
터널이 협상은 되었는데 아무것도 전달하지 못할 수 있습니다. 어느 채널이 실패했는지 확인하세요. 제어 설정, 데이터 보호, 또는 둘 모두를 넘어선 경로와 DNS입니다.
클라이언트는 연결되었다고 하고 서버는 피어를 보지만 애플리케이션은 여전히 아무 데도 도달하지 못합니다. 그 시점에 유용한 질문은 어떤 암호를 바꿀지가 아니라 어느 채널이 실패했는지입니다. OpenVPN은 세션을 협상하고 관리하는 제어 채널과 보호된 트래픽을 전달하는 데이터 채널, 두 기능을 명시적으로 부릅니다. IKEv2는 IKE 연관과 CHILD 연관을 통해 비슷한 분리를 표현합니다. 제어 경로의 결함에 데이터 경로 수정을 적용하면 변경 기회를 낭비하므로 아래 점검을 순서대로 진행하세요.
디버그하기 전에 채널 이름을 붙이세요
제어 측은 보안 자료를 협상하고 피어를 인증하며 연결을 관리합니다. 데이터 측은 필요한 상태가 마련된 뒤 선택된 트래픽을 전달합니다.
둘은 다르게 실패합니다. 제어 실패는 보통 사용할 수 있는 세션이 전혀 없거나 루프에서 다시 협상하는 세션을 남깁니다. 데이터 실패는 세션이 건강해 보이는데도 패킷이 버려지고 잘못 라우팅되거나 상대가 받아들이지 않을 매개변수로 보호되는 상태를 남깁니다. 읽고 있는 로그 줄이 어느 상황인지 알려주므로 오류 문구보다 라벨을 먼저 읽으세요.
제어 교환을 점검하세요
핸드셰이크가 완료되고 양쪽이 전송, TLS 버전, 인증 방식에 합의하는지 확인하세요. OpenVPN 로그는 제어 채널과 데이터 채널의 줄을 따로 출력하며 인증서, TLS 버전, tls-crypt의 불일치는 제어 줄에 나타납니다.
제어 교환이 실패하면 도달 가능한 포트, 인증서 체인과 유효 기간, 시스템 시계, 클라이언트와 서버의 암호 중복, 그리고 모든 tls-auth 또는 tls-crypt 키를 확인하세요. 큰 인증서 체인은 어떤 인증도 끝나기 전에 경로 MTU에서 실패할 수 있으며 이는 암호 오류가 아니라 시간 초과처럼 보입니다.
제어 결함은 제어 설정으로 고치세요. 데이터 암호를 올리거나 데이터 인증 정책을 완화해도 인증서 교환을 넘지 못한 핸드셰이크는 완료되지 않습니다.
데이터 채널을 따로 점검하세요
세션이 올라오면 협상된 데이터 암호와 모드, 키 유도, 키 갱신 동작을 확인하세요. OpenVPN에서는 데이터 채널 줄이 실제로 초기화된 암호와 키 크기를 알려주며 프로필의 첫 암호와 다를 수 있습니다.
그다음 세션이 무엇을 설치했는지 확인하세요. PUSH_REPLY는 경로, DNS 서버, redirect-gateway 지시를 추가할 수 있고 그중 어느 것도 애플리케이션이 쓸 수 없는 곳으로 트래픽을 보낼 수 있습니다. IKEv2에서는 CHILD 연관의 선택자가 실제 흐름의 주소와 맞는지가 같은 질문입니다.
tls-auth와 tls-crypt는 제어 채널에 속합니다. 이들은 핸드셰이크를 인증하거나 암호화하며 애플리케이션의 데이터 암호를 선택하지 않습니다. 데이터 경로의 변화를 기대하며 둘 중 하나를 추가한다면 바뀌는 것은 핸드셰이크뿐입니다.
이름을 IKEv2와 OpenVPN에 대응시키세요
IKEv2에는 IKE 보안 연관과 하나 이상의 CHILD 연관이 있습니다. IKE 연관은 제어 교환을 전달하고 CHILD 연관은 보호된 트래픽과 그 선택자를 전달합니다. 둘은 별도의 일정으로 협상되고 키가 갱신되므로 하나는 건강해도 다른 하나는 그렇지 않을 수 있습니다.
ESP 내부에는 TLS 방식의 제어 채널이 없습니다. 제어 프로토콜은 IKE이고 ESP는 보호된 페이로드입니다. ESP를 데이터 채널이라고 부르는 것은 느슨한 약칭이며, 캡처에서는 IKE 메시지와 ESP 패킷이 서로 다른 프로토콜로 보이기 때문에 패킷 캡처를 읽을 때 혼란을 줍니다.
OpenVPN 제어 채널과 IKE SA는 관리 측, OpenVPN 데이터 채널과 CHILD SA는 트래픽 측이며 분리가 비슷해 보여도 구현은 서로 바꿀 수 없다는 대응 관계를 메모에 명시해 두세요.
잘못된 설정을 바꾸는 것을 멈추세요
제어 교환, 데이터 보호, 전달, 그리고 이름 해석의 순서로 경로를 한 방향으로 따라가세요. 실패하는 첫 단계에서 멈추고 그 단계만 고치세요. 게이트웨이로 가는 핑은 되지만 애플리케이션 트래픽이 없는 연결된 세션은 전달이나 선택자의 문제이며 핸드셰이크 문제가 아닙니다.
제어 로그 줄, 협상된 데이터 매개변수, 설치된 경로, 그리고 실제 요청 하나를 단계마다 분리해 티켓에 적으세요. 이 구조는 동작하는 신원 확인을 약화시켜 그것이 일으키지도 않은 이후의 라우팅 문제를 고치는 일을 막고, 데이터 암호 변경을 인증서 오류의 수정으로 파는 일도 막습니다.
OpenVPN 프로토콜 문서가 제어와 데이터의 분리에 대한 참고 자료이므로, 공급업체의 인터페이스가 같은 두 기능에 다른 단어를 쓸 때 참고하세요.