네트워크 인프라 이해하기 · 제5부 · 사내망을 지사·클라우드·인터넷과 연결하기

사내망은 지사·클라우드·인터넷과 어떻게 연결될까

사무실 안의 통신이 잘된다고 지사나 클라우드의 업무 서비스까지 바로 쓸 수 있는 것은 아닙니다. 두 망을 잇는 회선뿐 아니라 겹치지 않는 주소, 오가는 경로와 접근 정책이 함께 맞아야 합니다. 본사 PC가 지사와 클라우드의 서버에 접속하는 사례로, 캠퍼스 밖의 연결에서 무엇을 서로 확인해야 하는지 살펴봅니다.

주소를 배정받는 것과 그 주소로 가는 경로를 알리는 것은 다르다↑

공인 주소를 배정받았다는 사실만으로 인터넷의 모든 라우터가 그 주소로 가는 길을 알게 되지는 않습니다. 주소를 사용할 권한과 그 주소 대역의 경로를 알리는 절차는 별개입니다. 사설 주소도 서로 연결할 망 사이에서는 겹치지 않게 계획해야 합니다.

사설 대역은 여러 조직이 각자 사용할 수 있습니다. 본사와 새로 연결한 지사가 모두 10.0.0.0/24를 사용한다면 문제가 생깁니다. 본사 PC는 지사에 있는 10.0.0.10을 같은 로컬 망의 장비로 판단할 수 있습니다. 본사 안에도 같은 주소의 장비가 있다면 목적지 주소 하나만으로 두 장비를 구별할 수 없습니다. 회선을 더 빠르게 바꾸거나 BGP를 켜는 것으로 주소의 모호함이 해결되지는 않습니다.

그래서 장비를 연결하기 전에 기업의 사설 주소 계획을 서로 대조해야 합니다. 이 사례에서는 본사 10.0.0.0/24, 지사 10.30.0.0/24, 클라우드 10.40.0.0/24를 구별했습니다. 실제 계획은 현재 사용량뿐 아니라 추가 지사와 서비스의 확장도 고려합니다. 이미 겹치는 망을 합쳐야 한다면 주소 변경이나 제한된 변환을 검토할 수 있지만, 변환이 이름 해석·접근 정책·운영 기록에 미칠 영향도 함께 살펴야 합니다.

공인 주소에서는 등록·위임 관계와 경로 광고의 책임을 확인합니다. 작은 사무실은 통신사가 제공한 공인 주소와 기본 경로를 사용할 수 있고, 통신사가 그 주소를 포함한 대역을 인터넷에 알릴 수 있습니다. 반면 여러 통신사를 사용하며 자신의 대역에 대한 정책을 직접 운영하는 조직은 별도의 협의와 경로 교환이 필요할 수 있습니다. 주소가 어느 등록기관에 기록되어 있는지와 어느 망이 인터넷에 광고하는지는 같은 질문이 아닙니다.

클라우드에 서버를 만들 때도 같은 구별이 필요합니다. 사설 주소가 생긴 것, 다른 망과 연결이 준비된 것, 경로와 접근 규칙이 적용된 것을 순서대로 확인합니다. 클라우드 상품마다 요구하는 연결 방식은 다르므로 공통 도면을 그대로 설정 명령으로 옮기지는 않습니다. 주소 관리의 위임 구조는 공인 IP 주소의 할당에서, 실제 경로 선택은 BGP 글에서 각각 이어 볼 수 있습니다.

근거: RFC 1918 — 사설 주소와 망 통합, IANA — 인터넷 번호 자원.

나가는 패킷과 돌아오는 패킷을 따로 따라가 본다↑

본사에서 지사로 가는 경로만 있어서는 응답을 받을 수 없습니다. 지사 서버가 본사 PC의 주소로 돌아오는 경로와 양쪽의 허용 정책도 필요합니다. 요청이 어디까지 도착했고 응답은 어디까지 돌아왔는지 나누어 확인하면 통신이 끊긴 방향과 구간을 찾기 쉽습니다.

본사 PC 10.0.0.25가 지사 서버 10.30.0.10으로 요청을 보냈다고 가정해 보겠습니다. PC는 게이트웨이의 MAC 주소로 프레임을 만들지만 IP 목적지는 지사 서버입니다. 라우터는 그 목적지에 맞는 지사 경로를 찾아 다음 홉으로 전달합니다. 일반적인 IP 라우팅에서는 홉마다 필요한 링크 헤더가 달라지고, NAT 같은 별도 처리가 없다면 최종 목적지 IP는 유지됩니다. 인터넷 너머 지사 서버의 MAC 주소를 본사 PC가 직접 찾는 것은 아닙니다.

