두 번째 WAN VPN 항목이 실패하는 동안 기본 항목은 계속 작동한다

기본 터널은 올라간 채로 있고 사용자는 계속 작업하며 두 번째 ISP 회선은 무엇을 바꾸든 유휴 상태로 남는다. 백업 회선의 주소를 게시하고 그쪽으로 이름을 지정했으며 어쩌면 클라이언트에 백업 항목을 추가했지만, 클라이언트는 아예 시도하지 않거나 인증까지 통과한 뒤 죽는다. 내가 추적한 사례에서 페일오버 기능 자체는 대개 정상이었고, 빠진 것은 항목을 쓸 수 있게 만드는 다섯 가지 중 하나였다. 그 인터페이스에서 아무것도 수신하지 않는데도 이름만 백업 주소로 확인될 수 있고, 응답이 기본 경로로 나가는데도 리스너가 연결을 받아들일 수 있다. 각 WAN을 자체 계약을 가진 별도 항목으로 다루면 장애가 클라이언트 버그처럼 보이지 않는다.

각 WAN에는 자체 항목 계약이 필요하다

WAN마다 다섯 개 필드를 기록한다: 공용 이름과 주소, 전송과 포트, 이를 종료하는 인터페이스 또는 컨텍스트, 제시해야 할 피어 ID, 그리고 응답이 나가는 위치다. 회선이 둘이면 완전한 세트도 둘. 두 번째 세트에 종료 인터페이스나 반환 경로가 없으면 백업 항목이 아니라 의도를 설명하는 DNS 레코드가 있는 것이다.

장비와 그 버전도 이 구성이 필요하다. DNS 레코드는 다른 인터페이스에서 서비스를 열 수 없고, 많은 플랫폼에서 리스너는 장치 단위가 아니라 주소 단위로 설정된다. ASA의 인터페이스 기반 IPsec은 암호화 맵과 터널 그룹을 외부 인터페이스에 묶으므로 두 번째 업링크에는 패킷이 실제로 도착하는 곳에 정책이 필요하다. 경로 기반 설계는 다르게 동작하며, 리스너가 모든 주소나 이름이 지정된 하나의 주소에 바인딩될 수 있고 그 선택이 ISP B가 응답할 수 있는지를 결정한다.

두 번째 WAN이 실제로 응답하는지 확인한다

게이트웨이 뒤의 머신이 아니라 두 회선의 바깥에서 테스트하고, 클라이언트 프로필이 쓰는 바로 그 이름을 테스트한다. TLS 리스너라면 빠른 확인은 openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts 를 네트워크 밖 호스트에서 실행하는 것이다. 필요한 것은 프로필의 이름과 일치하는 체인을 가진 완료된 핸드셰이크이며, 연결을 받아들이기만 하는 TCP 포트가 아니다.

RFC 9525 는 클라이언트가 무엇을 확인하는지 설명한다: 도달하려던 ID를 서비스가 제시하는 인증서와 비교한다. 기본 항목의 인증서를 돌려주는 두 번째 항목이나 두 이름 중 어느 것도 나열하지 않는 기본 인증서는 포트가 열려 있고 방화벽이 허용해도 이 테스트에서 실패한다.

여기서 실패의 대부분은 두 패턴으로 설명된다. 연결이 매달리면 보통 해당 인터페이스에 리스너가 없거나, 기본 서브넷만 허용하는 접근 규칙이 있거나, 두 번째 회선 앞의 통신사 장비가 포트를 떨어뜨리는 것이다. 잘못된 ID로 핸드셰이크가 끝나면 보통 다른 트러스트포인트, 기본 가상 호스트, 또는 ID를 맞추지 않고 기본에서 복사한 구성이 원인이다.

응답을 따라가되 요청만 보지 말라

두 번째 WAN은 대개 반환 경로에서 깨진다. 요청은 ISP B로 들어오고 장비가 응답하며, 응답은 ISP A의 기본 경로로 나가면서 클라이언트가 요청한 적 없는 출발지 주소를 쓴다. 상태 기반 변환은 이를 악화시킨다: 매핑이 기본 인터페이스용으로 만들어졌다면 반환 패킷은 변환을 놓치거나 클라이언트 방화벽이 버리는 출발지를 갖는다. 공급자도 자신이 준 회선에 속하지 않는 출발지 주소를 버리므로, 이것은 깔끔한 프로토콜 오류가 아니라 단방향 블랙홀처럼 보인다.

