라우팅 프로토콜


1) 라우터의 원리

라우터는 LAN테이블, Network테이블, Routing테이블 등 3가지 테이블을 관리함으로써 다른 네트워크를 비롯하여 네트워크의 모든 장치의 주소를 인식하고, 이를 바탕으로 패킷의 전송경로를 결정한다.


LAN테이블은 라우터가 속해있는 랜 세그먼트내 장치의 주소를 관리하고 있으며, 필터링 작업에 사용된다. 네트워크 테이블은 네트워크상의 모든 라우터의 주소를 보관하며 패킷의 수신지 라우터를 식별하는데 사용된다. 라우팅 테이블 역시 개개의 라우터에 구축되어 있으며, 각 경로에 대한 정보를 유지하고 있어서 다른 세그먼트로 전송되는 패킷의 경로를 결정하는데 사용된다. 3개의 테이블은 패킷의 전송에 있어서 최선의 경로선택, 회선이나 라우터 장애시 우회경로의 선택, 패킷의 순환현상을 방지하기 위해 활용하는 것으로 라우터의 모든 동작을 위한 핵심 요소이다. 이 테이블은 기본적으로 네트워크 관리자에 의해서 만들어지지만 네트워크 내에 존재하는 개개의 라우터에서 주기적으로 전달되는 라우팅 정보를 근거로 수시로 갱신된다.

라우터가 속해있는 네트워크내의 장치로부터 패킷을 수신하면 랜테이블을 검사하여 수신지 주소가 송신지 주소와 다른 네트워크에 속해 있다는 것을 확인하고 네트워크 테이블을 검사하여 패킷을 전달할 네트워크 주소(즉 네트워크에 연결되어있는 라우터의 주소)를 찾아낸다. 마지막으로 이 주소를 라우팅 테이블에서 검색하여 수신지로 가는 가장 적합한 경로를 알아낸다.


일단 경로가 결정되면 라우터는 수신한 원래의 패킷에 송신지 주소 및 네트워크 관리를 위해 필요한 제어정보(control information)을 추가한 새로운 패킷을 생성하여 해당 회선으로 전송한다. 상대편 라우터에서는 패킷을 수신하면 수신한 패킷에서 제어정보를 뽑아서 라우팅 테이블의 내용을 갱신하는데 사용하고 패킷내의 수신지 네트워크 주소와 테이블에 있는 정보를 근거로 어느 네트워크로 전송할 것인가 결정하며, 이러한 경로배정 과정은 모든 라우터에서 차례로 수행된다.


위에서 설명한 일련의 경로설정 과정을 라우팅이라 부른다. 이런식으로 패킷이 전송되므로 네트워크간에 폐쇄로가 형성되어 있더라도 문제가 없다. 패킷이 최종 수신지 라우터에 도착하면 라우터는 패킷의 이상유무를 검사하고 제어정보를 제거한 후, 원래의 데이터패킷을 랜쪽으로 전달함으로써 수신지에 도착하게 된다.


 

2) 라우팅 프로토콜


(1) RIP(Routing Information Protocol)

RIP는 최초에 Xerox Network System(XNS) 프로토콜에 사용하기 위하여 설계된 프로토콜로, 1982년 버클리(Berkeley Standard Distribution) 버전의 UNIX에 탑재되기 시작하면서 UNIX와 TCP/IP에 결합되기 시작하였으며, 오늘날에도 가장 일반적으로 사용되는 라우팅 프로토콜의 하나이다. RIP의 주요 특징은 다음과 같다.


라우팅 테이블은 데이터그램 패킷을 통하여 모든 라우터에 브로드캐스트된다.

송신지와 수신지 간의 거리는 패킷이 경유하는 라우터의 갯수에 해당하는 hop 수로 표시하는데, 하나의 라우터를 경유한다면 이를 '1 hop 거리', 두개의 라우터를 경유한다면 '2 hop 거리' 등으로 표시한다. RIP에서는 최대 hop을 16으로 제한하므로 16 이상의 경우는 도달할 수 없는 네트워크를 의미한다.

매 30초 이내에 새로운 라우팅 정보를 브로드캐스트하며, 만약 180초 이내에 새로운 라우팅 정보가 수신되지 않으면 해당 경로를 이상상태로 간주한다.

RIP에서는 액티브와 패시브 두가지 유형의 사용자를 정의하고 있다. 액티브 사용자(라우터가 대표적)는 자신이 속해있는 네트워크 내에서 데이터그램 패킷을 통하여 매 30초마다 라우팅 정보를 브로드캐스트한다. 반면에, 패시브 사용자(호스트 컴퓨터가 대표적)는 RIP 정보를 수신하여 경로를 갱신하지만 스스로 라우팅 정보를 송신하지는 않는다. RIP 패킷내에는 송신지에서 바라본 각 수신지 주소와 hop 수 등이 포함되어 있다.


한편, RIP에서는 성능과 신뢰성을 높이기 위하여 몇가지 규칙이 있다.

첫째는, RIP로 수신한 라우팅 정보는 단지 180초 동안만 유효하다. 이렇게 함으로써 180초 이내에 라우팅 정보가 수신되지 않으면 라우터가 고장났다는 사실을 알 수 있게 된다.

둘째로, 현재의 hop 수보다 낮은 hop 수의 라윙 정보를 수신하면, 새로 수신한 라우팅 정보로 대체하여 효율적인 경로를 선택할 수 있게 한다.

그러나 RIP에는 여러가지 결함이 있다. 첫째는, hop 수가 최대 16으로 제한되어 있으며, 16은 라우터에서 특별한 용도로 사용하므로 실제 패킷이 전달될 수 있는 네트워크의 hop 수는 15로 제한된다. 이로 인하여 전체 네트워크의 규모가 제한되어 대규모 인터네트워킹에서는 RIP를 적용할 수 없게 된다.

