OpenVPN /24가 예상보다 빨리 클라이언트를 소진하는 이유

클라이언트를 예순 명대에서 더 이상 받지 않는 /24 기반 풀은 설계대로 동작하는 것이지 라이선스 한도에 부딪힌 것이 아니다. net30에서는 모든 클라이언트에 양 끝에 주소가 하나씩 있는 가상 점대점 링크가 주어지며 이것이 주소 네 개를 소비하므로, 256개 주소 서브넷은 프리픽스가 시사하는 양의 약 사분의 일만 지원한다. 중요한 수치는 주소가 아니라 할당이다. 프리픽스를 클라이언트 수로 읽는 것이 숨은 사용자 상한을 찾게 만드는 실수다.

두 가지 토폴로지, 두 가지 산술 모델이 있고, 그중 하나만 사람들이 가정하는 프리픽스와 맞는다.

net30은 클라이언트마다 주소 네 개를 쓴다

net30은 각 세션이 양 끝에 주소를 가진 점대점 링크로 모델링되므로 클라이언트마다 /30 블록을 할당한다. 그 블록에는 주소 네 개가 들어가고 두 개만 사용할 수 있으므로 실제 클라이언트 수는 서브넷의 사분의 일이 된다. /24에서는 서버 자체의 블록과 고정 할당이 빠지기 전에 64개 블록이 남는다. 63 근처로 보고되는 상한은 설정된 최댓값이 아니라 산술이 드러난 결과다.

서버도 자체 할당이 필요하고, 정적 클라이언트 항목은 해당 클라이언트가 접속하든 하지 않든 블록을 소비한다. 둘 다 시작한 프리픽스를 바꾸지 않으면서 동적 범위를 줄인다.

프리픽스보다 풀 경계가 더 중요하다

서버 지시문은 지정한 서브넷보다 좁은 풀을 정의할 수 있고, 도우미 스크립트는 열어 본 프로필에 보이지 않는 추가 설정으로 확장될 수 있다. client-config 디렉터리의 고정 주소는 그 범위 안에 있으며 두 번 나눠 줄 수 없다. 프리픽스는 가능한 최대 공간을 설명할 뿐이고, 실제로 실행 중인 구성이 제공하는 것이 실효 풀이다.

설정된 범위가 작은 것만으로도 토폴로지만큼 상한을 잘 설명하므로, 용량에 대해 결론을 내리기 전에 둘을 비교하라.

클라이언트를 실제로 거부한 한도를 찾아라

먼저 토폴로지와 실효 풀을 읽고, 그다음 고정 할당과 예약 주소를 계산에 넣어라. 주소 공간을 탓하기 전에 max-clients 와 OpenVPN 바깥의 어떤 승인 제어든 확인하라. 마지막으로 거부가 일어난 순간의 서버 메시지를 그 후보들과 대조하라. 메시지는 제약을 지목하고, 숫자는 후보를 좁힐 뿐이다.

동시성 오류와 함께 오는 거부와 할당 오류와 함께 오는 거부는 고치는 방법이 다르고, 그 사이에서 추측하면 유지보수 시간 창을 낭비한다.

토폴로지를 바꾸면 주소 계획이 바뀐다

서브넷 토폴로지로 전환하기는 각 클라이언트에 블록 대신 주소 하나를 주며, 프리픽스가 정말로 너무 작을 때 올바른 선택이다. 클라이언트 주소 매개변수의 의미도 바뀌므로 고정된 모든 할당과 클라이언트별 파일은 손으로 다시 번호를 매기는 대신 다시 도출해야 한다. 새 범위를 계획하고, 정적 항목을 이전하고, 그것을 참조하는 경로를 갱신하라.

전환은 예전 구성의 다른 이름이 아니다. 자체 검토가 필요한 주소 계획 변경으로 다루고, 적어도 한 클라이언트는 이전 방식의 주소를 유지할 것으로 예상하라.

마스크가 아니라 계획에서 풀 크기를 정하라

동시 접속 클라이언트 수에 재접속과 시험을 위한 여유를 더해 크기를 정하고, 선택한 토폴로지에서 그것을 덮는 가장 작은 프리픽스를 고르라. 예순 명 클라이언트 상한을 풀려고 /16으로 넓히는 것은 더 큰 사설 범위가 클라이언트가 이미 닿는 무언가와 충돌할 가능성이 더 크기 때문에 용량 문제를 라우팅과 중복 문제로 바꾸는 일이다.

토폴로지, 풀, 고정 할당, 그리고 그로 인한 클라이언트 상한을 함께 문서화하라. 그러면 다음 용량 질문은 조사가 아니라 산술이 된다.