OpenVPN 경로 한도를 실제로 소유한 구성 요소는 무엇인가?

경로 이백 개를 담은 프로필이 한 기계에서는 동작하고 다른 기계에서는 마흔 개만 설치된다. 엔진, 그것을 시작하는 통합, 그리고 그것을 공급하는 서버가 각각 할 말이 있고, 어느 쪽이든 목록을 서로 다른 지점에서 멈출 수 있다. 실패를 하나의 한도로 읽으면 잘못된 파일로 가게 된다. 구조는 세 단계이며, 멈춘 단계는 무엇을 찾아야 하는지 알면 눈에 보이는 흔적을 남긴다.

세 단계, 세 가지 다른 한도

먼저 엔진이 옵션을 해석하고 이 버전이 그것을 이해하는지 판단한다. 다음으로 통합이 엔진이 보고한 것을 설치하며, 그 자체의 코드가 목록을 제한하거나 다시 만들 수 있다. 마지막으로 서버가 어느 클라이언트 단계도 무언가를 보기 전에 특정 신원에 경로를 몇 개 보낼지 정한다. 세 단계, 세 개의 천장, 그리고 그중 하나만 프로필에 적힌 숫자다.

천장 하나를 올린다고 다른 것들이 달라지지 않는다. 거부된 경로는 서버의 정책 결정일 수도, 클라이언트가 해결한 겹침일 수도, 초과분을 버린 설치 쪽 한도일 수도 있다. 각 경우의 해결책은 다르다.

무엇이든 측정하기 전에 셋을 분리하라. 파서 오류는 토큰을 지목하고, 설치 쪽 한도는 짧은 경로 표를 남기며, 정책 결정은 아무것도 남기지 않는다. 흔적이 먼저 어느 단계를 살펴야 하는지 알려 준다.

파서가 먼저 말한다

알 수 없는 옵션은 크게 그리고 이르게 실패하고 오류 문구가 토큰을 지목하므로, 이것이 가장 알아보기 쉬운 단계다. 정확한 메시지를 설치된 엔진 버전과 비교하라 — 한 릴리스에서 추가된 옵션은 그 이전 릴리스에서 알 수 없기 때문이다. 더 새로운 배포에서 복사한 프로필이 그 불일치의 흔한 원인이다. 파서는 인식하지 못하는 지시문을 결코 조용히 무시하지 않는다.

받아들여진 옵션은 결과에 대해 아무 말도 하지 않는다. 해석은 성공하고, 목록은 여전히 설치 쪽에서 잘릴 수 있으며 서버가 아예 제공하지 않았을 수도 있다. 깨끗한 해석을 계속할 허가로 여겨라, 증거가 아니라.

버전 문자열은 실제로 실행된 바이너리에서 기록하라, 패키지 관리자가 무엇이 설치되어 있다고 생각하는지가 아니라. 이 둘은 예상보다 자주 어긋난다.

설치 쪽에도 자기 천장이 있다

활성화를 소유한 구성 요소가 엔진 바이너리가 아니라 NetworkManager 플러그인일 수 있고, 터널이 하나도 생기기 전에 자체 한도를 부과할 수 있다. 그 편집기가 실행 중인 엔진이 결코 읽지 않는 필드를 보여 주거나, 편집기가 표시하지 않는 필드를 읽을 수 있다. 두 상황 모두 밖에서 보면 클라이언트 버그처럼 보인다. 어느 쪽도 프로필을 편집해서 고쳐지지 않는다.

설정된 수가 아니라 도착한 수를 세라. ip route show dev tun0 명령이 설치된 경로를 나열하며, 그 수를 보낸 목록과 비교하면 버려진 경로와 한 번도 보내지 않은 경로가 구분된다. 보낸 수와 일치하는 수라면 의심은 다시 서버로 간다.

더 큰 숫자를 강제하려고 엔진 바이너리를 셸로 감싸면 업그레이드가 흐려지고 되돌리기가 추측이 된다. 또한 다음에 설정을 읽는 사람에게 실제 한도를 숨긴다.

무엇을 제안받았는지는 서버가 정한다

클라이언트별 정책은 목록을 전송 전에 줄일 수 있다. 클라이언트 전용 파일이 한 신원에 경로를 더할 수도 있고, 그룹 정책이 그것들을 빼버릴 수도 있으며, 클라이언트는 걸러진 경로와 한 번도 정의되지 않은 경로를 구별할 수 없다. 바로 이 모호함 때문에 서버 기록이 중요하다. 템플릿이 아니라 그 신원의 실제 전송 목록을 요구하라.

서버 기록을 받은 목록과 비교하라. 둘 사이의 간격이 정책 계층이며, 보통 프로필이 암시하는 것보다 작다.

설계가 허락하면 인접한 네트워크를 요약하고 오래된 항목을 삭제하라. 더 적고 더 큰 경로가 더 높은 천장보다 많은 사례를 해결한다.

숫자를 올바른 곳에서 바꿔라

한도를 실제로 소유한 구성 요소의 문서화된 설정을 사용하라. 플러그인에 그 필드가 없다면, 플러그인이 기능보다 오래되었는지 아니면 다른 기반이 경로를 소유하는지 확인하라. 그다음 선택한 값 옆에 엔진, 플러그인, 서버 버전을 기록하라. 다음 업그레이드가 질문을 다시 열며, 그 메모가 질문을 답할 수 있게 만든다.

셋 중 어느 것이든 업그레이드한 뒤에는 다시 시험하라. 올바른 곳에서 올린 한도도 그것을 적용하는 구성 요소가 바뀌면 움직인다. 버전 기록만이 그 움직임을 예측 가능하게 만든다.