또한 RIP에서 사용하는 벡터 디스턴스 알고리즘은 네트워크의 고장 또는 변화가 일어난 이후에 이 사실이 전체 네트워크에 전달되어 안정화하는데까지 많은 시간이 소요된다. 따라서 RIP에서는 잘못된 라우팅 정보가 전달될 가능성이 있다. 이같은 문제는 다음과 같은 방법으로 해결된다.


Split Horizon : 라우팅 정보를 수신한 라우터는 이를 전달해준 인터페이스 포트를 기록해 두고 해당포트에 관한 정보는 이 포트를 통하여 재전달하지 않는다.

hold down : 회선이 고장난 이후에 라우팅 테이블을 갱신하지 않고 전체 네트워크의 경로가 새로 갱신될 때까지 기다린다.

poison reverse : 회선이 고장나는 경우 라우터는 즉시 해당 경로의 hop 수를 16으로 정정하여 전체 네트워크에 여러차례 전송한다.

RIP는 두 네트워크간의 hop 수만을 기준으로 하여 라우팅 방식을 결정하므로 이 방식을 사용하면 데이터 패킷은 가장 짧은 경로를 통하여 전달된다. 그러나 두 네트워크 세그먼트간에서 가장 짧은 경로를 택하는 것이 바람직하지 않을 때가 있다. 즉, 하나의 경우는 두 개의 라우터간에 T1 회선이 연결되어 있고(2 hopt), 다른 경로는 3개의 라우터간에 FDDI가 구성되어 있는 경우(3 hop)에 FDDI를 경유하는 빠른 경로가 있음에도 불구하고 성능이 떨어지는 T1 회선을 선택하게 된다.



(2) IGRP(Interior Gateway Routing Protocol)

시스코사에서 독자적으로 개발한 프로토콜로, 독립적 네트워크 내에서만 사용하기 위해 개발된 것이다. RIP와 유사하게 IGRP는 hop수를 기준으로한 정보를 전송한다. 라우팅 경로의 결정은 회선의 전송능력, 전송지연시간, 회선의 사용률, 신뢰성을 바탕으로 결정한다. IGRP는 또한 복수의 경로상에서의 로드밸런싱 기능을 지원한다.


IGRP의 패킷 포맷은 다음과 같이 구성되어 있다.


IGRP 패킷의 첫째 필드는 버전 번호를 포함한다. 이 버전 번호는 사용중인 IGRP의 버전을 명시하여, 신호차이와 비호환성에 대비한 필드이다. 버전필드 다음은 Opcode 필드이다. 이 필드는 패킷의 Type을 명시한다. 1은 Update 패킷을, 2는 Request 패킷을 표시한다. Request 패킷은 다른 라우터로부터 라우터 테이블을 요청할 때 사용되며, 이 패킷은 version, opcode, as number 필드를 담고 있는 헤더로만 구성된다. update 패킷은 routing table entry를 포함한다. routing Table Entry에 대한 제한은 없으며, 단지 IP 헤더를 포함하여 패킷은 단지 1,500byte보다 커서는 안된다.


opcode 필드 다음은 Edition 필드이다. 이 필드는 Routing Table이 바뀔 때마다 증가하는 Serial Number를 담고 있다. 이 Edition 값은 라우터들이 이미 바뀐 정보를 update하지 않도록 하는데 사용된다.


다음 필드는 AS Number이다. 이 필드는 라우터들이 다수의 AS들을 연결할 수 있기 때문에 요구된다. 한 라우터 내에서 다수의 AS는 다른 AS Routing 정보를 유지한다.

다음 세 필드들은 update 패킷에 Subnet의 Number와 Major Network의 Number, External Network의 Number를 명시한다. 이 필드는 IGRP Update Message가 세 영역을 가지기 때문에 필요한데 세 영역은 Subnet의 안쪽, 현재 AS의 안쪽, 현 AS의 외부이다. IGRP 헤더의 마지막 필드는 Checksum 필드이다. 이 필드는 받은 패킷의 이상유무를 계산한다.


Update Message들은 각각의 Routing Table Entry에 대한 일련의 7개의 Data 필드를 담고 있다. 첫째 필드는 Address 부분 3byte이고, 다음은 Metric 값을 나타내는 5byte인데, 5byte 중 첫번째는 Delay(10ms 167sec), 다음은 Bandwidth 필드(1,200bps 10Gbps), MTU(Maximum Transmission Unit;Maximum Packet Size) 크기를 나타내는 MTU 필드, 다음 필드는 Reliability 필드(송,수신 패킷 전송성공률), Load 필드(사용중인 Channel의 비율), Hop Count 필드로 구성된다.



(3) OSPF(Open Shortest Path First)

인터넷 엔지니어링 태스크 포스에서 개발한 프로토콜인 OSPF 프로토콜은 Shortest Path First라는 알고리즘을 사용한다. SPF 알고리즘에서는 모든 라우터가 토폴로지에 관한 모든 정보를 완벽히 갖고 있다. OSPF의 중요한 특징을 살펴보면 다음과 같다.


사용자에 의한 경로의 지정, 가장 경제적인 경로의 지정, 복수경로의 선정 등의 기능을 제공하며, 변화의 발생에 관한 정보가 RIP에 비하여 빨리 전파된다.

라우팅정보를 인접한 라우터에 모두 전송하는 플러딩 방식을 사용하므로 토폴로지에 관한 정보가 전체 네트워크상의 라우터에서 동일하게 유지된다.

각 라웉터는 자신을 네트워크의 중심점으로 간주하여 최단 경로의 트리를 구성한다. IP 주소와 IP에서 제공하는 서비스만ㅇ르 사용한다.

여러 종류의 서비스를 제공하기 위하여 분산된 트리를 사용한다.

동일한 비용을 갖는 모든 경로에 트래픽을 분산시켜 전송한다.


□ OSPF 경로 선정

효율적으로 경로를 선정할 수 있는 OSPF 인터네트워크를 설계하려면 OSPF 메트릭스값 조정(Tuning), 지역 간 트래픽 제어(Control), OSPF 인터네트워크에서의 로드밸런싱 등과 같은 사항을 주지해야 한다.

