Access Server에서 Community OpenVPN으로: 무엇을 다시 만들어야 하는가

Access Server와 Community OpenVPN은 같은 프로토콜을 사용하고 그 밖의 거의 모든 것은 같은 방식이 아닙니다. 핸드셰이크, 암호 협상, 터널의 데이터 평면은 호환되므로 클라이언트는 프로필을 수정하지 않고도 둘 중 어느 쪽에나 연결할 수 있습니다. 차이는 구성의 소유자입니다. 한 제품은 정책을 작성하고 강제하는 관리 계층을 제공하고, 다른 제품은 구성 파일과 몇 가지 훅을 건네고 당신이 결정하기를 기대합니다.

그 차이가 곧 이전 계획입니다. 옛 제품이 당신을 대신해 결정한 모든 것은 새 배포의 어딘가에서 명시적 결정이 되어야 합니다.

두 배포가 더 이상 교체 가능하지 않은 지점

Access Server에서는 웹 관리 인터페이스가 사용자, 그룹, 사용자별 권한, 인증서 발급, 그리고 사람이 내려받는 프로필 번들을 소유합니다. 그 아래의 데몬은 그 계층이 구성합니다, 그래서 실행 중인 서비스는 손으로 거의 편집하지 않는 저장된 상태의 산물입니다. Community OpenVPN에서는 구성 파일이 곧 상태입니다. 리스너, 인증 기관, 인증 훅, 푸시되는 모든 옵션을 지정하며 아무것도 당신 대신 다시 쓰지 않습니다. 같은 TLS 기계가 아주 다른 두 소유 모델 아래에 놓이는 셈입니다.

짧은 대응표가 그 간격을 구체화합니다. 사용자와 그룹은 다시 만들기 전까지 옛 데이터베이스에만 존재합니다. 프로필 번들은 구성 파일과 당신이 직접 배포하는 인증서가 됩니다. 사용자별 권한은 client-config-dir 안의 지시문이 됩니다. 관리 인터페이스는 인증서를 발급하고 파일을 편집하기 위해 당신이 고르는 프로세스가 됩니다.

서버를 건드리기 전에 그 대응표를 적어 두십시오. 채울 수 없는 행은 당신이 곧 잃을 기능이며, 조용히 잃는 것이 이전을 몇 주 뒤 장애로 만드는 길입니다.

신원은 인증서 파일과 함께 옮겨지지 않습니다

옛 기관의 인증서가 새 서비스에서 올바르게 해석되더라도 잘못된 신원일 수 있습니다. 옛 제품이 새 서비스가 볼 수 없는 계정 상태와 그것들을 짝지었기 때문입니다. 먼저 새 배포가 인증서만으로 인증하는지, PAM이나 RADIUS에 닿는 플러그인으로 인증하는지, 아니면 조합으로 인증하는지 정하고, 각 선택이 필요한 속성을 유지하는지 확인하십시오. 사용자별 신원이 없는 공유 인증서는 그것을 가진 모두에게 하나의 자격 증명입니다. 폐기도 첫날부터 동작해야 하며, Community OpenVPN에서는 crl-verify가 참조하는 CRL 파일과 그것을 다시 생성하는 프로세스를 뜻합니다.

등록은 전환 전에 계획하고, 뒤로 미루지 마십시오. 새 인증서, 검증된 폐기 경로, 한 사람을 비활성화하는 문서화된 방법은 전제 조건이지 후속 작업이 아닙니다. 다중 요소 인증이 옛 제품의 통합에서 왔다면 대체를 분명히 밝히십시오. 설치되지 않은 플러그인은 최악의 순간에 닫힌 채 실패합니다.

라우팅과 이름 해석은 구성을 쓰는 사람을 따릅니다

경로, DNS 설정, 전체 터널 동작은 두 제품 모두에서 푸시되는 옵션이지만, 당신을 위해 계산하는 것은 한쪽뿐입니다. Community OpenVPN에서는 푸시 지시문을 직접 쓰고, redirect-gateway가 서버에 속하는지 클라이언트에 속하는지 결정하고, 호스트에 포워딩과 NAT가 있는지 확인합니다. 끝난 핸드셰이크는 포워딩, 주소 변환, 클라이언트가 실제로 받은 경로에 대해 아무것도 알려주지 않습니다.

클라이언트별 동작에는 client-config-dir와 클라이언트 인증서의 common name으로 명명한 파일이 필요하고, 사이트 간 피어에는 그 뒤의 프리픽스에 대한 iroute 항목이 필요합니다. 이름이 틀리면 옵션은 오류 없이 무시됩니다. 운영이 아닌 클라이언트 하나를 자체 주소 풀에서 시험한 다음, 할당된 주소와 받은 경로, 최종 리졸버 설정을 읽으십시오.

옛 서비스가 돌아올 수 있도록 전환을 순서화하십시오

새 리스너를 다른 포트나 주소에서 실행하고, 대체를 입증하는 동안 옛 리스너가 트래픽을 계속 처리하게 하십시오. 한 소켓에 두 데몬은 롤백 계획이 아닙니다.

한 번에 한 그룹씩, 자체 인증서와 자체 풀, 자체 경로와 함께 옮기고, 되돌아가는 길을 사고 중에 발견하지 말고 미리 연습하십시오. 새 서비스를 먼저 멈춰야만 동작하는 롤백도 롤백이지만, 아무것도 불타지 않을 때 시험해야 합니다.

마지막으로 직접적인 대응이 없는 기능을 나열하고 각각의 운명을 문서로 정하십시오. 셀프서비스 프로필 다운로드, 사용자별 권한 플래그, 관리 인터페이스 자체, 실시간 연결 보고입니다. 그것들을 문서화된 수동 절차로 바꾸는 것은 정당한 답입니다. 행을 비워 두는 것은 아닙니다.

옛 포털을 본 적 없는 사용자가 등록하고, 연결하고, 의도한 내부 주소에 도달하고, 깔끔하게 폐기될 수 있을 때 작업은 끝납니다. 그 전의 모든 것은 준비입니다.