OpenVPN이 첫 줄을 거부하나요? 파일은 아마도 UTF-16입니다

오류는 .ovpn 파일의 첫 줄을 가리키며 client가 있어야 할 자리에 뒤섞인 글자처럼 보이는 것을 인용합니다. 파일은 편집기에서 아무 문제 없이 열리고, 첫 줄은 client로 읽히며, 지시자는 지극히 평범합니다. 두 관찰 모두 맞는 것은 편집기는 바이트를 디코딩하지만 클라이언트는 그러지 않기 때문입니다. 지금 보고 있는 것은 거의 항상 인코딩 문제이며 문법 문제가 아닙니다.

속설: 편집기가 보여 주는 것이 파일이다

텍스트 편집기는 감지하거나 추측한 인코딩으로 바이트를 문자로 디코딩합니다. UTF-16으로 추측하면 화면에서는 파일이 완벽해 보이지만 그 아래 바이트는 쌍으로 되어 있어 라틴 문자마다 제로 바이트가 따라붙습니다. OpenVPN은 그 바이트를 문자로 읽고, 파싱하려는 첫 지시자에서 불일치가 드러납니다.

그래서 보이는 줄과 전달되는 줄은 서로 다른 것입니다. 보이는 이상한 문자를 지우는 것은 인코딩이 아니라 표시를 바꾸는 일이며, 다음 파싱도 같은 이유로 조금 다른 메시지와 함께 실패합니다. 오류 속 토큰을 쫓아도 끝내 아무 데도 닿지 않는 이유입니다. 바이트는 원본에서부터 틀렸고, 뒤따르는 모든 판독기는 같은 깨진 배열을 추측합니다.

특정한 방식으로 진단적이기 때문에 이 실패의 구체적인 모양은 알아 둘 가치가 있습니다. 다른 기기에서는 잘 동작하던 프로필에서 파일 맨 앞에 토큰이 있다면, 이는 어휘의 문제가 아니라 바이트 순서의 문제입니다.

처음 바이트가 실제로 말하는 것

문자가 아니라 바이트를 읽으세요. 작은 명령 두 개면 몇 초 만에 판가름 나고, 둘 다 파일을 바꿀 수 있는 응용 프로그램에서 열 필요가 없습니다:

file client.ovpn
head -c 24 client.ovpn | od -An -tx1

찾는 패턴은 앞쪽의 바이트 한 쌍 뒤에 두 번째 바이트마다 제로가 오는 텍스트가 이어지는 형태입니다. FF FE는 UTF-16 리틀 엔디언, FE FF는 빅 엔디언, EF BB BF는 바이트 순서 표시가 있는 UTF-8을 뜻합니다. 표시가 없는 보통 UTF-8 파일은 첫 글자의 바이트로 곧장 시작합니다.

글자 사이의 제로 바이트가 결정적 단서입니다. 모든 ASCII 문자의 뒤에 제로가 붙기 때문에 UTF-16 리틀 엔디언에서 client라는 단어는 여섯 바이트가 아니라 열두 바이트를 차지합니다. 그 구조는 편집기 화면으로는 보이지 않고, 두 바이트를 지우는 것으로도 없앨 수 없습니다.

여기 중요한 미묘함이 있는데, OpenVPN의 구성 판독기는 2.6 구성 판독기가 보여 주는 대로 파일 앞부분의 UTF-8 바이트 순서 표시를 실제로 건너뜁니다. 그 관용은 바로 그 표시에만 해당하며, 글자가 제로로 채워진 UTF-16 파일에는 아무 효과가 없습니다. 두 표시를 같은 문제로 보는 것이 속설의 나머지 절반입니다.

변환은 삭제가 아니라 다른 이름으로 저장

무엇이든 하기 전에 운영자의 원본을 그대로 둔 사본을 보관하고 별도 파일에서 작업하세요. 프로필에는 개인 키나 계정 자료가 들어 있을 수 있으므로 사본은 되돌릴 지점이자 참조점입니다.

그다음 실제 인코딩 변환은 편집기의 명시적 인코딩 메뉴를 쓰거나, 입력과 출력 인코딩을 밝히는 변환기로 수행하세요:

iconv -f UTF-16 -t UTF-8 client.ovpn > client-utf8.ovpn
file client-utf8.ovpn

명령의 종료 상태를 믿지 말고 결과를 검증하세요. 변환은 모든 지시자를 보존해야 하고, 인라인 인증서나 키 블록은 표식 안에서 바이트 단위로 그대로 보존해야 합니다. PEM 데이터를 다시 줄바꿈하거나, 블록 안의 줄 끝을 바꾸거나, 변환 중에 프로필을 다시 포맷하면 옛 문제를 고치면서 새 문제를 만듭니다.

클라이언트나 서비스를 변환된 파일로 향하게 하고 가장 먼저 보고되는 오류를 보세요. 뒤섞인 토큰이 사라졌다면 인코딩 작업은 끝난 것이고, 그 뒤에 실패하는 것은 다른 문제입니다.

고친 인코딩이 고치지 않는 것

인코딩은 텍스트를 읽는 방식을 정할 뿐, 앞에 있는 클라이언트에 그 옵션이 유효한지는 말해 주지 않습니다. 다른 구현을 위해 내보낸 프로필은 깨끗하게 파싱되면서도 실행 중인 빌드가 지원하지 않는 옵션 때문에, 또는 그 클라이언트에서 인자 의미가 다른 지시자 때문에 거부될 수 있습니다.

그 뒤의 오류는 별도의 조사가 필요합니다: 정확한 철자, 인자의 문법, 그리고 그것을 받아들이는 버전입니다. 파싱에 성공했다고 해서 프로필이 성공한 것은 아닙니다.

조사하는 동안은 국소적으로 처리하세요. 공개 온라인 변환기와 붙여 넣은 hex 덤프는 개인 키가 들어 있을 수 있는 파일에 나쁜 장소인데, 인코딩 문제는 고치기 쉽지만 유출된 키는 그렇지 않습니다.