OSPF 메트릭스 값 조정(Tuning) : OSPF 메트릭스의 기본 값은 대역폭을 근거로 산출된다.
지역간 트래픽 제어(Control) : 단 한대의 지역 경계 라우터만이 존재하는 경우, 그 지역에 속하지 않는 모든 트래픽은 지역 경계 라우터로 송신된다.

여러 대의 지역 경계 라우터가 있는 경우에는 1) 트래픽을 생성한 노드에서 가장 가까이 있는 지역 경계 라우터를 이용해 송신(트래픽은 가능한 빨리 지역을 벗어남) 2) 트래픽의 목적지에서 가장 가까이 있는 지역 경계 라우터를 이용해 송신(트래픽은 가능한 늦게 지역을 벗어남) 등 2가지 중 한가지 방식으로 트래픽이 송신된다.


□ OSPF 경로 축약
경로축약기법을 사용하면 2가지 라우팅 정보가 네트워크를 통해 전달된다. 즉 백본이 각 지역에 대한 정보를 얻는 Area-to-Backbone Advertisement, 각 지역에서 백본과 다른 지역에 대한 정보를 얻는 Backbone-to-Area Advertisement다.


Area-to-Backbone Advertisement : 적절한 축약을 위해서는 OSPF 지역 설계시 다음과 같은 사항을 고려해야 한다. 1) OSPF 경로 축약은 지역 경계 라우터에서 수행된다. 2) OSPF는 VLSM을 지원하므로 네트워크/서브넷 어드레스에 대한 임의의 Bit Boundary 축약이 가능하다. 3) OSPF 사용시에는 수작업으로 축약해야 한다.

Back-to-Area Advertisement : 각 지역에는 4가지 형태의 라우팅 정보가 존재한다.

ⓐ 기본 경로 : 지정된 IP 네트워크/서브 네트워크를 찾을 수 없는 경우에는 라우터가 기본 경로에 지정된 목적지로 패킷을 넘긴다.

ⓑ 지역내 경로(Intra-areaRoutes) : 명확히 지정된 네트워크나 서브넷 경로는 지역내의 모든 네트워크나 서브넷에 전송한다.

ⓒ 지역간 경로(Interarea Routes) : 각 지역은 동일한 AS의 네트워크에 대한 명확히 지정된 네트워크나 서브넷 경로를 전송한다.

ⓓ 외부 경로(External Routes) : 서로 다른 AS끼리 라우팅 정보를 교환할 때 교환되는 경로를 외부 경로라 부른다.

한편 지역은 해당 지역에서 사용하는 라우팅 정보에 따라 크게 3가지로 구분한다.

Nonstub 지역 : 4가지 형태의 경로를 모두 전송하는 지역. RIP와 OSPF를 둘다 이용하는 ASBR(Autonomous Sustem BorderRouter)가 설치된 지역이나 지역간ㅇ르 연결하는 가상 링크(Virtual Link)가 설정된 지역은 반드시 Nonstub 지역이어야 한다. 이 지역은 가장 많은 자원이 집중된 지역이다.

Stubarea : 외부 경로를 제외한 나머지 3가지 형태의 경로를 전송하는 지역. 단 한대의 지역경계 라우터가 있는 경우 바람직한 형태의 지역이나 여러대가 있는 경우에도 채택할 수 있다.

축약을 하지 않은 Stubarea : 이 지역에서는 기본 경로 지역 내 경로만이 전송된다.
이러한 지역은 백본에 지역을 연결할 때 한 대의 라우터만 사용하는 단순한 구성인 경우 바람직하다.



□ OSPF 컨버전스

OSPF의 특징 중 가장 매력있는 점은 형상 변화가 발생하면 매우 신속하게 그 변화에 적응하는 능력이다. 라우팅 컨버전스는 장애 발생 감지와 새로운 경로 모색으로 구성된다.


OSPF 네트워크는 시리얼 라인장애(Carrier Loss), 토큰링 장애, FDDI 장애 등과 같은 장애를 발생 즉시 감지해낼 수 있다. 장애가 발생하면 그것을 감지한 라우터는 변경된 정보를 포함하는 Link State 패킷을 해당 지역의 모든 라우터에 송신한다. 이 패킷을 수신한 모든 라우터는 SPF(Shortest Path First) 알고리즘을 이용해 전 경로를 재계산한다.


OSPF 컨버전스에 영향을 주는 요소는 장애 감지와 경로 재계산이다. OSPF는 2가지 방식으로 장애를 감지한다. 첫째는 인터페이스의 상태변화이고, 두번째는 Dead Timer라 부르는 시간내에 이웃 라우터로부터 hello 패킷이 수신되지 않은 경우 장애로 판단한다. Dead Timer의 기본값은 브로드캐스트 네트워크의 경우 40초, 비브로드캐스트 네트워크의 경우에는 2분이다. 경로 계산에 걸리는 시간은 지역의 크기 데이터베이스내의 경로 개수에 따라 달라진다.



□ OSPF 네트워크 확장성

확장성은 전체 네트워크의 구조와 어드레싱 방식에 의해 좌우된다. 계층 구조의 어드레싱 환경과 정형화된(체계적인) 어드레스 부여가 OSPF 네트워크 확장성을 결정한다.



□ OSPF 보안성

라우팅 프로토콜에 대해서는 OSPF 네트워크에 접속된 라우터 제어와 라우터끼리 교환하는 라우팅 정보 제어 등 2가지의 보안 기법을 적용할 수 있다. OSPF 패킷에서는 허가(Authentication) 필드를 사용할 수 있으므로, 이 필드를 이용하면 현재 제어하고 있지 않은 호스트나 라우터에서 과실로 이한 OSPF의 실행을 막아 네트워크 전체의 불안정 가능성을 줄일 수 있다. 그러나 동일한 OSPF 지역에 속해 있는 라우터 간의 라우팅 정보는 같으므로 OSPF 네트워크에서는 보안 기능을 제공하기 위해 라우트 필터(Route Filter)를 사용할 수 없다.

