두 개의 활성 IPsec 터널에는 여전히 반환 경로 계획이 필요하다

한 사이트의 워크스테이션에서 터미널을 열고 다른 사이트의 서버에 연결한다. 그 하나의 TCP 대화는 이제 두 개가 아니라 네 개의 게이트웨이를 지나야 하며, 흥미로운 부분은 좋은 날에 동작하는지 여부가 아니다. 흥미로운 부분은 정방향이 어느 게이트웨이 쌍을 골랐는지, 응답이 어느 쌍을 고르는지, 그리고 그동안 누가 플로우의 상태를 보유하는지다. 라우팅 테이블의 어떤 것도 그것을 대신 결정하지 않는다.

경로를 그리기 전에 게이트웨이 네 개를 그려라

사이트마다 독립적인 VPN 방화벽 두 개, ISP마다 한 쌍을 두는 이중 활성 설계는 쓸 수 있는 경로 두 개와 그것을 깨는 세 가지 방법을 준다. 무엇이든 구성하기 전에 주소를 적어라: 각 게이트웨이 앞과 뒤에서 보이는 클라이언트, 마찬가지로 서버, 정방향 다음 홉과 역방향 다음 홉이다.

그 표가 설계다. 그 이후의 모든 것은 장비가 그 표에 동의하는지의 문제다.

정방향 경로는 어떻게 선택되는가

동일 비용 다중 경로 라우팅 계층은 헤더 필드를 해싱해 플로우를 다음 홉으로 분배하며, 이를 RFC 2992가 자세히 설명한다. 그 선택은 완전히 무상태일 수 있다: 연결 추적 항목이 필요 없고, 변하지 않는 필드에 대한 안정적인 해시만 있으면 된다. 경로 집합과 해시 입력을 일정하게 유지하면 플로우의 모든 패킷이 같은 다음 홉을 고른다.

플로우별 선택은 지연이 다른 링크에서 패킷별 분산이 일으킬 재정렬을 피한다. 라우팅 비용이 같다고 측정 지연이 같다는 보장은 하지 않는데, 실제로 그렇지 않기 때문이다. 그리고 경로 구성이 바뀌면 플로우가 다시 매핑되므로, 장애 중 연결 유지는 경로 선택과 별개의 요구 사항이다.

반환 경로가 실제로 필요한 것

여기서 이야기는 대칭이기를 멈춘다. 안정적인 정방향 해시는 원격 사이트가 응답을 어떻게 다룰지에 대해 아무것도 알려주지 않는다. 독립 방화벽이 유용한 상태를 유지하려면 연결의 양방향을 봐야 한다면, 그것을 우회하는 반환 경로는 무엇과도 맞지 않는 트래픽을 남긴다. 비슷한 규칙 집합을 가진 두 상자는 공유 상태가 아니다.

구현된 양방향 동작을 확인하거나, 필요한 경계를 일관되게 유지하는 명시적 정책을 작성하라. 여기서의 추측은 장애가 나는 동안, 그것을 즐기지 않는 사람들에 의해 드러난다.

번역이 당신 대신 결정하는 곳

NAT는 다른 지렛대이며, 필수가 아니라 선택 사항이다. 경로별로 변환된 아이덴티티는 응답을 상태를 보유한 게이트웨이로 되돌릴 수 있고, 이는 정당한 설계다. 다만 매핑, 반환 경로, 그 상태의 소유자를 더하므로, 소리 내어 말할 수 있는 요구 사항에만 부담을 받아들여라.

요구 사항이 단지 두 경로가 트래픽을 나르고 어느 하나가 ISP 손실을 견디는 것이라면, 일관된 반환 라우팅을 갖춘 단순한 플로우별 다중 경로가 보통 더 작은 설계다.

수용을 순서대로 걸어 보라

이 순서로 시험하고 각 단계에서 주소를 기록하라: 경로 A의 새 연결과 그 응답 경로, 경로 B에서도 같은 것, 그다음 ISP 하나의 손실, 그다음 복구다. 각 결과마다 어떤 기존 플로우가 이동했는지, 어느 것이 다시 연결해야 했는지, 새 플로우가 이후 어디로 갔는지 적어라. 먼저 기대값을 적고, 그다음 캡처와 비교하라. 확립된 터널 두 개는 그중 아무것도 증명하지 않는다.

설계는 작성한 표가 캡처가 보여주는 것과 일치할 때 끝나며, 두 터널이 모두 올라왔을 때가 아니다.