두 번째 항목을 출발지로 하는 트래픽의 라우팅 결정을 확인한다. 응답은 요청이 도착한 인터페이스로 나가야 하고, 적어도 원격 측이 그 경로에 속한다고 받아들이는 주소를 가져야 한다. 정책 라우팅 플랫폼에서는 수신 인터페이스나 변환된 출발지에 묶인 규칙과, 각 외부 인터페이스에 연결된 변환 문장이 필요하다. 클라이언트가 연결하는 동안 두 인터페이스에서 동시에 캡처하면, ISP B로 들어오는 SYN과 ISP A로 나가는 SYN-ACK이 한 번의 실행으로 문제를 정리한다.

클라이언트가 두 번째 항목을 알 방법을 준다

페일오버는 클라이언트 측 결정이며 대안을 배우는 방식은 클라이언트 계열마다 다르다. ASA에서는 그룹 정책의 webvpn 속성으로 백업 서버 목록이 전달되고, 다른 클라이언트는 프로필 안의 목록이나 사용자가 고르는 수동 두 번째 프로필을 기대한다. Cisco의 연결 정책 안내서는 클라이언트에 구성된 백업 정보와 게이트웨이가 제공하는 정보를 모두 설명하며, 그 프로토콜별 세부 사항을 모든 클라이언트나 터널 모드로 일반화해서는 안 된다. 잘못된 메커니즘 위에 두 번째 항목을 세우기 전에 배포된 클라이언트가 어느 쪽을 구현하는지 확인한다.

어떤 메커니즘이든 클라이언트는 기본 경로를 잃기 전에 대체 이름을 확인할 수 있어야 한다. 사람들이 놓치는 것이 바로 이 의존성이다: 대체 이름이 방금 실패한 터널로만 닿을 수 있는 리졸버에서 확인된다면 폴백은 시작조차 할 수 없다. 두 번째 이름은 로컬이나 인터넷으로 응답하는 리졸버에 게시한다. 전환 후에는 새 인증과 새 애플리케이션 세션을 예상해야 하며, 클라이언트 페일오버는 상태 기반 페일오버가 아니므로 오래 유지되는 세션은 살아남지 못한다.

두 공급자에 걸친 하나의 주소는 다른 제품이다

하나의 공용 주소를 두 회선으로 도달 가능하게 유지하는 것은 라우팅 서비스이며 VPN의 체크박스가 아니다. 두 공급자가 운반하기로 동의한 주소 공간이 필요하고, 상대 네트워크가 받아들이는 방식으로 광고해야 하며, 공급자 독립 공간과 BGP를 쓰는 멀티호밍이 그것을 제공한다. ISP A의 주소를 ISP B 인터페이스에 할당해도 거기에 이르지 못한다: 패킷은 그 프리픽스를 한 번도 광고하지 않은 네트워크에 도착해 상류에서 버려진다.

두 항목을 게시하는 데 그중 어느 것도 필요 없다. 클라이언트가 두 이름을 유지하고 그 사이를 오갈 수 있다면 독립된 두 항목으로 충분하며, AS 번호와 피어링 합의, 어디서나 받아들여야 하는 프리픽스를 피할 수 있다. 이동 가능한 주소 옵션은 클라이언트를 재구성해 대체할 수 없는 안정적인 진입점이 정말 필요할 때, 또는 TTL 지연이 있는 DNS 기반 페일오버가 설계 대상 장애에 비해 너무 느릴 때만 고려한다.

다음에 확인할 것

실패한 항목에서 바깥으로 이 순서로 진행한다: 두 번째 주소가 밖에서 응답하는가, 클라이언트가 기대하는 ID를 제시하는가, 요청이 온 경로로 응답이 나가는가, 필요하기 전에 클라이언트가 이름을 알 수 있는가. 답이 아니오인 지점에서는 그 계층을 고치고 테스트 호스트가 아니라 배포된 프로필로 다시 시험한다: 실험실의 핸드셰이크는 실제 클라이언트의 완료된 연결보다 증거로서 약하다.

WAN마다 주소, 포트, 종료 인터페이스, 인증서 이름, 반환 경로, 변환 규칙을 담은 짧은 기록을 유지하고 회선이나 NAT 장비, 클라이언트 버전이 바뀔 때마다 다시 확인한다. 유휴 백업 경로는 조용히 썩으며, 아무도 쓰지 않는 항목에 대해 모두가 그것에 의존하는 날까지 아무것도 경고하지 않는다.