Posted by 초나미
TAG network

MIME은 아스키 데이터가 아닌 메시지를 인터넷을 통해 보낼 수 있도록 하는 프로토콜이다.


이메일 전송 프로토콜인 SMTP는 원래 7bit 아스키 데이터만을 지원했다. 7bit 아스키 데이터라는 조건을 만족하기 위해서는 오직 영문자만을 사용하여 이메일을 보내는 방법밖에 없다. 컴퓨터 기술이 점점 발달하면서 영문 텍스트만 지원하는 이메일 방식이 매우 불편해짐에 따라, 아스키 데이터 이외의 다른 종류들도 인식하고 처리할 수 있는 방식을 IETF(Internet Engineering Task Force)에 제안하였다.


현재 이메일 클라이언트들은 MIME을 지원하고 있다. MIME을 사용하면서부터 이미지, 사운드, 영상 등 8bit 바이너리 컨텐츠도 주고 받을 수 있게 되었다. 또한 영어가 아닌 다른 언어들도 지원되면서 세계 어느 나라에서나 편리하게 이메일을 사용할 수 있게 되었다.


메시지를 MIME 형식에 맞게 바꾸어 주는 것은 이메일을 보내고 받을 때 이메일 클라이언트나 메일 서버에 의해 자동적으로 이루어진다. 또한 웹브라우저에는 여러 타입의 MIME들이 기본적으로 탑재되는데, 이는 HTML 형식이 아닌 다른 형식들도 보여줄 수 있게 한다.


또한 MIME은 새로운 컨텐츠 타입과 다른 MIME 특성값을 입력할 수 있는 방법을 정의에 포함하고 있기 때문에 확장성이 있다.


MIME의 중요한 목표는 기존의 이메일 서버나 클라이언트들에게 변화를 요구하지 않겠다는 것이다. 즉 기존의 이메일 서버나 클라이언트들이 새로 다른 프로그램을 설치하거나 하는 일 없이 MIME을 받아들일 수 있도록 하겠다는 것이다.


기존 형식으로 쓰여진 메시지를 기본값으로 하여, 기존 클라이언트들은 기본값으로 메시지를 이해하고, 새로운 클라이언트들은 MIME 형식으로 쓰여진 나머지 부분을 보면서 메시지를 이해하는 것이다. 또한 간단한 MIME 형식의 텍스트메시지는 기존 클라이언트나 서버에서도 이해 가능하다.


MIME 메시지 분석


보통의 텍스트 이메일 메시지는 헤더부분(To: From: Subject: 등)과 본문 부분으로 구성된다. MIME 메시지는 MIME 메시지 헤더와 MIME PART 헤더로 구성된다. MIME 메일은 RFC 822에 기반을 둔 메일을 확장한 것으로 MIME 역시 RFC의 한 부분이다.


헤더 필드


MIME 헤더에는 MIME 메시지 헤더와 MIME PART 헤더로 분류된다. MIME 메시지 헤더는 다음과 같이 구성된다.


MIME-Version 헤더

- 사용할 MIME의 버전을 제공한다.


Content 타입 헤더

- 데이터의 형식을 확인해서 사용할 수 있도록 해준다. text, image, audio, video, applications, multipart, message 형식을 사용할 수 있다. 임의의 바이너리 첨부물은 application/octet-stream 형식을 사용하면 된다. 몇 가지 예를 더 들면 image/jpg, application/msword, multipart/mixed 등이 있다.


Content-Transfer-Encoding 헤더

- 가장 중요한 헤더로써 데이터의 인코딩 유형을 보여주고 MUA를 사용해서 첨부물을 디코딩할 수 있도록 한다. 7bit, 8bit, 바이너리, quoted-printable, base64, custom, per attachment 중의 하나를 사용할 수 있다. 7bit 인코딩은 US ASCII 문자를 사용하는 인코딩이다. 8bit와 바이너리 인코딩은 일반적으로 잘 사용하지 않는다. Quoted printable은 사람들이 읽기 편한 보통의 텍스트를 사용하고 데이터에 영향을 줄 수 있는 게이트웨이를 통해 보호된다. 이것은 보통 바이너리를 사용하고 텍스트 형식의 데이터가 아니다. Base64는 보통 바이너리나 텍스트가 아닌 데이터들을 인코딩하는데 사용될 수 있다. 7bit 데이터가 아닌 것은 scheme(문자열을 쉽게 다루기 위해 설계된 프로그래밍 언어)를 사용해서 인터넷 메일 게이트웨이를 통과할 수 있다.


Content-ID 헤덩

- Content-Type 헤더가 message/external-body, multipart/alternative일 경우에 사용한다.


Content-Description 헤더

- 옵션 헤더로 메시지 부분에 대해서 US ASCII 형태로 설명한다.


Content-Disposition 헤더

- 실험적인 헤더로써 MUA가 디스플레이할 첨부물의 첨부형식을 인라인 형식으로 할 것인지 첨부형식으로 할 것인지를 결정할 힌트를 제공한다.


MIME PART 헤더는 MIME-Version헤더를 제외한 것을 사용할 수 있다. 만약, MIME 헤더가 메시지 블록의 한 부분이라면 전체 메시지에 적용된다. 하지만, MIME PART 내에서 사용되면 그것은 그 PART에만 적용된다.


<출처: http://tong.nate.com/duck403/29967286>

Posted by 초나미

IP주소:네트워크 및 주소

 

IP주소란 어떤 TCP/IP 네트워크에 있는 호스트를 고유하게 식별하는 32비트 숫자를 말한다.

서브넷마스크가 호스트, 네트워크 및 서브네트워크를 구분하는데 어떻게 사용되는지 이해하려면 이진 표기법으로 된 IP주소를 확인해 보면 된다.


