모든 OpenVPN 노드에 하나의 서비스 IP: 그것이 하지 않는 일

클라이언트는 여러 OpenVPN 서버 중 하나에 연결한 뒤 그 노드에서 실행되는 작은 서비스가 필요합니다: 상태 페이지, 메트릭 엔드포인트, 백업 에이전트입니다. 모든 노드에 같은 사설 서비스 주소를 주면 클라이언트 구성은 어느 서버에 붙었든 동일해집니다. 그 편리함은 실제이며, 동시에 과대 해석하기도 쉽습니다: 공유 주소는 어느 노드에 도달했는지를 알려줄 뿐, 무언가가 이중화되어 있다는 뜻은 아닙니다.

같은 주소가 모든 노드에서 동작하는 이유

각 노드는 주소를 로컬로 보유하고 그 주소에 응답하므로, 현재 터널을 통해 그 주소에 도달한 클라이언트는 그 터널 반대편의 서비스를 얻습니다. 노드 사이에는 조정되는 것이 없고, 한 노드에서 다른 노드로 트래픽이 건너가지도 않습니다.

주소는 복제된 것이 아니라 반복된 로컬 레이블입니다. 각 노드는 오직 자기 자신을 위해서만 응답하며, 어느 노드도 다른 노드를 대신해 그 주소의 트래픽을 전달하지 않습니다. 이것이 서버들이 독립적인 동안 하나의 클라이언트 구성이 유효하게 유지되는 이유입니다. 또한 이 설계가 노드 사이의 조정을 전혀 필요로 하지 않는 이유이기도 합니다.

그래서 같은 구성이 노드 사이의 라우팅 프로토콜 없이 모든 서버에서 동작합니다. 또한 이 설계가 상태에 대해 아무 말도 하지 않는 이유이기도 합니다: 주소는 호스트에 묶여 있고 서비스가 유용한지에 묶여 있지 않으므로, 고장 난 노드에도 정상 노드와 똑같이 존재합니다.

터널이 아니라 루프백에 할당하세요

주소를 루프백 인터페이스에 두면 어떤 터널 장치의 수명과도 분리되므로, 재연결이나 구성 다시 읽기가 주소를 제거하지 않습니다. 주소는 호스트가 존재하는 한 존재합니다.

lo 위의 주소는 필터가 아닙니다. 서비스는 여전히 그 주소에서 수신해야 하고, 호스트 방화벽은 여전히 실제 인바운드 경로를 평가하며, 그 경로는 터널 인터페이스로 도착합니다. 루프백이 곧 로컬 전용이라고 가정하는 사람은 결국 정당한 클라이언트를 차단하거나 의도하지 않은 것을 노출하게 됩니다.

할당을 훅에서 다시 추가하는 대신 호스트의 네트워크 구성으로 영속화하세요. 설정 훅은 터널이 올라오지 않은 노드에서는 실행되지 않으며, 서비스 주소는 터널 활동에 의존해서는 안 됩니다. 주소를 배포판이 관리하는 인터페이스 구성에 넣고, 그다음 한 번 재부팅해서 확인하세요. 재부팅은 나중의 구성 변경을 견디는 유일한 테스트입니다.

ip address show dev lo | grep 10.250.0.1
ip address add 10.250.0.1/32 dev lo

경로 하나를 밀어 넣고 목적지 하나를 의미하세요

클라이언트는 그 주소에 대한 호스트 경로가 필요하며, 그것은 접속하는 서버가 제공합니다. 모든 서버가 같은 목적지를 제공하므로 클라이언트가 이동해도 프로파일은 바뀌지 않습니다.

서비스를 탓하기 전에 클라이언트가 무엇을 설치했는지 확인하세요.

ip route get 10.250.0.1

HTTP 서비스라면 주소에 이름을 주고 그 이름에 대한 인증서를 주세요. 공유 IP는 정체성이 아니며, TLS 검증을 없애지도 않고, 사설 키 하나를 모든 노드에 복사하는 것을 정당화하지도 않습니다. 공유 주소로 해석되는 이름은 인증서 이야기를 평범하게 유지하고, 필요하면 노드별 정체성을 유지하게 해줍니다.

공유 주소가 할 수 없는 일

장애 조치를 제공하지 않습니다. 선택한 노드가 죽으면 주소도 함께 죽고, 클라이언트는 다른 곳으로 다시 연결해야 합니다.

새 연결은 이전 연결을 전혀 모르는 다른 호스트에서 종료되므로, 살아 있는 TCP 세션을 이전하지 않습니다.

정상 노드를 고르지도, 부하를 분산하지도, 노드 사이에서 데이터를 동기화하지도 않습니다. 그것들은 각자 고유한 장애 방식을 가진 별개의 메커니즘이며, 주소 지정 요령이 그것들을 덮는다고 가장하는 것이 단순한 설계가 마땅치 않은 복원력 명성을 얻는 길입니다. 두 터널이 동시에 활성이라면 목적지의 의미가 모호해지므로, 활성 터널은 하나라는 가정을 명시적으로 유지하세요.

서비스 정체성을 이름과 함께 유지하세요

주소가 무엇을 뜻하는지 적어 두세요: 클라이언트가 현재 연결된 노드의 서비스에 도달한다는 것입니다. 그 한 문장이 이 패턴이 끄는 오해의 대부분을 막습니다.

그다음 조각들을 함께 문서화하세요: 주소, 그것이 사는 인터페이스, 서버가 밀어 넣는 경로, 그리고 서비스가 제시하는 이름과 인증서입니다. 미래의 독자가 검증할 수 있는 네 가지 작은 사실을, 실제로 확인할 순서대로 적습니다.

요구가 노드 로컬 서비스에 대한 안정적인 목적지라면 이 패턴이 맞고 비용은 거의 들지 않습니다.

요구가 가용성이라면 한 계층 위로 올라가세요: 로드 밸런서, 상태 확인이 있는 서비스 이름, 또는 노드를 교체하는 방법을 이미 아는 오케스트레이션 시스템입니다.

그것을 일찍 결정하면 공유 주소는 편리한 레이블이라는 본래 모습을 유지하고, 결코 설계되지 않은 일을 조용히 기대받는 구성 요소가 되지 않습니다.