VPN을 위한 전용 회선? 요구사항부터 번역하라

제안서에는 사무실 VPN용 특정 전용 회선이 적혀 있고, 숫자는 아무런 설명도 없이 등장한다. 서명하기 전에 그 문장을 실제로 숨기고 있는 네 가지 요구사항으로 쪼개라: 물리적 접속점, IP 전달 방식, 양방향 용량, 그리고 회선 뒤의 지원 약정이다. 그 순서대로 관문으로 삼아 점검하라. 접속 단계에서 실패한 회선은 더 큰 대역폭 숫자로도 구할 수 없기 때문이다. 그런 다음 실제로 전달된 것이 적어 둔 내용과 맞는지 확인하라.

제품 이름이 아니라 요구사항을 번역하라

IPsec은 IP 계층에서 트래픽을 보호하고, 전송은 구매한 회선에 맡긴다. IPsec 아키텍처 문서는 트래픽이 두 피어 사이에서 어떻게 보호되는지를 설명할 뿐, 접속 유형이나 보장 속도, 복구 기한에 대해서는 아무 말도 하지 않는다. 그것들은 서비스 계약의 속성이다.

이 구분이 바로 회선 요구사항이 정당하면서도 VPN 요구사항은 아닐 수 있는 이유 전체다. 직렬 인터페이스만 있는 게이트웨이는 정말로 직렬 접속이 필요하며, 그것은 프로토콜이 아니라 하드웨어 제약이다. 장비를 교체하면 제약은 사라진다. 각 요구사항을 “게이트웨이에는 Y 때문에 X가 필요하다” 형식으로 적고, 문장을 완성할 수 없는 항목은 거부하라.

속도보다 접속을 먼저 명명하라

접속은 분계점에서의 물리적·링크 계층 연결이다: 구리 이더넷, 특정 트랜시버를 쓰는 광섬유, 직렬 인터페이스, 또는 현재 장비에 있기 때문에만 존재하는 더 오래된 무언가다. 여기서 틀리면 대역폭에서는 결코 나오지 않는 방식으로 비싸다. 보통 양쪽 끝에 새 하드웨어를 사야 하기 때문이다. 빠진 광 모듈은 용량 문제가 아니며 어떤 업그레이드로도 고쳐지지 않는다.

커넥터, 속도 협상, 미디어 컨버터나 라우터를 누가 공급하는지 확인하라. 그다음 책임이 어디서 끝나는지 확인하라. 링크가 03:00에 끊겼을 때 누가 무엇을 만질 수 있는지는 분계점이 결정하기 때문이다. 그 경계를 회선 식별자 옆의 기록에 적어라. 지원 전화를 한 시간짜리 전가가 아니라 오 분짜리 대화로 바꾸는 한 줄이다.

ip -br link show
ethtool eth0 | head -20
sudo lshw -class network -short

주소가 아니라 IP 전달을 확인하라

서비스가 실제로 어떤 주소나 프리픽스를 전달하는지, 그리고 그것이 고정인지 물어라. 동적 주소를 내주는 회선은 사이트 간 게이트웨이에 잘 맞지 않는다. 피어 설정이 예정에 없던 변경을 견뎌야 하기 때문이다. 프리픽스 길이도 확인하라. 주소 하나와 라우팅된 /29는 서로 다른 상품이다.

그다음 주소가 당신에게 도달하기 전에 무언가가 주소를 변환하는지 물어라. 서비스 앞의 제공자 측 NAT나 통신사급 NAT는 인바운드 세션을 깨뜨리므로, 원격 사이트에서 IPsec을 받아들이려는 게이트웨이는 도달할 수 없게 된다. 속도가 이를 보상하지 못한다: 당신이 통제하지 않는 변환기 뒤의 빠른 링크는 아무도 포워딩하지 않는 포트로 인바운드 연결을 받아들일 수 없다.