예를 들어, 점으로 구분된 십진수 IP주소 192.168.123.132는 이진 표기법으로 32비트 숫자110000000101000111101110000100에 해당한다. 이 숫자는 어려울 수도 있으므로 이진수로 8자리씩 4부분으로 나누어진다.


이러한 8비트 섹션을 옥텟(octet)이라고 한다. 그러면 예제 IP 주소는 11000000.10101000.01111011.10000100이 된다. 이 숫자도 마찬가지로 알아보기가 어려우므로, 대부분의 경우 이진 주소를 점으로 분리된 십진수 형식으로 변환해서 사용을 하게 된다.


TCP/IP WAN(Wide Area Network)이 네트워크 집합으로서 효율적으로 작동하도록 하기 위해서 네트워크 사이에서 데이터 패킷을 전달하는 라우터는 정보 패킷이 향하는 호스트의 정확한위치를 모른다.


라우터는 해당 호스트가 어떤 네트워크의 구성원인지만을 알고 있고 자신의 라우팅 테이블에저장되어 있는 정보를 사용하여 대상 호스트의 네트워크로 패킷을 가져가는 방법을 결정한다.패킷은 대상 네트워크로 배달된 다음 해당 호스트로 배달된다.


이러한 프로세스가 작동하기 위해 IP 주소는 두 부분으로 이루어진다. IP주소의 첫째 부분은 네트워크 주소로 사용되고, 마지막 부분은 호스트 주소로 사용된다. 예제 192.168.123.132를 두 부분으로 나누면 다음과 같이 된다.


192.168.123(네트워크) .132(호스트)

혹은

192.168.123.0(네트워크 주소) 0.0.0.132(호스트 주소)

이렇게 표현할 수 있다.


 

서브넷마스크


TCP/IP가 작동하기 위해 필요한 두번째 항목이 바로 서브넷마스크이다. 서브넷마스크는TCP/IP 프로토콜에 의해 호스트가 로컬 서브넷에 있는지 아니면 원격 네트워크에 있는지를 확인하는데 사용된다.


TCP/IP에서는 네트워크 주소와 호스트 주소로 사용되는 IP주소의 부분이 고정되어 있지 않아 또다른 추가 정보가 있지 않는 한 위의 네트워크 주소와 호스트 주소를 확인할 수 없다. 이러한 추가 정보는 서브넷마스크라고 하는 또다른 32비트 숫자의 형태로 제공된다.


이 예제에서는 서브넷마스크가 255.255.255.0이다. 이진 표기법에서는 255가 11111111에 해당하므로 이 서브넷마스크가 아래와 같다는 것을 모른다면 다음 숫자가 무엇을 의미하는지 이해하기 어려울 것이다.


11111111.11111111.11111111.00000000


IP주소와 서브넷마스크를 나란히 놓으면 주소의 네트워크 부분과 호스트 부분을 아래와 같이 분리할 수 있다.


11000000.10101000.01111011.10000100  --  IP 주소(192.168.123.132)
11111111.11111111.11111111.00000000  --  서브넷마스크(255.255.255.0)


처음 24비트(서브넷마스크에서 1로 이루어진 숫자)는 네트워크 주소이고 마지막 8비트(서브넷마스크에서 나머지 0으로 이루어진 숫자)는 호스트 주소이다. 이 숫자가 의미하는 것은 아래와 같다.


11000000.10101000.01111011.00000000  --  네트워크 주소(192.168.123.0)
00000000.00000000.00000000.10000100  --  호스트 주소(0.0.0.132)


이제 255.255.255.0이라는 서브넷마스크를 사용하는 이 예제에서 네트워크 ID는 192.168.123.0이고, 호스트 주소는 0.0.0.132라는 것을 알 수 있을 것이다. 패킷이 로컬 서브넷이나 원격 네트워크로부터 192.168.123.0 서브넷에 도달하여 해당 서브넷에 목적지 주소 192.168.123.132가 있으면 컴퓨터가 네트워크로부터 해당 패킷을 받아서 처리한다.


거의 모든 십진 서브넷마스크는 왼쪽은 모두 1이고 오른쪽은 모두 0인 이진 숫자로 변환된다.

또다른 일반적으로 사용되는 서브넷마스크는 아래와 같다.


255.255.255.192    11111111.11111111.11111111.11000000
255.255.255.224    11111111.11111111.11111111.11100000



네트워크 주소

 

인터넷 주소는 인터넷을 관리하는 조직인 InterNIC에서 할당하고 있다. 이러한 IP주소는 클래스로 나누어진다. 이러한 클래스 중 가장 일반적으로 사용되는 클래스는 A, B, C입니다. 클래스 D와 E도 있지만 일반 사용자는 대개 사용하지 않는다.

각 주소 클래스는 서로 다른 기본 서브넷마스크를 갖고 있다. 첫번째 옥텟을 보면 IP주소의 클래스를 식별할 수 있다. 다음은 클래스 A, B, C의 인터넷 주소 범위와 예제 주소이다.


▷ 클래스 A 네트워크는 기본 서브넷마스크 255.0.0.0을 사용하고 첫번째 옥텟으로 0-126 사이의 값을 갖는다. 주소 10.52.36.11은 클래스 A 조소이다. 이 주소의 첫번째 옥텟은 10으로, 1-126(포함) 사이에 있다.


▷ 클래스 B 네트워크는 기본 서브넷마스크 255.255.0.0을 사용하고 첫번째 옥텟으로 128-191 사이의 값을 갖는다. 주소 172.16.52.63이 클래스 B 주소이다. 이 주소의 첫번째 옥텟은 172로, 128-191(포함) 사이에 있다.


▷ 클래스 C 네트워크는 기본 서브넷마스크 255.255.255.0을 사용하고 첫번째 옥텟으로 192-223 사이의 값을 갖는다. 주소 192.168.123.132가 클래스 C 주소이다. 이 주소의 첫번째 옥텟은 192로, 192-223(포함) 사이에 있다.

