사이트 간 VPN에서 정적 경로와 라우팅 프로토콜 중 무엇을 쓸까

두 선택지 모두 사이트 사이로 패킷을 운반하므로, 결정은 어느 프로토콜이 더 새로운가의 문제가 아니고 터널의 크기도 그것을 정하지 않습니다. 세 가지 조건이 정합니다, 얼마나 많은 프리픽스가 얼마나 자주 바뀌는지, 경로 사이의 자동 페일오버가 필요한지, 그리고 팀이 새벽 세 시에 얼마만큼의 제어 평면 장치를 운영할 수 있는지입니다. 이에 정직하게 답하면 선택은 대개 스스로 이루어집니다. 이 글의 나머지는 각 답이 무엇을 치르게 하는지입니다.

세 가지 조건이 결정한다

첫 번째 조건은 변동성입니다. 소유가 분명한 안정적인 서브넷 몇 개는 몇 년 동안 손으로 유지할 수 있고, 각 경로는 누군가 읽고 확인할 수 있는 한 줄로 남습니다. 프로젝트가 생기고 사라지면서 움직이는 수십 개의 프리픽스는 다른 문제입니다, 모든 이동이 옛 경로를 아직 기억하는 모든 장치에 도달해야 하기 때문입니다.

두 번째는 장애 시의 동작입니다. 백업 경로가 사람이 알아차리지 않는 사이 활성화되어야 한다면, 무언가가 장애를 감지하고 경로를 철회해야 합니다. 정적 라우팅은 추적이나 조건부 설치를 통해서만 그것을 할 수 있고, 미리 생각해 둔 장애에만 할 수 있습니다.

세 번째는 두 번째 제어 평면에 대한 의욕입니다. 라우팅 프로토콜은 세션, 인증, 필터, 선택 정책을 더하며, 그 각각은 모니터링과 변경 절차를 필요로 합니다. 이것은 일회성 설정 작업이 아니라 영구적인 운영 비용입니다.

세 번째 문단 아래의 표가 짧은 판본이고, 그 뒤의 세 절이 각 행이 왜 그 자리에 있는지 설명합니다. 고르기 전에 각 행을 자신의 사이트 수와 견주어 읽으십시오, 운영 비용을 무시한 결정은 절반의 결정일 뿐이기 때문입니다.

정적 라우팅이 실제로 치르게 하는 비용

정적 경로는 터널 양쪽에서 모두 올바라야 합니다. 서브넷을 추가한다는 것은 원격 게이트웨이, 로컬 게이트웨이, 그리고 보통 되돌아오는 경로를 편집하는 일이며, 그중 하나를 잊으면 애플리케이션 버그처럼 보이는 단방향 장애가 생깁니다. 애플리케이션 팀은 시간 초과를 보고, 네트워크 팀은 존재하고 겉보기에 건강한 경로를 봅니다. 어느 팀도 틀리지 않았고, 그래서 이 장애의 위치를 찾는 데 그렇게 오래 걸립니다.

정적 항목은 그 아래 경로가 사라진 뒤에도 설치된 채로 남습니다. 플랫폼이 추적을 제공하지 않으면 경로는 더 이상 전달하지 않는 다음 홉을 계속 가리키고, 트래픽은 전환되는 대신 사라집니다. 그 침묵이 단순한 선택지를 고를 때 받아들이는 비용입니다.

각 경로 옆에 추적 방법을 적고, 그것이 어떤 장애를 덮는지 기록하고, 목록을 터널 구성과 함께 보관하십시오. 그렇지 않으면 다음 중단은 네트워크가 아니라 사용자가 발견하게 되고, 그것은 언제나 더 비싼 발견입니다.

동적 라우팅이 실제로 치르게 하는 비용

