사이트 간 VPN의 주소 공간 크기를 정하는 방법

VPN 서브넷이 얼마나 커야 하는지 물으면 정직한 답은 질문 안에 서로 다른 네 개의 서브넷이 숨어 있을 수 있다는 것이다. 사이트 VPN은 전송 엔드포인트, 번호가 붙은 터널 링크, 보호된 LAN의 프리픽스, 그리고 관리형 게이트웨이에서는 공급자가 예약하는 인프라 서브넷을 포함할 수 있다. 특정 설계에서는 그중 하나나 둘만 존재한다. 사무실 장비 수로 산정하는 것이 아무도 만족하지 못하는 /24로 계획이 끝나는 이유다.

무엇이든 할당하기 전에 네 가지 역할에 이름을 붙인다

전송 엔드포인트는 두 게이트웨이가 인터넷이나 전용 회선을 넘어 서로에게 도달할 때 쓰는 주소이며, 그 수는 LAN이 아니라 게이트웨이와 이중화 모델에서 나온다. 내부 터널 링크는 설계가 지점 간 인터페이스에 번호를 부여할 때만 존재하며, 정책 기반 IPsec 구성은 보통 그렇게 하지 않는다. 보호된 프리픽스는 라우팅 가능해야 하는 실제 사무실망이나 VPC망이고, 공급자가 예약한 서브넷은 관리형 서비스에 속한다.

무엇이든 더하기 전에 이미 있는 것을 조사한다. 여기서 값비싼 실수는 다른 곳에서 이미 라우팅되는 프리픽스를 재사용하는 것이다. 파일럿 프로젝트에서 남은 오래된 터널 하나로도 계획이 망가진다. 조사 결과는 날짜와 함께 적어 둔다. 폐기한 링크에 대한 기억이 링크 자체보다 오래 살기 때문이다.

ip -br addr show
ip route show | head -40

이 두 명령은 연결된 네트워크와 그 너머의 모든 것에 도달하는 경로에 대한 로컬 뷰를 준다. 조사는 모든 사이트에서 반복한다. 한 사이트의 출력만으로 만든 계획은 다음 사이트의 것과 충돌한다. 블록 하나를 할당하기 전에 출력을 모아 둔다.

장비가 아니라 링크와 토폴로지를 센다

지점 간 인접이 여덟 개인 설계는 블록을 여덟 개 소비한다. 하나가 아니다. /30에서는 각 블록이 두 호스트를 연결하는 데 주소 네 개를 쓰므로, 계획은 사용 가능한 엔드포인트 열여섯 개에 주소 서른두 개를 안게 되고, 예산이 견뎌야 하는 숫자가 그것이다. /31 링크를 지원하는 플랫폼은 절반만 쓰지만, 양쪽 끝과 서비스가 그 모델에 동의할 때만 그렇다. 예산은 내림이 아니라 올림한다. 나중에 블록을 줄이는 것은 가동 중인 링크의 번호를 다시 매기는 일이기 때문이다.

공급자 제약이 일반 관행보다 우선한다. 문서화된 내부 터널 범위는 라우터에서 /31이 동작하는 곳에서도 /30을 요구할 수 있고, 관리형 게이트웨이는 자기 서브넷에 특정 마스크를 요구할 수 있다. 다른 플랫폼에서 빌려온 경험칙을 적용하기 전에 서비스 요구 사항을 읽는다.

다지점 오버레이는 산술을 다시 바꾼다. 게이트웨이마다 주소 하나이고, 그들 사이의 도달성은 오버레이가 맡는다. 사이트 수에 블록 크기를 곱하기 전에 구현이 실제로 어느 토폴로지를 쓰는지 정한다.

성장은 계획에서 자기 줄을 가질 만하다. 일관된 인프라 범위를 예약하는 것은 합리적이며, 그 안에 어떤 더 작은 할당이 들어 있는지 적어 두는 것도 그렇다. 다음 엔지니어가 그 예약을 하나의 브로드캐스트 도메인으로 읽지 않도록.

게이트웨이 서브넷을 LAN 풀 밖에 둔다

관리형 게이트웨이의 인프라는 클라이언트 풀이 아니다. 예약된 게이트웨이 서브넷의 주소는 서비스 자체의 구성 요소를 두며, 원격 근무자는 결코 그곳에서 가져가지 않는다. 그 서브넷을 사용자 수로 산정하는 것은 범주 오류로, 큰 범위를 낭비하거나 게이트웨이를 굶주리게 한다.

같은 점이 클라우드 VPN 연결의 터널 범위에도 적용된다. 공급자는 터널마다 작은 내부 범위를 자기 용도로 할당한다. 그 범위는 지사 서버가 있는 곳이 아니며 당신이 나눠 줄 것도 아니다.

aws ec2 describe-vpn-connections --query "VpnConnections[].{Id:VpnConnectionId,Tunnels:Tunnels[].OutsideIpAddress}" --output table

외부 주소를 나열하면 공급자가 무엇을 할당했고 어느 예비 터널이 지금 살아 있는지 확인된다. 연결이 존재하기 전에 쓰인 설계 문서를 읽는 것보다 빠르다.

모든 프리픽스에 역할, 소유자, 성장을 기록한다

운영과의 접촉을 견디는 계획은 프리픽스마다 어떤 역할을 하는지, 먼 쪽을 누가 할당하는지, 여유가 얼마나 남았는지를 밝힌다. 소유자 필드가 없으면 두 팀이 같은 분기에 같은 /24를 할당하고, 충돌은 터널이 올라올 때에야 드러난다.

이 범위들은 다른 터널로 들어오는 가정과 지사 프리픽스에서 멀리 둔다. 주소 공간이 겹치는 것이 사이트 간 연결이 협상에 성공하고도 아무 트래픽도 통과시키지 못하는 흔한 이유이기 때문이다.

내부 링크 주소를 할당해도 그 뒤의 LAN이 광고되지는 않는다. 경로나 트래픽 선택자, 반환 경로, 접근 규칙은 별도의 작업 항목이며, 계획은 번호가 붙은 인터페이스가 라우팅까지 대신 해 준다고 암시하는 대신 그렇게 말해야 한다.