어떤 시나리오에서는 해당 네트워크의 실제 토폴로지 때문에, 또는 네트워크나 호스트 수가 기본 서브넷마스크 제한을 초과하여 기본 서브넷마스크 값이 조직의 필요 사항과 맞지 않을 수도 있다. 다음 절에서는 서브넷 마스크를 사용하여 네트워크를 나누는 방법에 대해 설명한다.


 

서브넷 구성

 

클래스 A, B, C TCP/IP 네트워크는 시스템 관리자에 의해 더 작은 단위로, 즉 서브넷으로 나누어질 수 있다. 인터넷의 논리적 주소 체계(IP주소와 서브넷으로 이루어진 추상적 세계)와 실제로 사용되는 실제 네트워크를 맞출 때 이러한 작업이 필요하다.


IP주소 블록을 맡고 있는 시스템 관리자가 관리하는 네트워크가 이 주소에 잘 맞는 방식으로 구성되어 있지 않을 수도 있다. 예를 들어 각각 다른 사이트에 있는 3개의 네트워크에서 150대의 호스트를 갖고 있고 하나의 TCP/IP 라우터로 연결되어 있는 광역 네트워크를 갖고 있다고 가정해 보자. 3개의 네트워크는 각각 50대의 호스트를 갖고 있다. 클래스 C 네트워크192.168.123.0을 할당 받았다고 가정해 보자. 이 주소는 설명을 위한 것으로 실제로는 인터넷에서 할당받는 범위에 있지 않다. 따라서 150대의 호스트에 대해 192.168.123.1 - 192.168.123.254 사이의 주소를 사용할 수 있다.


호스트 부분이 모두 1이거나 모두 0인 이진 주소는 유효하지 않기 때문에 이 예에서 192.168.123.0 주소와 192.168.123.255 주소는 사용할 수 없다. 0 주소는 호스트를 지정하지 않고 네트워크만을 지정하는데 사용되므로 유효하지 않다. 255 주소(이진 표기법에서 호스트 주소가 모두 1인 주소)는 네트워크 상의 모든 호스트에 메시지를 브로드캐스트하는데 사용된다. 이렇게 네트워크 또는 서브넷의 첫번째 주소와 마지막 주소는 개별 호스트에 할당될 수 없다.


이제 254대의 호스트에 IP주소를 제공할 수 있을 것이다. 이 경우 150대의 컴퓨터가 모두 하나의 네트워크에 있어야 적절하다. 하지만 이 예에서는 150대의 컴퓨터가 3개의 실제 네트워크에 나뉭져 있다. 각 네트워크에 추가로 주소 블록을 요청하는 대신 하나의 주소 블록을 여러 개의 실제 네트워크에 사용할 수 있도록 네트워크를 여러 개의 서브넷으로 나눈다.


이 경우에는 네트워크 주소는 늘리고 가능한 호스트 주소 범위는 줄이는 서브넷마스크를 사용하여 네트워크를 4개의 서브넷으로 나눈다. 즉, 호스트 주소에 사용되는 비트 중 일부를 빌려 이를 주소의 네트워크에 사용할 수 있다.

이진 표기법에서는 255.255.255.192가 11111111.11111111.11111111.11000000과 같기 때문에 그렇다. 마지막 옥텟의 처음 두 자릿수는 네트워크 주소가 되어 추가 네트워크 00000000(0), 01000000(64), 10000000(128), 11000000(192)를 가질 수 있다. 어떤 관리자는 서브넷마스크로 255.255.255.192를 사용할 경우 서브네트워크를 두 개만 사용하기도 한다. 이러한 4개의 네트워크에서 마지막 6자리 이진수는 호스트 주소에 사용할 수 있다.


서브넷마스크 255.255.255.192를 사용하면 192.168.123.0 네트워크가 4개의 네트워크 192.168.123.0, 192.168.123.64, 192.168.123.128, 192.168.123.192로 나누어진다. 이들 4개 네트워크에서 유효한 주소는 다음과 같다.


192.168.123.1-62, 192.168.123.65-126, 192.168.123.129-190, 192.168.123.193-254 모두 1과 모두 0인 이진 호스트 주소는 유효하지 않으므로 마지막 옥텟이 0, 63, 64, 127, 128, 191, 192, 255인 주소는 사용할 수 없다는 점을 기억하자.


두 호스트 주소, 192.168.123.71과 192.168.123.133을 보면 그 이유를 알 수 있다. 기본 클래스 C 서브넷마스크 255.255.255.0을 사용할 경우 이 두 주소가 모두 192.168.123.0 네트워크에 있다. 그러나 서브넷마스크 255.255.255.192를 사용한다면 이 두 주소가 각각 다른 네트워크에 있게 된다. 즉, 192.168.123.71은 192.168.123.64 네트워크에 있고 192.168.123.133은 192.168.123.128 네트워크에 있게 된다.


 

기본 게이트웨이


어떤 TCP/IP 컴퓨터가 다른 네트워크에 있는 호스트와 통신해야할 경우 대개 라우터라고 하는 장치를 통해 통신한다. TCP/IP 용어에서 호스트에서 지정되는 라우터는 해당 호스트의 서브넷을 다른 네트워크에 링크하므로 기본 게이트웨이라고 불린다. 이 절에서는 네트워크의 다른 컴퓨터나 장치에 도달시키기 위해 패킷을 해당 기본 게이트웨이에 보낼지 여부를 TCP/IP가 어떻게 결정하는지에 대해 설명한다.


호스트가 TCP/IP를 사용하여 다른 장치와 통신할 때는 정의된 서브넷마스크와 목적지 IP주소 대 서브넷마스크와 고유의 IP주소 사이에서 비교 프로세스를 수행한다. 이러한 비교의 결과는 목적지가 로컬 호스트인지 아니면 원격 호스트인지 여부를 컴퓨터에 알려준다.