프로토콜은 새 프리픽스를 알리고, 도달할 수 없는 것을 철회하며, 경로 사이의 선호를 표현합니다. 여러 사이트나 중복 터널이 그렇지 않으면 변경마다 조정된 편집을 필요로 할 때 이것은 정말 유용합니다. 동시에 프로토콜이 최악의 순간에 여러분을 놀라게 할 수 있는 이유이기도 합니다. 그 동작 하나하나는 여러분이 직접 하지 않은 상태 변화입니다.

그것은 서로 어긋날 수 있는 두 상태를 만듭니다. 터널은 올라가 있는데 라우팅 세션은 내려가 있을 수 있고, 세션은 올라가 있는데 그 알림이 애플리케이션이 필요로 하는 서브넷을 빠뜨릴 수 있습니다. 둘 다 절반만 동작하는 네트워크처럼 보이고, 둘 다 터널 상태 페이지에서는 보이지 않습니다.

그래서 필터와 정책은 나중 생각이 아니라 설계의 일부가 됩니다. 모든 것을 알리는 프로토콜은 언젠가 잘못된 것을 알리게 되고, 잘못된 프리픽스는 그것을 고칠 수 있는 사람보다 빠르게 이동합니다. 첫 세션을 활성화하기 전에 필터를 작성해, 첫 알림이 이미 의도된 것이 되게 하십시오.

라우팅 세션이 무엇을 말할 수 있는지 통제하십시오

피어별로 허용되는 프리픽스 목록을 정하고 인그레스에서 강제하십시오, 아웃바운드 필터로는 피어가 여러분에게 기본 경로를 보내는 것을 막을 수 없기 때문입니다. 여기서 비싼 실수는 기본 경로와 집계입니다, 그것들은 정당해 보이는 하나의 학습된 항목으로 무관한 경로를 조용히 대체할 수 있기 때문입니다. 설계가 정말로 원하지 않는다면 명시적으로 거부하십시오.

첫 세션이 올라오기 전에 각 네트워크 옆에 소유 사이트를 적으십시오, 그 대응표가 필터 목록의 원천이지 문서의 장식이 아니기 때문입니다. 그것이 없으면 필터를 편집하는 사람은 어느 사이트가 프리픽스를 알려야 하는지 추측해야 합니다.

두 프로토콜 사이의 재분배는 루프가 시작되는 곳이고, 같은 프리픽스가 깔끔하게 비교되지 않는 속성을 지니고 두 번 도착하는 곳입니다. 특정 요구가 강제할 때까지 재분배를 설계에서 빼두고, 있어야 한다면 경계에서 경로를 표시하고 필터링하십시오.

경로 기반 터널 인터페이스는 동적 라우팅을 표현하기 쉽게 만듭니다, 터널이 셀렉터를 맞추는 정책이 아니라 경로를 가진 인터페이스가 되기 때문입니다. 그것이 피어 범위 문제를 없애지는 않습니다, IPsec 셀렉터는 여전히 라우팅하려는 트래픽을 허용해야 합니다.

행복한 경로가 아니라 장애 경로를 시험하십시오

무엇을 고르든 업링크 하나를 내리고 트래픽이 움직이는지, 또는 문서화한 대로 실패하는지 확인하십시오. 두 경로가 모두 건강한 상태에서만 시험한 설계는 전혀 시험하지 않은 설계입니다. 그 자리에서 감지 시간을 재십시오, 잰 숫자가 사용자가 겪을 숫자입니다.

다음으로 반환 경로를 독립적으로 확인하십시오, VPN 위의 비대칭 라우팅은 흔하고, 상태를 지닌 장치가 응답을 버릴 때까지 보이지 않습니다. 한 방향으로 동작하는 흐름은 경로의 절반만 증명합니다.

작업 순서는 프리픽스를 세고, 장애를 어떻게 감지할지 정하고, 누가 프로토콜을 운영할 수 있는지 확인하고, 무엇을 알릴지 통제한 다음, 하나의 장애를 처음부터 끝까지 시험하는 것입니다. 각 단계는 다음 단계가 필요로 하는 사실을 만들어 냅니다.