MPLS VPN냐 IPsec 오버레이냐: 정해야 할 세 가지 계약

세 가지 약속이 하나의 광역 견적 안에 들어 있고, 하나를 사도 나머지를 사는 것은 아니다. 누군가는 당신의 패킷을 전달하고, 누군가는 당신의 라우팅을 다른 모든 고객과 분리하며, 누군가는 전송 중에 페이로드를 읽을 수 있는지 결정한다. 그 약속들은 서로 다른 당사자에게 속해도 하나의 실행 가능한 설계를 설명할 수 있다. 그것들을 분리하는 것이 결정이며, 기술 이름을 고르는 것이 아니다.

하나의 광역 견적 안의 세 가지 약속

첫 번째 약속은 전송으로, 어떤 사이트가 어떤 액세스 회선으로 연결되고 누가 그들 사이에서 패킷을 전달하는가이다. 두 번째는 라우팅으로, 어떤 프리픽스가 서로 도달할 수 있고 누가 변경을 승인하며 당신의 트래픽이 다른 테넌트와 어떻게 분리되는가이다. 세 번째는 보호로, 무엇이 암호화되고 어느 종단점 사이이며 누가 키를 가지는가이다. 각각을 서면으로 요구하라, 답은 모두 다른 문서에 살고 있기 때문이다.

공급자 견적은 보통 첫 번째에 가격을 매기고, 두 번째를 당연하게 여기며, 세 번째를 당신에게 남긴다. 그것은 부정직이 아니라 셋은 서로 다른 팀이 판다. 설계 검토에서 보안 팀은 암호화를 전제했고 네트워크 팀은 통신사가 처리한다고 전제했다는 사실이 드러날 때 문제가 된다. 문장을 셋으로 나누는 데 한 시간이 들고 그 회의를 막을 수 있다.

레이블은 전달을 설명한다, 접속 지점의 서비스가 아니라

다중 프로토콜 레이블 스위칭은 패킷이 공급자 네트워크 안에서 어떻게 이동하는지 말한다. 고객이 무엇에 접속하는지, 고객이 공급자 에지와 무엇을 교환하는지는 말하지 않는다. 공급자는 MPLS 위에 라우팅된 IP VPN을 만들 수도, 완전히 다른 연결 모델의 2계층 서비스를 제공할 수도 있으며, 둘 다 „MPLS 연결“로 당신에게 올 수 있다.

IETF의 공급자 제공 VPN 용어는 바로 이 일을 위한 어휘로 고객 에지, 공급자 에지, 그리고 그 사이에 만들어진 서비스 모델을 정의한다. 견적이 계층을 흐릴 때 이것을 쓰고, 인도가 물리적으로 무엇인지 물어라.

라우팅된 서비스는 공급자 에지와의 라우팅 관계를 주므로, 프리픽스를 추가하는 일은 두 조직의 변경 요청이 된다. 2계층 인도는 당신 자신의 라우팅을 나르고 운영 부담을 당신 쪽으로 옮긴다. 어느 쪽도 추상적으로 더 낫지 않으며, 답은 당신의 토폴로지가 얼마나 자주 바뀌는지, 새벽 세 시에 누가 응답하기를 원하는지에 달려 있다.

암호화는 우연히 위임할 수 없는 약속이다

전용 전송은 페이로드를 읽을 수 없게 만들지 않는다. 공급자의 분리는 테넌트를 운영상 분리할 뿐, 경로의 바이트를 누가 검사할 수 있는지에 대한 진술이 아니다. 통신사가 트래픽을 읽을 수 없어야 한다는 요구라면, 그 요구에는 당신이 통제하는 메커니즘이 필요하고 IPsec이 보통의 것이다.

IPsec은 전용 전송 위에서도 인터넷 액세스 위에서만큼 쉽게 동작하므로, 관리되는 도달성과 당신 자신의 신뢰 경계가 동시에 필요할 때 „MPLS냐 IPsec이냐“는 거짓 선택이다. 터널이 어디서 끝나는지 정하라, 라우터에서 끝나는 터널은 그 라우터 뒤의 구간을 평문으로 남기 때문이다. 다음으로 각 피어를 누가 관리하는지 정하라, 제삼자가 가진 키는 당신이 소유한 경계가 아니기 때문이다.

모든 약속에 이름과 측정 가능한 경계를 주라

약속마다 소유자와 측정 가능한 경계를 한 줄로 쓰라. 액세스 회선의 가용성은 공급자에게, 백본 지연은 공급자에게, 터널의 생존은 종단점을 운영하는 이에게 속한다. 아무도 측정하지 않는 단일 종단 간 숫자는 아무도 당신에게 빚지지 않은 숫자다.

서비스 수준 협약은 계약과 그 범위에서 나오며, 기술 이름의 글자에서 나오지 않는다. IPsec은 최선 노력 인터넷 전송을 요구하지 않고, MPLS도 그 자체로 지연 보장을 나르지 않으며, 둘 다 아래 네트워크와 당신이 고른 종단점에 달려 있다.

그린 경로를 시험하라, 그 실패까지 포함해서

여유 있는 인터페이스의 전용 전송도 오버레이가 헤더를 더하면, 세션이 성립한 뒤 큰 응답에서 멈추는 형태로 실패할 수 있다. 추론하는 대신 사용 가능한 크기를 시험하고, 종단 간 통과하는 가장 큰 패킷을 적어 두라. 대역폭을 논하기 전에 그렇게 하라, 큰 패킷을 버리는 경로는 애플리케이션 문제처럼 보이기 때문이다. 그 숫자는 각 액세스 회선의 MTU 옆 설계 문서에 속한다.

ping -M do -s 1400 -c 3 <vpn-gateway>
traceroute -n <vpn-gateway>

그 명령들은 한 사이트의 Linux 호스트에서 오지만, 다른 플랫폼은 같은 시험을 다르게 쓴다. 어떤 사이트가 더 작은 값을 필요로 하면, 그것은 기록해야 할 설계 제약이지 보고할 장애가 아니다. 같은 규율은 처리량에도 적용된다, 암호화는 처리 비용을 요구하고 종단점은 용량 계산의 일부가 되기 때문이다.

서명 전에 두 장의 도면을 그려라, 모든 소유자가 표시된 정상 경로와 같은 표시를 가진 장애 경로다. 두 번째는 종이에서는 중복처럼 보이지만 실제로는 한 대의 장비에 의존하는 설계를 드러낸다. 장애가 올 때 그 도면이 혼란스러운 아침을 짧은 분류로 바꾼다.