이 프로세스의 결과에 따라 목적지가 로컬 호스트인 것으로 판단되면 컴퓨터가 해당 로컬 서브넷에서 패킷을 보낸다. 비교 결과 목적지가 원격 호스트인 것으로 판단되면 컴퓨터가 자신의 TCP/IP 등록 정보에 정의된 기본 게이트웨이로 패킷을 전달한다. 그러면 라우터가 해당 패킷을 올바른 서브넷으로 전달해야 한다.


 

문제 해결


TCP/IP 네트워크 문제는 종종 컴퓨터의 TCP/IP 등록 정보에서 세가지 주요 항목을 잘못 구성하기 때문에 발생한다. TCP/IP를 구성할 때의 오류가 네트워크 동작에 어떠한 영향을 미치는지 이해하고 있으면 일반적인 많은 TCP/IP 문제를 해결할 수 있다.


서브넷마스크가 올바르지 않은 경우: 네트워크가 자신의 주소 클래스에 대해 기본 마스크 외에 다른 서브넷마스크를 사용하는 반면 클라이언트는 여전히 주소 클래스에 대해 기본 서브넷마스크를 사용하도록 구성되었다면 멀리 있는 네트워크에 대한 통신은 성공하지만 인접한 네트워크에 대한 통신은 실패한다. 예를 들어 앞 부분에 있는 서브넷 구성 예에서처럼 서브넷을 4개 만들었지만 TCP/IP 구성에서 잘못된 서브넷마스크 255.255.255.0을 사용하면 어떤 컴퓨터가 다른 서브넷에 있는지 여부를 호스트가 판단할 수 없다.


이러한 현상이 발생하면 같은 클래스 C 주소에 속하는 다른 실제 네트워크에 있는 호스트를 목적지로 하는 패킷이 배달을 위해 기본 게이트웨이로 보내지지 않는다. 어떤 컴퓨터가 자신이 속한 로컬 네트워크의 호스트와는 통신할 수 있고, 가까이에 있고 같은 클래스 A, B, C 주소를 갖고 있는 네트워크를 제외한 모든 원격 네트워크와 교신할 수 있을 경우에 이러한 현상이 일반적으로 발생한다. 이 문제를 해결하려면 TCP/IP 구성에서 해당 호스트에 대해 올바른 서브넷마스크를 입력하면 된다.


IP주소가 올바르지 않은 경우: 로컬 네트워크에서 서로 다른 별개의 서브넷에 있어야 하는 IP주소를 컴퓨터에 부여하면 이들 컴퓨터가 통신할 수 없다. 이들 컴퓨터는 대상 컴퓨터에 올바르게 전달할 수 없는 라우터를 통해 서로에게 패킷을 보내게 된다. 이러한 문제가 발생하면 컴퓨터가 원격 네트워크에 있는 호스트와 교신할 수 있지만 로컬 네트워크에 있는 일부 컴퓨터나 모든 컴퓨터와는 통신할 수 없다. 이 문제를 해결하려면 동일한 실제 네트워크 상의 모든 컴퓨터가 동일한 IP 서브넷의 IP주소를 갖도록 해야한다.


기본 게이트웨이가 올바르지 않은 경우: 올바르지 않은 기본 게이트웨이를 사용하여 구성된 컴퓨터는 자신이 속한 네트워크 세그먼트에 있는 호스트와는 통신할 수 있지만 일부 또는 모든 원격 네트워크에 있는 호스트와는 통신할 수 없다. 하나의 실제 네트워크가 라우터를 두개 이상 가지고 있고 잘못된 라우터가 기본 게이트웨이로 구성된 경우 호스트가 일부 원격 네트워크와는 통신할 수 있지만 다른 원격 네트워크와는 통신할 수 없다. 일반적으로 이 문제는 어떤 조직에 내부 TCP/IP 네트워크에 대한 라우터와 인터넷에 연결된 라우터가 따로 있는 경우에 발생한다.


<출처: http://xianglai.tistory.com/tag/%EC%84%9C%EB%B8%8C%EB%84%B7%ED%8C%85>

Posted by 초나미

❑ IPv4와 IPv6 구조


1) IPv4
   - 32비트 체계이며, 8비트씩 4부분(옥텟)으로 구성

   - 각 옥텟당 8비트로 구성되므로 28=256 즉, 0~255까지의 숫자 사용 가능
     ex) 11000000.10101000.00001010.10000010(2진) → 192.168.10.130(10진)

   - 패킷 크기가 64Kbyte로 제한

   - 주소 종류 : 유니캐스트(Unicast), 멀티캐스트(Multicast), 브로드캐스트(Broadcast)



2) IPv6
   - 128비트 체계이며, 16비트씩 8부분으로 16진수로 표시
     예) 0010000000000111 0000010000000110 1010101111001101 0000000011111111
         0000000000000000 0000000000000000 1111111111111111 0001000100010001
         → 2007:0406:ABCD:00FF:0000:0000:FFFF:1111
         → 2007:0406:ABCD:FF:0:0:FFFF:1111
         → 2007:0406:ABCD:FF::FFFF:1111


   - IPv4에서의 서브넷 마스크는 지원되지 않으며 프리픽스 길이표기만 지원
     예) 21DA:D3:0:2F3B:2AA:FF:FE28:9C5A/64
         → 처음 64비트가 네트워크 프리픽스임을 의미
         → 위 IP의 서브넷ID는 21DA:D3:0:2F3B::/64


   - 옵션 사용시 특정 호스트 사이에는 임의로 큰 크기의 패킷의 전송 가능

   - 고정크기의 단순한 헤더를 사용하는 동시에, 확장헤더를 통해 네트워크 기능에 대한 확장 및
      옵션 기능의 확장이 쉬움

   - 헤더가 40바이트로 IPv4보다 두 배 증가하였으나, 결정적으로 라우터의 성능에 영향을 미치는
      필드수는 12필드에서 8필드로 줄어 라우팅 성능 향상

   - Fragmentation이 엄격하게 통제되어 오로지 송신 호스트에서만 가능

   - Flow Label 개념을 도입하여 Application 특성에 따라 특별하게 취급하는 것이 가능

   - 패킷의 출처 인증과 데이터의 무결성 및 비밀 보장 기능을 확장헤더를 통해 적용 가능

   - 주소 종류 : 유니캐스트(Unicast), 멀티캐스트(Multicast), 애니캐스트(Anycast)


