두 서버에 걸친 하나의 VPN 계정: 세 개의 상태 원장

두 VPN 노드 중 어디로든 로그인할 수 있는 하나의 계정은 소프트웨어 문제가 되기 훨씬 전에 설계 문제를 제기합니다. 계정의 관점, 각 노드가 소유한 네트워크, 연결된 클라이언트가 유지하는 세션은 서로 다른 세 종류의 상태이며, 이들을 이리저리 복사할 때 서로 다른 방식으로 실패합니다. 셋 모두를 하나의 시스템으로 복사하는 것은 그중 하나를 잃는 흔한 방법입니다.

아래 세 원장을 순서대로 살펴보십시오. 각각은 무엇이 권위이고 무엇이 로컬이며 다른 노드가 없을 때 무슨 일이 일어나는지를 묻고, 답은 서로에게서 이어지지 않습니다.

누가 연결할 수 있는가: 하나의 권한, 여러 노드

입장 허용 원장부터 시작하십시오: 어떤 ID 원본이 권위인지, 어떤 인증서 발급자를 신뢰하는지, 어떤 계정이 자격이 있는지, 어떤 두 번째 요소가 적용되는지, 각 계정이 어디까지 도달할 수 있는지입니다. 그다음 각 노드가 변경을 어떻게 얼마나 빨리 알게 되는지 적어 두십시오.

공유 데이터베이스는 그 답의 가능한 구성 요소 하나입니다. 관련된 모든 정책이 그곳에 산다는 증거도, 모든 노드가 같은 순간에 변경을 적용한다는 증거도 아닙니다. 노드 A에서 비활성화되었지만 노드 B에서는 여전히 허용되는 계정은 오프보딩 절차가 끝나지 않았다는 뜻입니다.

권한에 도달할 수 없을 때 노드가 무엇을 할지 정하십시오. 장애 중에 캐시된 자격 증명을 받아들이는 것은 보안 비용이 따르는 정책 선택이고, 거부하는 것은 가용성 비용이 따르는 정책 선택입니다. 둘 다 변호할 수 있습니다; 문서화하지 않고 두는 것은 그렇지 않습니다.

발급자의 권한도 계정 데이터와 분리해 두십시오. 여러 게이트웨이가 서명 키를 보유하지 않고도 같은 CA를 신뢰할 수 있으며, 각 노드에는 여전히 자체 서버 인증서와 자체 클라이언트 측 신뢰 관계가 필요합니다.

노드가 소유하는 것: 주소와 경로

두 번째 원장은 각 노드에 로컬입니다: 수신 주소, 서버 신원, 주소 풀, 사설 자원으로 가는 경로, 리졸버 정책, 트래픽이 인터넷 쪽으로 나가는 방식입니다. 같은 계정을 어느 노드든 서비스할 수 있지만 이 객체들은 서로 다르게 남습니다.

돌아오는 경로가 잊히는 부분입니다. 두 노드가 같은 풀에서 주소를 나눠 주면 사설 네트워크는 특정 클라이언트가 어느 노드의 것인지 알 수 없고, 응답이 잘못된 곳으로 갈 수 있습니다. 다른 풀에도 경로와 권한이 필요하므로 별도의 번호 범위는 완전한 설계가 아닙니다.

클라이언트를 의도적으로 한 노드로 보내십시오. DNS 선택, 클라이언트 엔드포인트 목록, 프런트엔드 서비스는 각각 다른 메커니즘이며 상태 확인과 장애 조치 동작도 다릅니다. 하나를 고르는 것은 괜찮습니다; “로드 밸런싱”을 설계로 삼으면 돌아오는 경로와 장애 동작이 정의되지 않은 채 남습니다.

문서화된 제품 사례가 여기서 도움이 됩니다. Pritunl의 복제 문서는 VPN 네트워크를 복제본별 객체로 다루며, 다른 복제본의 클라이언트가 서로에게 도달하려면 추가 경로와 연결이 필요합니다. 이는 제품에 특정한 배치이며 Community OpenVPN을 위한 조리법은 아니지만, 복제본을 추가하는 것이 계정 저장소만이 아니라 네트워크를 바꾸는 이유를 보여 줍니다.

세션이란 무엇인가: 행이 아니라 살아 있는 상태

세 번째 원장은 활성 세션입니다. 연결된 클라이언트는 자신을 받아들인 노드에 프로토콜 상태와 네트워크 할당을 가집니다. 계정이 다른 노드에 알려져 있다고 해서 그 노드에 세션, 키, 패킷을 계속할 능력이 생기지는 않습니다.

노드가 실패할 때 무슨 일이 일어나는지 분명히 하십시오. 지원되는 결과는 새 인증과 새 주소로 다른 노드에 다시 연결되는 것이고, 그 뒤 애플리케이션은 각자의 방식으로 회복합니다. 중단 없는 인계가 필요하다면 그 요구에는 명시적인 구현 지원이 필요하며, 데이터베이스 복제에서 끌어낸 추론으로는 충분하지 않습니다. 답을 당직 엔지니어가 찾을 수 있는 곳에 적어 두십시오.

용량 규칙에도 같은 대우가 필요합니다. 계정당 동시 세션 두 개라는 한도를 노드 사이에서 강제하려면 점유된 자리들에 대한 조정된 시각을 가진 권위가 있어야 합니다. 노드 로컬 목록과 이력 계정 기록을 더해도 그 시각이 되지 않습니다.

세 원장을 시험하기

각각을 따로 시험하십시오. 노드 A로 로그인하고, 다음으로 노드 B로 로그인하여 둘 다 예상한 주소 범위로 성공하는지 확인하십시오. 신원을 하나 회수하고, 우연히 시험한 노드만이 아니라 두 노드를 모두 확인하십시오. 그다음 한 노드를 멈추고 클라이언트와 사설 애플리케이션이 실제로 무엇을 하는지 관찰하십시오.

승인 테스트에 돌아오는 경로를 포함하십시오. B에 연결되지만 A 뒤의 자원에서 응답을 받지 못하는 클라이언트는 입장 검사는 통과하고 네트워크 검사는 실패한 것이며, 그 구분이 보고서에 나타나야 합니다.

세 원장 모두에 명시적인 소유자, 변경 경로, 장애 동작이 있을 때에만 다중 노드 계정 설계가 완성됩니다. 설정 파일을 노드 사이에 복사하는 것은 그 질문들 중 어느 것에도 답하지 않습니다.