한대의 PC가 복수 네트워크에 걸쳐 있고, 각 네트워크에 별도의 게이트웨이가 지정되어 있을때, 복수의 게이트웨이로 인한 호스트의 통신 문제가 발생한다. 윈도우 시스템의 ROUTE 명령으로 라우팅 테이블에 정적 수동 라우팅 규칙을 추가하여 문제를 해결하는 방법에 대해 알아본다. 또한 트리구조 네트워크와 스타구조 네트워크에 대해 알아보고, 분리된 네트워크를 운용할때 생각해 볼 점을 나눠본다.
둘 이상의 네트워크에 걸친 PC
PC 한대에 복수의 랜카드를 설치하고, 복수의 네트워크에 접속이 가능하도록 연결하는 경우가 있다. 대부분의 경우는 서로 분리된 내부의 네트워크에 동시에 접속하기 위해서인데, 복수의 네트워크들 중에서 하나의 네트워크에만 게이트웨이가 존재한다면 문제가 되지 않으나, 게이트웨이가 둘 이상 존재하는 경우, PC는 혼란에 빠지게 된다.
이는, 랜카드에 설정된 게이트웨이 주소가 기본적으로, 기본 게이트웨이로 잡히기 때문이다. 기본 게이트웨이란, 자신이 속해있지 않은 네트워크를 넘어 다른 네트워크와 통신을 해야 할 경우에 기본적으로 거치도록 설정된 라우터의 주소이다. 만약 기본 게이트웨이가 하나일 경우 문제될 일이 없다. 하나 있는 그 게이트웨이로만 통신하면 되기 때문이다.
그런데 기본게이트웨이가 둘이 되어 버리면, 어느 게이트웨이를 사용해야 할지 혼란에 빠진다. 어쩔 때는 통신이 붙었다가, 어쩔 때는 통신이 안됐다가 하면서 아주 답답한 상황이 벌어진다.
그림의 네트워크를 예로 들어보겠다. 가운데 있는 PC에 랜카드(NIC)가 둘, IP도 둘, 게이트웨이도 두개가 설정되어 있다. 이 상황에서 192.168.1.0/24네트워크와 172.30.0.0/16 네트워크는 통신하는데 아무런 문제가 발생하지 않는다. 게이트웨이를 거칠 필요가 없기 때문이다. 하지만, 172.27.11.0/24네트워크와 통신하거나, WAN영역으로 빠져 나가려 하면, 위에서 설명한 이유로 문제가 생긴다. 어느 게이트웨이로 나가야 할지 모르기 때문이다.
해결방법
RIP의 적용
본래 이 상황에서 정석적인 해결 방법은, 윈도우가 RIP(라우팅 정보 프로토콜)를 직접 사용하도록 하는 것이다. 네트워크상에 존재하는 다른 라우터들과 직접 라우팅 정보를 교환해 적합한 경로를 선택할 수 있도록한다. 하지만 일반적인 가정이나 소호환경에서 사용되는 공유기는 RIP를 지원하지 않는 경우가 많고, 구성하기 위한 RIP에 대한 지식이 필요하다. 그리고, 그런 지식이 있는 사람이라면 아마 이 글을 검색할 일도 없었을 것이다.
게이트웨이 삭제
또 하나의 방법은 주로 사용할 게이트웨이만을 남겨두고, 나머지 네트워크의 게이트웨이를 모두 공란으로 비워두는 것이다. 이렇게 하면 PC에 설정된 게이트웨이 주소는 하나 뿐이니 윈도우가 게이트웨이 때문에 혼란에 빠질 일이 없다. 하지만 DHCP를 사용해 IP를 받아오는 상황이라던가, 양쪽 게이트웨이를 모두 사용해야만 하는 상황에서는 적용할 수 없는 방법이다.
ROUTE명령으로 정적 라우팅 설정
위의 두가지 방법에 비해 난이도도 낮고, 큰 제약 없이 해결할 수 있는 방법이 있다. 이 문제의 원인은, 윈도우가 172.27.11.0/24와 통신하려면 172.30.0.1 게이트웨이를 거쳐야 하는 것을 모르기 때문이다. 모르면? 알려주면 된다!
라우팅은 라우터에서만 이루어지는 동작이 아니다. 모든 네트워크 장비들은 기본적인 라우팅 기능을 가지고 있으며, 윈도우 PC역시 마찬가지이다. 내가 통신을 하기 위해 데이터를 어디로 보내야 하는지 결정하는 기능과 규칙을 기본적으로 가지고 있다는 말이다. 이 규칙을 표로 만들어 놓은 것이 바로 라우팅 테이블이라 불리는 목록이며, 윈도우는 통신을 할때, 이 라우팅 테이블을 보고 데이터를 어디로 전송할지 결정한다. 이 라우팅 테이블에,
172.27.11.0 네트워크로 가는 트래픽은 172.30.0.1 게이트웨이를 거치면 된단다
라고 적어만 두면, 윈도우는 172.27.11.0과 통신하기위해서 엄한 192.168.1.1을 두드리는 것이 아닌, 172.30.0.1로 트래픽을 보내게 되며, 정상적인 통신이 이루어지게 된다. 이렇게 윈도우의 라우팅 테이블에 있는 라우팅 정책을 추가하고 관리하데 사용하는 명령이 바로 ROUTE명령이다.
ROUTE 명령 사용방법
우선 ROUTE명령은 관리자 권한을 가진 콘솔창에서 실행 되어야 하는것을 기억하고 있어야 한다. 윈도우 콘솔창을 관리자 모드로 실행해 주어야 정상적으로 ROUTE명령을 사용할 수 있다. ROUTE의 기본 명령은 다음의 형식을 따른다.
route [옵션] [대상네트워크] MASK [네트워크마스크] [게이트웨이주소]
옵션
여러가지 옵션이 있으나, ROUTE명령에서 주로 사용되는 옵션은 ADD, DELETE, CHANGE, PRINT의 네가지 옵션이 있다.
- ADD
- 라우팅 테이블에 존재하지 않는 새로운 규칙을 추가하는 명령이다.
- DELETE
- 기존에 라우팅 테이블에 존재하는 규칙을 제거하는 명령이다. 이때는 [대상네트워크]주소 까지만 입력해 주면 되고, [네트워크마스크]나 [게이트웨이주소]는 생략이 가능한다.
- CHANGE
- 기존에 라우팅 테이블에 존재하는 규칙을 변경할때 사용하는 명령이다. 사실 별 사용할 일은 없을 것이다. 기존 것을 삭제하고 새로이 추가하는게 더 일반적이긴 하다. 게이트웨이를 변경하는 용도이다.
- 현재의 라우팅 테이블을 표시해 준다. 옵션만 입력해 주면 되고, 뒤의 항목은 입력할 필요가 없다.
라우팅 규칙 추가
위의 예에서, 172.27.11.0/24 네트워크로 가는 트래픽은 172.30.0.1 게이트웨이를 거치도록 라우팅 규칙을 추가해 줘야 한다고 했다. 이 경우 아래와 같이 입력해 주면 된다.
route ADD 172.27.11.0 MASK 255.255.255.0 172.30.0.1
라우팅 규칙 제거
만약, 라우팅 규칙을 제거해야 할 경우, 아래와 같이 입력해 주면 된다.
route DELETE 172.27.11.0
영구 저장
ROUTE 명령으로 추가되거나 변경된 라우팅 규칙은, 재부팅 하면 날아가 버린다. 윈도우를 재부팅하더라도 계속 라우팅 규칙을 유지하고 싶다면, 아래의 예와 같이 -p옵션을 추가해 주면 된다
route -p ADD 172.27.11.0 MASK 255.255.255.0 172.30.0.1
이렇게 ROUTE 명령을 통해 라우팅 경로를 설정하면, 복수의 게이트웨이가 있다 하더라도 일.단.은 통신에 문제가 발생하지 않게 조치할 수 있다.
뱀발-사용할 일이 없는게 좋다
현장과 상황에 따라 달라질 수 있겠으나, 사실 본 필자는 위의 상황이 발생하는 것 자체가 좋지 않은 상황이라 생각한다. 본 필자가 생각하는 정석적이고 이상적인 네트워크 토폴로지는 하나의 호스트가 하나의 랜카드와 하나의 IP 주소를 가지고 하나의 네트워크에 속해 있으며, 그룹내 통신은 엣지 스위치를 통해 이루어 지고 (스타 토폴로지), 네트워크 간의 통신은 상단에 위치한 라우터를 통해 이루어지는 (트리 토폴로지) 트리-스타구조의 네트워크이다.
트리-스타구조 네트워크
물론 트리-스타구조의 토폴로지가 만능이라는 얘기는 아니다. 기술적으로도 다른 토폴로지보다 우월하다는 것도 아니다. 다만 대부분의 환경에서 적용이 가능하고, 관리측면에서도 여러가지 장점이 있다는 것 뿐이다. 하지만 여러가지 환경이나 정책의 이유 (절대 기술적인 이유가 아니다.)로 이러한 구조를 적용하기 힘든 경우가 생기는데, 대표적으로
- 보안상의 이유로, 부서별 업무 네트워크를 분리 하는 경우
- 역시 보안상의 이유로, 외부와 단절된 폐쇄망을 운영하는 경우
- 라우터를 운용하기 위한 예산 또는 기술력이 없는 경우
다중 네트워크에 걸쳐있는 호스트의 등장
문제는, 이렇게 네트워크를 그룹별로 분리해 운영하거나 외부와 단절된 폐쇄망으로 운영하는 경우, 서로 분리된 네트워크 간의 데이터 전달이 필요한 일이 반드시 생기게 된다는 것이다. 명확한 목적과 정확한 보안정책에 따라 네트워크가 운영되고 있다면, 절차와 정책, 그리고 사용자들의 의식이 합쳐져 별 다른 문제가 생기지 않....기는 개뿔! 이런 네트워크에서도 위반이 생기는데, 별다른 이유 없이 폐쇄망이 좋다더라! 또는, 관리하기 귀찮아!라는 얄팍한 논리로 구성된 폐쇄망이라면 볼 것도 없다. '이 놈만 예외로 하자' 또는 '운영의 편의'라는 이유 하에, 두 네트워크 사이에 걸쳐져 양쪽을 동시에 접속할 수 있는 호스트가 반드시 생긴다.
바로, 이 글의 위에서 가정한 상황이다. 그나마 여기까지는 괜찮다 치겠다. 무슨 일이든 한 번이 어렵지, 두 번은 쉬운 법이다. 이 양다리 호스트는 점차 영역을 확장하게 되거나, 또다른 양다리 호스트들이 여기저기 생겨날 것이다. 점차 네트워크는 혼돈과 파멸의 구렁텅이를 향해 달려가게 된다.
결론
본 필자는 기술적인 측면이 아닌 운영과 보안의 측면에서, 이 방법을 사용하지 않는게 좋다 생각한다. 명확한 원칙을 세우고, 그 원칙을 따라 네트워크를 설계하고 운용한다면 사실 사용할 일이 없는게 정상이다. 하지만, 어쩔 수 없는 상황이란게 언제나 존재한다. 그럴 경우에 이 글을 기억해 주기 바란다. 그리고 혹 호스트에서 정적 라우팅을 설정했다면, 최대한 빠른 기간안에 다시 삭제할 수 있게 되기를 바란다.