※ IPv4에서의 브로드캐스트는 네트워크 상에서 클라이언트들의 부하를 상승시킬 뿐 아니라 회선의
    효율적 사용도 방해하는 요인이며, 보안상의 문제점도 가지고 있어, IPv6에서는 브로드캐스트를
    없애고 애니캐스트를 추가하였다. 애니캐스트 주소로 지정된 패킷은 적절한 멀티캐스트 라우팅
    토폴로지를 통해 주소로 식별되는 인터페이스 중 라우팅 거리가 가장 가까운 인터페이스로 전달된다.

Posted by 초나미
TAG network

TCP Wrapper

보안 2007/08/25 02:09

TCP Wrapper


1. 개념


TCP Wrapper는 네트워크 서비스에 관련한 트래픽을 제어하고 모니터링할 수 있는 UNIX 기반의 방화벽 툴이다. 현재의 시스템에서 SYSTAT, FINGER, FTP, TELNET, RLOGIN, RSH, EXEC, TFTP, TALK등의 모니터링을 하고 필터링을 할 수 있게 해주는 것이다.

임의의 호스트가 서비스를 요청해 오면 실제 데몬을 구동하기 전에 접속을 허용한 시스템인지 여부를 확인하여 호스트명 및 서비스명을 로그에 남긴 다음, 허가된 시스템은 서비스를 제공하고 허가되지 않은 경우에는 접속을 차단해 준다.

기존의 설정파일이나 소스코드에 별다른 수정이 필요하지 않고, 정상적인 사용자들에게는 불편을 주지 않으면서도 허가되지 않은 접근의 제한 및 탐지가 가능하다.


2. inetd와 TCP wrapper

UNIX 기반에서 서버프로그램인 데몬들은 standalone 모드나 inetd 모드로 구동된다. standalone 모드는 시스템 부팅과 동시에 바로 실행되어 프로세스가 항상 떠 있어야 하는 데몬들로 자체 제어 매커니즘을 가지고 있다. 그에 비해 inetd 모드에서는 client의 요청이 있을때만 inetd 데몬에 의해서 해당 서비스데몬을 구동시키는데, inetd 데몬이 client로부터 들어오는 요청에 대해 /etc/inetd.conf 파일의 구성설정과 /etc/services 파일의 정의된 포트를 이용하여 서비스를 구분하고 해당 서비스의 서버데몬을 구동시켜준다.


※ 예) Client-Server 프로그램

   Client              Server             Application
   ----------------------------------------
   telnet               telnetd             remote login
   ftp                   ftpd                  file transfer
   finger               fingerd            show users
   systat              server             application
   ...  ...  ...


보통 UNIX 시스템에서는 들어오는 모든 종류의 네트워크 커넥션을 기다리는 하나의 데몬을 띄워서 사용하고 이 커넥션이 성립 되었을 때 이 데몬이 적당한 서버 프로그램을 실행하게 된다. 그리고 이 데몬은 다시 sleep이 되고 다른 커넥션을 기다리게 된다.

telnet의 경우를 예를 들면 다음과 같다.

[user] -- [telnet client] -- (inetd) -- [telnet server] -- [login]

이용자는 telnet 프로그램을 실행하여 원하는 시스템에 접속을 시도하고, 이 때 서버에서는 inetd가 요청을 받아 inetd.conf를 살펴본 다음 telnetd 프로그램을 실행시킨다.


※ TCP Wrapper 설치여부나 설치된 버전 확인

rpm -qa | grep wrappers


LINUX의 경우 6.X 버전에는 대개 TCP Wrapper가 설치되어 있으며, 7.0버전부터는 TCP Wrapper와 유사하나 보다 강화된 Xinet가 기본적으로 설치된다.


3. 접근제어 설정

① /etc/hosts.deny  --> 접근제어할 리스트
   /etc/hosts.allow --> 접근허용할 리스트
   (Not in either : 접근 허용)

② 접근제어 형식
daemon_list : client_list : option : option .... : shell_command
- daemon_list : 하나 이상의 데몬 프로세스 이름
- client_list : 하나 또는 그 이상의 호스트 이름, 호스트 어드레스, 패턴/와일드카드
- shell_command : 규칙이 매칭될 때 수행되는 shell 명령. 주로 허가되지 않은 접속 요청이 있을 때 접속을 요청한 클라이언트의 단말기에 에러 메시지를 출력하거나 특정인에게 메일을 발송하는 형태로 주로 사용.


※ 접근제어 기술

[기술 형식]                             [예]
IP Address                             10.20.30.14
Network Address/Netmask       10.20.30.14/255.255.255.0
Networkgroup                         @local-network
호스트 네임                            kisa.or.kr
와일드카드 이용                      LOCAL : /etc/hosts에 등록된 모든 호스트에 대해 적용
                                            ALL   : 모든 호스트에 대해 적용

※접근제어 예


/etc/hosts.deny

ALL: ALL EXCEPT .or.kr --> 모든 서비스에 대해 or.kr 도메인을 제외한 다른 시스템들은 접근을 차단
in.telnetd: 10.20.30.14
in.telnetd: 10.20.30.14: banners /etc/txts
---> /etc/txts라는 디렉토리를 만들고 그 안에 in.telnetd라는 텍스트 파일을 만들어야 된다.

/etc/hosts.allow


ALL: LOCAL --> 모든 서비스에 대해 local 호스트들의 접근 허용
in.telnetd: 10.20.30.14, 20.30.40.15
in.proftpd: 10.20.30.14
ipop3d: 10.20.30.14
in.proftpd: 10.20.30.0/255.255.255.0 EXCEPT 20.20.20.20

Posted by 초나미
TAG 보안