pfSense에서의 OpenVPN 페일오버 세 가지 유형과 세 가지 메커니즘

pfSense의 „OpenVPN 페일오버“는 적어도 세 가지 서로 무관한 설계를 아우르며, 각각 다른 메커니즘이 필요합니다. 예비 인터넷 회선으로 터널을 살려 두는 것, 다른 서버로 다시 접속하는 것, LAN 트래픽을 이미 수립된 다른 터널로 보내는 것은 한 기능의 변형이 아닙니다. 게이트웨이 그룹을 만들기 전에 어떤 장애를 막는지 고르십시오. 하나를 고치는 그룹은 나머지 둘에는 아무 일도 하지 않습니다.

그룹을 만들기 전에 장애를 명명하십시오

장애 중에 참이기를 바라는 문장을 쓰십시오. „터널이 예비 WAN으로 다시 연결된다“와 „지사는 여전히 다른 터널로 애플리케이션에 도달한다“는 다른 문장입니다. 전자만 전송에 관한 것입니다.

그다음 메커니즘에 대응시키십시오. 로컬 WAN 상실은 인터페이스 선택 문제이고, 죽은 원격 끝점은 연결 목록 문제이며, 수립된 터널 내부의 쓸 수 없는 경로는 라우팅과 정책 문제입니다.

로컬 WAN: 전송을 옮긴다

pfSense OpenVPN 클라이언트의 경우 지원되는 다중 WAN 구성이 적절한 게이트웨이 그룹을 클라이언트가 묶이는 인터페이스로 선택합니다. 주 회선이 실패할 때 바깥 연결이 예비 회선으로 나가게 하는 것이 바로 이것입니다. 그 자체로 내부 트래픽의 경로가 바뀌지는 않습니다.

같은 설계의 서버 쪽은 별개입니다. 여러 공인 주소로 접근되어야 하는 OpenVPN 서버는 각 항목마다 수신기와 인바운드 정책이 필요하며, 두 회선으로 걸 수 있는 클라이언트만으로는 부족합니다. 공인 항목 하나가 동작한다고 해서 두 번째가 구성되었다는 증거는 아닙니다.

전달되는 LAN 패킷에 대한 정책 기반 라우팅 규칙은 로컬에서 만들어진 VPN 전송 연결을 옮기는 설정이 아닙니다. 서로 다른 두 조회이며, 하나를 바꿔도 다른 하나는 바뀌지 않습니다.

원격 끝점: 다른 서버

대체 원격은 연결 목록의 기능입니다. 현재 항목이 응답하지 않으면 클라이언트가 다음 항목을 시도하며, 이는 특정 호스트가 죽었을 때 유용하고 자신의 상향 회선이 죽었을 때는 유용하지 않습니다. 두 장애는 사용자 책상에서는 비슷해 보이지만 고치는 방법이 다릅니다.

각 후보는 호환되는 인증, 호환되는 클라이언트 정책, 같은 사설 자원에 대한 접근을 갖춘 진짜 대체여야 합니다. 같은 고장 난 기반으로 해석되는 두 번째 호스트 이름은 예비가 아닙니다. 필요한 경로가 없는 서버도 마찬가지이며, 핸드셰이크가 아무리 건강해 보여도 달라지지 않습니다.

이 메커니즘은 두 터널을 동시에 전달하게 하지도 않습니다. 연결을 하나씩 순차적으로 바꾸며, 그 사이의 공백은 돌아가던 모든 것에 보입니다.

터널 경로: 다른 출구를 고른다

두 터널이 이미 올라와 있고 트래픽이 더 건강한 쪽을 써야 한다면, 메커니즘은 자체 게이트웨이를 가진 할당된 VPN 인터페이스와 올바른 트래픽을 그리로 보내는 명시적 정책 규칙입니다. 그 할당된 인터페이스 위에 게이트웨이 그룹을 두면 우선순위와 모니터링을 표현할 수 있습니다.

그 설계는 선택에 관한 것이지 복구에 관한 것이 아닙니다. 새 연결을 두 번째 터널로 옮겨도 첫 번째에 이미 수립된 세션에 대해서는 아무 말도 하지 못하며, 상대가 새 출발지 주소를 받아들일지도 알 수 없습니다. 이를 복구 메커니즘으로 보는 것이 기대를 너무 높게 잡는 방식입니다.

기존 세션이 살아남아야 한다는 것이 요구라면 분명히 말하십시오. 대부분의 구현은 살아 있는 흐름을 터널 사이로 옮기지 않으며, 옮긴다고 가정하고 설계하면 도면에서는 맞아 보이지만 실제로는 열린 연결을 모두 떨어뜨리는 페일오버가 됩니다.

모니터, NAT, 페일클로즈 규칙

모니터는 터널이 제공해야 할 것을 시험해야 합니다. 터널 상대에서는 응답하지만 그 뒤의 애플리케이션 네트워크에서는 응답하지 않는 대상은 사용자가 아무것도 보지 못하는데도 건강하다고 보고합니다. 도달할 수 없는 진단 대상은 경로가 정상인데도 죽었다고 보고합니다. 주소를 의도적으로 고르고, 의도한 터널로만 도달할 수 있는지 확인하십시오.

두 출구 모두에서 나가는 NAT를 확인하십시오. 주 회선에서 동작하는 변환은 예비의 출발지 주소를 설명하지 못하며, 원격 사설 네트워크는 제시하는 출발지와 맞는 귀환 경로가 필요합니다. 한 경로에서 맞는 변환이 다른 경로에서는 조용히 틀릴 수 있습니다.

그다음 절대 WAN을 써서는 안 되는 트래픽을 어떻게 할지 정하십시오. pfSense는 선택한 게이트웨이가 죽은 규칙에 대해 정의된 동작이 있고, 뒤에 오는 넓은 통과 규칙이나 기본 경로가 그 의도를 뒤집을 수 있습니다. 차단된 결과를 요구 사항으로 적고, 경로를 내려서 검증하십시오.

상실과 복구를 따로 시험하고, 생성할 권한이 있는 트래픽으로, 바깥 연결을 나르는 WAN, 애플리케이션 요청을 나르는 터널, 응답이 지나는 경로 세 가지를 동시에 보십시오. 초록 게이트웨이 표시 두 개는 그 세 가지에 들지 않습니다. Netgate의 다중 WAN 안내서 는 이것이 의존하는 전송 바인딩과 내보내는 클라이언트 대안을 설명합니다.