VPN 터널을 이용한다면 원래 패킷은 터널을 건너기 위한 바깥쪽 패킷으로 운반될 수 있습니다. 본사와 지사 사이의 업무 주소, 터널 양 끝의 주소, 인터넷을 통과하는 경로를 구별해야 합니다. 지사 쪽 장비가 터널 처리를 끝낸 다음에도 서버까지의 전달과 정책 검사가 남습니다. 따라서 터널 양 끝 사이의 통신 성공과 그 안으로 운반할 업무 통신의 성공은 따로 시험합니다.

응답에서는 지사 서버가 10.0.0.25로 가는 경로를 사용합니다. 지사 라우터에 본사 대역 경로가 없으면 응답이 다른 출구로 나가거나 중간에서 버려질 수 있습니다. 반환 경로가 반드시 요청과 같은 물리 링크여야 하는 것은 아닙니다. 다만 통신 상태를 검사하는 방화벽이나 NAT를 거친다면 응답을 받은 장비가 필요한 상태와 매핑을 알고 있어야 합니다. 이중화 장비가 있다고 해도 그 조건은 별도로 확인해야 합니다.

사설망끼리의 이 연결에 NAT가 항상 필요한 것은 아닙니다. 양쪽 주소가 겹치지 않고 서로 도달할 수 있으며 정책이 허용한다면 원래 주소로 통신하도록 설계할 수 있습니다. 반대로 인터넷 접속이나 주소 중복 해결 때문에 변환을 적용했다면 변환 전후 값을 함께 기록합니다. 캡처 두 곳의 주소가 다르다는 이유만으로 다른 통신이라고 결론 내리지 않고, 매핑과 시각을 대조해야 같은 요청과 응답을 이어 볼 수 있습니다.

근거: RFC 1812 — 패킷 전달, RFC 4301 — IPsec 보안 구조, RFC 3022 — NAT의 양방향 변환.

BGP를 켜기 전에 누구와 어떤 경로를 나눌지 정한다↑

외부 망에 연결한다고 모든 현장에 BGP가 필요한 것은 아닙니다. 출구가 하나이고 전달할 대역이 단순하다면 기본 경로나 정적 경로로 운영할 수 있습니다. 경로를 직접 설정해도 관리할 수 있는지, 상대 망과 경로 변경을 자동으로 주고받아야 하는지부터 판단합니다. 어떤 경로를 받아들이고 내보낼지 직접 제어해야 한다면 그 정책을 지원하는 방식도 검토해야 합니다.

예를 들어 본사가 단일 통신사를 통해 인터넷을 사용한다면 기본 경로로 충분할 수 있습니다. 본사와 지사의 대역이 적고 거의 바뀌지 않는 연결에는 정적 경로를 검토할 수 있습니다. 반면 여러 통신사가 같은 목적지를 알려 주거나, 경로 변경과 장애에 따라 선택을 바꾸어야 한다면 동적 경로 교환이 유용할 수 있습니다. 다만 연결 상품이 BGP를 요구하는 경우도 있으므로 조직의 필요와 제공자의 기술 조건을 함께 확인합니다.

BGP를 사용한다면 세션이 맺어진 뒤에도 확인할 일이 남습니다. 상대에게서 받아들일 프리픽스, 우리 쪽에서 광고할 프리픽스, 선호할 출구와 비정상 경로를 막을 정책을 정합니다. 세션이 정상이라고 모든 경로가 사용 가능한 것은 아닙니다. 수신한 경로가 정책에서 제외되거나 다음 홉에 도달할 수 없으면 실제 전달에 쓰이지 않을 수 있습니다. 이 구별은 BGP의 경로 선택에서 구체적으로 다룹니다.

사내 OSPF와 외부 연결의 경로를 함께 사용해야 한다고 해서 양쪽의 모든 경로를 서로 넘기지는 않습니다. 먼저 기본 경로만 전달해도 되는지, 필요한 특정 대역만 전달할지 판단합니다. 재분배가 필요하다면 허용 범위와 출처를 관리하고, 다른 경로 체계로 넘긴 경로가 원래 체계로 다시 유입되지 않게 해야 합니다. 재분배와 경로 태그는 이처럼 서로 다른 경로 체계가 만나는 지점에서 읽으면 왜 필요한지 더 분명해집니다.

연결을 마쳤다면 본사·지사·클라우드에서 실제 업무 요청과 응답을 확인하고, 허용하지 않은 접근은 차단되는지도 시험합니다. 회선과 터널의 장애, 남는 경로의 용량, 변경을 되돌릴 조건까지 기록합니다. 캠퍼스 설계에서 정한 역할·용량·장애 경계가 사내 장비에서 끝나지 않고 외부 사업자와의 연결까지 이어지는 것입니다. 그 기록이 있어야 주소나 경로가 바뀌어도 업무에 미치는 영향을 판단할 수 있습니다.

근거: RFC 1812 — 외부 프로토콜 없는 망 간 연결과 정적 라우팅, RFC 4271 — BGP 경로 교환·선택.

용어사전↑