라우터와 DNS의 소유자가 누구인지 기록하라. 제공자가 라우터를 공급하면 그 펌웨어, NAT 동작, 기본 경로에 대한 생각까지 물려받게 되고, 이후 모든 변경은 티켓을 거친다. 네트워크 밖의 누군가에게 도달 가능하다고 기대하는 포트로 인바운드 연결을 시도하게 하라. 변환 이야기를 증명하는 유일한 시험이기 때문이다.

ip -br addr
ip route get 198.51.100.10
traceroute -n 198.51.100.10

용량은 워크로드에서, 양방향으로 산정하라

용량은 사용자당 숫자가 아니라 작업 기준으로 서술해야 한다. 대량 파일 접근, 대화형 관리, 야간 백업은 각각 다른 트래픽 패턴을 만들고, 그중 하나만 지속적인 업스트림 처리량을 신경 쓴다. 좌석당 대역폭 숫자는 판매 편의일 뿐 모델이 아니다.

양방향을 모두 추정하고, 캡슐화 오버헤드를 더하고, 트래픽이 버스트형인지 지속형인지 적어라. 그다음 계약의 표제 속도가 아니라 보장 속도를 확인하라. 몇 초 만에 끝나는 버스트 허용량은 야간 백업에 도움이 되지 않는다. 게이트웨이 자체의 한계도 같은 예산에 넣어라. 암호화 처리와 동시 세션 수는 회선보다 훨씬 먼저 한계가 될 수 있다. 더 빠른 회선은 포화된 게이트웨이를 고치지 못한다.

운영 약정을 확정하라

가용성, 복구 대응, 에스컬레이션 경로, 유지보수 통지는 측정 방법을 명시해 서면으로 남겨야 한다. 인터넷 표제 속도는 그런 속성을 하나도 확립하지 못하며, 장애를 정의하지 않고 신뢰성을 약속하는 마케팅 페이지도 마찬가지다. 시계가 언제 시작되는지 물어라. 제공자 자신의 확인 시점에서 잰 대응 시간은 당신의 모니터링 경보에서 잰 숫자와 같지 않기 때문이다. 그 두 정의는 아무도 거짓말하지 않고도 몇 시간씩 달라질 수 있다.

지원 경계도 기록하라. 제공자의 책임이 당신 라우터가 종단하는 접속점에서 끝난다면, 모든 장애의 첫 한 시간은 누구 잘못인지 정하는 데 쓰이고, 어떤 SLA 시계도 그것을 덮지 않는다.

회선을 서면 조건과 대조해 검증하라

서비스가 가동되면 설치 기사가 보여 준 속성이 아니라 실제로 계약한 속성을 측정하라. 실제 경로의 처리량, 지연, 손실이 증거이며, 이름 붙일 수 있는 시간과 위치에서 기록해야 한다. 인도 시점만이 아니라 혼잡한 시간대에도 측정을 반복하라. 한가한 날 10:00에 한 인수 시험은 15:00의 링크에 대해 거의 알려 주지 않는다.

iperf3 -c speed.example.net -t 30 -P 4
mtr -n --report -c 50 198.51.100.10
curl -sS -o /dev/null -w '%{time_connect} %{time_starttransfer}\n' https://speed.example.net/

결과를 계약서와 함께 보관하라. 기준선 없는 성능 논의는 인상에 대한 논쟁이다. 측정이 약정에 못 미치면 증거가 신선하고 서비스가 아직 계약이 정한 인수 기간 안에 있을 때 제기하라. 요청에 이름 붙인 호스트를 쓰면 TLS 핸드셰이크도 유효하게 유지되므로, 인증서 경고를 회선 고장으로 오해하지 않는다.

마지막으로 네 관문을 실제 전달된 것과 다시 대조하라. 접속, IP 전달, 용량, 지원 조건 각각 기록에 한 줄이 있고, 각 줄 옆에 이름이 있다.