OpenVPN Connect가 fragment를 거부합니다: 프로필 출처를 고치세요

오류는 가져오기 단계에서, 어떤 협상도 시작되기 전에 나오며, 클라이언트가 받아들이지 않는 지시문의 이름을 밝힙니다. OpenVPN Connect는 OpenVPN 3 라이브러리 코드를 실행하며, 커뮤니티 클라이언트의 fragment 옵션을 전혀 구현하지 않습니다. 그래서 이 문제는 패킷 크기를 조정하는 문제가 아니라 두 끝점 사이의 호환성 문제가 됩니다.

그 줄을 지우면 클라이언트가 구문 분석할 파일은 되지만, 서버는 그 줄이 설명하던 형식을 여전히 기대할 수 있습니다. 무엇이든 고치기 전에 가져오기 화면에서 바깥으로 나가며 확인하세요.

가져오기가 멈추는 지점

가져오기 도구는 서버에 접속하기 전에 지시문을 구문 분석하므로, 거기서의 거부는 문법에 대한 로컬 판단이고 네트워크 결과가 아니며, OpenVPN의 지원되지 않는 지시문 목록도 같은 제한을 기록합니다. 이는 같은 파일이 같은 컴퓨터에서 커뮤니티 클라이언트에서는 동작하고 Connect에서는 실패할 수 있는 이유를 설명합니다. 메시지에서 지시문 이름을 읽고, 그 문구가 클라이언트가 무엇에 반대했는지를 보여 주는 유일한 증거이므로 원본 파일을 보관하세요. 가져오기 오류와 연결 시간 초과는 서로 다른 단계에서 오므로 대응도 달라야 합니다.

메시지가 fragment를 지목한다면, 남는 질문은 서버도 그것에 의존하는지입니다. 받은 프로필을 건드리기 전에 그 답부터 내리세요.

fragment가 커뮤니티 클라이언트에서 바꾸는 것

커뮤니티 클라이언트에서 이 지시문은 OpenVPN 자체의 데이터그램 분할을 켜며, 페이로드가 바깥 IP 계층에 닿기 전에 나눕니다. 큰 UDP 데이터그램을 버리는 경로를 지나가기 위해서, 그리고 경로 MTU 탐색을 믿을 수 없는 곳에서 터널을 쓸 수 있게 유지하기 위해서 존재합니다. 이것은 인터페이스 MTU를 낮추는 것과 같은 말이 아니고, 운영체제가 하는 IP 계층 분할도 아닙니다. 이 방식을 갖추지 않은 클라이언트는 숫자를 낮춰서 얻을 수 없습니다.

이 설정은 서버 구성에도 있으므로, 사본에서 빼면 바뀌는 것은 내 쪽뿐입니다. 서버는 그 옵션을 이해하는 상대를 여전히 기대할 수 있고, 구문 분석되는 프로필은 아직 성립하는 세션이 아닙니다. 이 두 사실이 편집한 파일이 연결되었다가 멈추는 혼란스러운 중간 상태를 설명합니다.

이 클라이언트용으로 만들어진 프로필을 요청하세요

깔끔한 길은, 서비스가 그런 것을 공개한다면, OpenVPN Connect용으로 문서화된 두 번째 프로필입니다. 많은 제공자가 공개하며, 차이는 보통 가리키는 끝점이 아니라 생략하는 지시문에 있습니다. 지원 데스크는 잘려 나간 파일을 진단하는 것보다 프로필을 클라이언트에 맞추는 편이 훨씬 빠르므로, 오류를 설명하는 대신 클라이언트 이름으로 요청하세요.

서버를 직접 운영한다면 결정의 범위는 내 클라이언트보다 넓습니다. 분할을 끄면 나쁜 경로에서 연결을 유지하려고 그것이 필요했던 상대를 포함해 모든 피어에 영향을 줍니다. 영향을 받는 클라이언트를 위해 두 번째 리스너나 두 번째 구성을 공개하면 기존 사용자는 계속 동작하고, 더 새로운 클라이언트는 구문 분석할 수 있는 것을 받습니다. 그 대응 관계는 금방 사라지므로, 어느 쪽을 택하든 어떤 구성이 어떤 클라이언트를 맡는지 적어 두세요.

연결을 검증하세요, 가져오기만이 아니라

가져오기 성공은 구문 분석기가 파일을 받아들였다는 것만 증명합니다. 내가 통제하는 컴퓨터에서 커뮤니티 클라이언트로 같은 프로필을 써서 터널을 세우고, 전송과 암호 협상에 대해 로그를 읽으세요. 아래 명령이 데스크톱 앱을 거치지 않고 그 일을 합니다.

openvpn --config client.ovpn --verb 3
ip -4 addr show tun0
curl -sS --interface tun0 -o /dev/null -w '%{http_code}\n' --max-time 8 https://example.com/

로그를 보면 옵션 오류가 어떤 TLS 교환보다 먼저 나타나고 인증이나 암호 실패가 그 뒤에 나타나므로, 시도가 어디서 멈췄는지 알 수 있습니다. 터널이 올라왔는데 요청이 계속 실패한다면 문제는 호환성에서 라우팅으로 옮겨 간 것입니다. 서버에 대해 무엇이든 결론 내리기 전에 같은 네트워크에서의 Connect 동작과 비교하세요.

동작하는 프로필과 클라이언트 버전을 메모 옆에 두세요. 앞으로의 클라이언트 릴리스가 어떤 지시문을 지원하면, 아무도 서버를 건드리지 않아도 답이 바뀝니다.