The Network Administrator's Guide V0.4Olaf Kirch1999년 8월 15일번역자 이 승 lvl@chollian.net, 신동원 kaien@aapd.metal.pusan.ac.kr현재 8장까지 번역이 되어 있습니다. 뒷부분을 좀 마무리 지어주세요 ! 1. Introduction to Networking
1.1 역사네트워킹을 하고자 한 생각은 아마 통신 그 자체만큼 오래되었을 것이다. 석기 시대 때 살았던 사람들을 한번 살펴보자 그 사람들은 개인의 의사를 전달하기 위해서 북을 사용했다. 원시인 'A'가 돌 던지기 게임을 할려고 원시인 'B'를 자기집에 부르려고 한다. 그런데 그들은 너무 멀리 떨어져서 살고 있기 때문에, 'A'가 북을 쳐서 'B'에게 신호를 보냈다. 그럼 'A'가 할 수 있었던 다른 방법은 없었을까? 1) 그는 'B'가 있는 장소로 직접 걸어 갈 수도 있었고, 더욱 커다란 북을 사용할 수도 있었으며, 그들 사이에서 중간쯤에 살고 있는 'C'에게 메시지를 전달하게 할 수도 있었다. 이 중 마지막 방법이 바로 네트워킹이다. 물론, 현재의 네트워킹은 우리 선조들의 방법과 도구에서 무수히 발전해 온 것이다. 요즈음에는, 토요일 축구시합{{. 유럽에서는 아직도 이와 같은 근본정신을 특별한 날에 보여주고 있다.}} 약속을 하기위해서, 광학섬유나 마이크로웨이브와 같은 거대한 선로를 통해서 서로서로 얘기를 주고받을 수 있는 컴퓨터를 이용한다. 아래에선 전선같은 골치아픈 이야기나 축구 따위는 다 잊고 이러한 통신이 어떻게 이루어질 수 있는지에 대해서만 이야기할 것이다. 우리는 이 안내서에서 UUCP에 기반한 것과 TCP/IP를 이용하는 두가지 방식의 네트워킹을 다룰 것이다. 두 컴퓨터 사이에서 데이터를 전송하기 위한 프로토콜 스위트와 소프트웨어 패키지를 설명할 것이다. 이 장에서는, 이 두가지 네트워킹에 대해 설명하고, 공통된 기본원칙에 대해 논의할 것이다. 우리는 네트워크를 서로 간에 통신을 주고받을 수 있는 호스트의 집합으로 정의한다. 이 때, 호스트 간의 통신은 많은 경우 통신을 전담하는 호스트의 서비스에 의존한다. 호스트들은 대부분의 경우 컴퓨터이겠지만 꼭 컴퓨터일 필요는 없다. 즉, 호스트가 X-terminal이나 인텔리전트 프린터일 수도 있다. 소규모 호스트 집단은 사이트라 부르기도 한다. 통신은 어떠한 언어 또는 규약이 없이는 불가능하다. 컴퓨터 네트워킹에서 통용되는 언어는 뭉뚱그려 프로토콜 이라 불린다. 하지만 영어 프로토콜의 "의정서", "외교의례" 중에서 "의정서"의 뜻을 생각해서는 안되고, 국가의 두 정상이 만났을 때 어떤 식으로 행동해야 하는지를 매우 형식적으로 규정하는 "외교의례"의 뜻에 더 비슷하다고 생각하여야 한다. {{.역자주 : 우리에겐 프로토콜이라는 단어에서 의정서나 외교의례의 뜻을 유추할 우려가 없을테니 필요없는 설명이겠다.}} 외교의례와 매우 유사하게 컴퓨터에서 사용하는 프로토콜들은 네트워크가 두 개 이상의 호스트 사이에서 메시지를 교환하기 위한 엄격한 규칙에 지나지 않는다.
1.2 UUCP NetworksUUCP는 Unix-to-Unix Copy를 줄인 말이다. UUCP는 처음에 시리얼 라인을 통해 파일을 전송하고, 전송을 예약하고, 원격 사이트에서 실행 프로그램을 실행시키는 기능을 하는 소프트웨어 패키지로 시작했다. 70년대 후반에 처음 나온 이후로 크게 변경되었지만, 그것이 제공하는 서비스들은 여전히 스파르타식이다. 어플리케이션은 여전히 다이얼업 전화 연결을 토대로 하고 있는 광 지역 정보 통신망에서 동작한다. 처음에 UUCP는 1977년 벨 연구소에서 유닉스 개발 사이트 간에 통신을 하기 위해 개발되었다. 1978년 중반에, 이 네트워크는 무려 80개 사이트에 연결되었다. 이것은 리모트 프린팅이 가능했고 어플리케이션으로 전자우편을 돌리고 있었다. 그러나 이 시스템에서 중점적으로 한 일은 새로운 소프트웨어를 배포하고, 버그를 고치는 일이었다. {{.시간이 지나도 그대로인 것은 있다.}}} 오늘날 UUCP는 더 이상 UNIX에 제한되어 있지 않아서, AmigaOS, DOS, Atari's TOS 등의 다양한 플랫폼에서 사용할 수 있는 공개용, 상업용 포트가 있다. UUCP 네트워크의 주요 단점중에 하나는 대역폭이 적다는 것이다. 한 이유는 최대 전송률을 가지는 전화 설비 지역이 많은 제한을 가진다는 것이고, 다른 한 이유는 UUCP 링크는 연결이 지속적이지 않고, 거의 다 연결되어 있다가 끊겼다를 반복한다.; 대신에 호스트들은 오히려 규칙적인 시간간격을 두고 서로 다이얼업으로 접속한다. 그러므로, 메일 메시지 하나가 UUCP 네트워크로 전송될 때, 전송되는 시간의 대부분 동안 메시지는 호스트의 디스크에서 하는일 없이 빈둥거리며 다음 연결을 기다리게 된다. 이러한 제약에도 불구하고, 여전히 많은 UUCP 네트워크가 전세계에서 운영되고 있다. 주로 취미로 호스팅을 하는 사람들이 저렴한 가격으로 사용자들에게 접속을 제공하고 있다. {{. 2006년 현재에도 유효한가?}} UUCP가 인기 있는 가장 주요한 요인은 The Big Internet Cable로 연결되어 있는 컴퓨터와 비교해서 그 가격이 매우 싸다는 것이다. 자신의 컴퓨터를 UUCP 노드로 만들기 위해서는 모뎀 한 대와 UUCP 구현이 된 컴퓨터, 그리고 내 UUCP mail과 news 피드를 받아 줄 다른 UUCP 노드 하나만 있으면 된다.
UUCP를 사용하는 방법Unix to Unix copy 란 이름이 시사하듯이 UUCP의 철학은 매우 단순하다. UUCP는 기본적으로 하나의 호스트에서 다른 호스트로 파일을 복사한다. 거기에 원격 호스트에서 할 수 있는 작업이 것이 더해진다. 여러분의 컴퓨터가 swim이라는 이름을 가진 가상의 호스트로 접근해서, 인쇄 명령인 lpr을 실행한다고 가정하자. 그러면 여러분은 swim {{- bash 셸(GNU Bourne Again Shell)을 사용할 경우, 여러분은 느낌표(!)를 쓸 때 이스케이프 문자를 덧붙여야 할지도 모른다. 왜냐하면 bash는 느낌표를 history 를 불러내는 명령으로 사용하기 때문이다. }} 상에서 이 책을 인쇄하기 위해 명령행에서 다음을 입력할 수 있다.
$ uux -r swim!lpr !netguide.dvi
UUCP 스위트의 명령인 uux는 swim에게 하나의 job을 스케줄한다. 이 작업은 입력 파일인 netguide.dvi과 이 파일을 lpr로 보내주라는 요청으로 이루어져 있다. -r 옵션은 uux에게 지금 바로 리모트 시스템을 부르지 않도록 지시하고 다음에 연결이 될 때까지 작업을 저장시켜준다. 이러한 작업을 스풀링이라 부른다. UUCP의 또 하나의 특징은 작업과 파일들을 여러 호스트를 거쳐서 전달할 수 있다는 것이다. 위 예제에서 본 swim이라는 호스트가 groucho와 UUCP 연결을 갖고, groucho는 큰 UNIX 어플리케이션 아카이브를 갖는다고 하자. 여러분의 사이트로 tripwire-1.0.tar.gz 파일을 다운로드 하기 위해 다음과 같은 명령을 쓸 수 있다.
$ uucp -mr swim!groucho!~/security/tripwire-1.0.tar.gz trip.tgz
생성된 작업은 groucho로부터 파일을 가져다 달라고 swim에 요청할 것이며, 여러분의 사이트로 파일을 보내 줄 것이다. 파일은 trip.tgz로 저장돠고, 파일의 도착은 메일로 여러분에게 통보 될 것이다. 이 작업 세 단계로 되어 있다. 첫 번째 단계는 여러분의 사이트가 swim으로 작업을 보낸다. 다음 단계로 swim이 groucho 와 접속했을 때, 요청한 파일을 다운로드한다. 마지막으로, swim에서 실제 여러분의 호스트로 파일을 전송한다. 오늘날 UUCP 네트워크에서 제공하는 가장 중요한 서비스로는 전자우편과 뉴스가 있다. 우리는 뒤에서 이들이 무엇인지를 다시 다루게 될 것이다. 여기선 간단히 소개만 하기로 한다. 전자우편 - 짧게 이메일 - 으로 우리는 다른 호스트에 어떻게 접속하는지는 모르지만, 다른 호스트의 사용자들과 메시지를 교환할 수 있다. 여러분의 사이트에서 목적 사이트로 메시지를 보내는 작업은 메일 처리 시스템가 전담하여 수행한다. UUCP 환경에서 메일은 수신 주소와 메일 메시지를 전하려고 하는 인접호스트 상에서 대개 rmail 명령을 수행하여 전송하게 된다. rmail 명령은 메시지를 다른 호스트로 다시 전달하고 되며 이런 과정이 반복되면서 메시지는 목적 호스트에 도착하게 된다. 우리는 이 부분을 13장에서 다시 자세하게 다룰 것이다. News는 분산된 게시판 시스템이라고 하는 것이 가장 간단하게 설명하는 방법일 것이다. 대부분의 경우 뉴스란 유즈넷 뉴스를 가리키며 유즈넷 뉴스는 참여하고 있는 사이트 수가 무려 120,000개에 달하는 가장 큰 뉴스 교환 네트워크이다. 유즈넷의 시초는 1979년 당시 새로 발표된 UNIX V7과 새로운 UUCP의 릴리스로 거슬러 올라간다. 세 명의 대학원생들이 Unix 커뮤니티 성원들 간에 일반적인 소식을 교환하자는 생각에서 출발하였다. 그들은 몇개의 스크립트 짰고, 이것이 최초의 netnews 시스템이 되었다. 1980년에는 듀크 대학, unc, phs와 노스캐롤라이나의 두 대학을 아우르게 되었고, 여기에서 결국 유즈넷이 발전하게 되었다. 비록 유즈넷이 UUCP를 기반으로 출발하기는 했지만, 현재 유즈넷은 더이상 특정 네트워크에 구애되지 않는 개념으로 발전하였다. 유즈넷에서 정보의 가장 기본적인 단위는 기사로 불리는 게시물이고, 기사는 주제별로 나뉘어 계층화된 뉴스그룹들 중 하나에 게시되어 올라간다. 대부분의 유즈넷 사이트는 모든 뉴스그룹 중 자신이 선택한 몇 그룹의 기사만을 받으며, 각 사이트는 하루에 평균 60MB정도의 기사를 갖고 있는다. UUCP 세계에서, 뉴스는 요청한 그룹들로부터 모든 기사들을 모아놓고, 몇 개의 batches 라고 하는 곳에 그것들을 묶어놓고, UUCP 연결을 이용해 보내게 된다. 이것들은 수신 사이트에 보내지게 되며, 나중에 이것들을 풀기 위해서는 rnews 명령을 사용하면 된다. 마지막으로, UUCP는 다이얼 업 공개 아카이브 사이트의 네트워킹 방식으로 쓰일 수 있다. UUCP 다이얼 업 연결로 사이트에 연결하고 guest 사용자로 로긴하여 접속하여 공개해 놓은 아카이브 영역에서 파일들을 전송받을 수 있다. 보통 guest 로긴의 계정명과 암호는 uucp/nuucp 또는 그와 비슷한 것이다.
1.3 TCP/IP NetworksUUCP가 저렴한 다이얼 업 네트워크에 대한 합리적인 해결책이긴 하지만, store-and-forward (저장해 놓았다가 전달하기) 기술로는 대응하기 힘든 경우도 많이 있음이 증명되었다. 예를 들면 랜(Local Area Networks,LAN)을 구성하는 경우이다. 랜은 보통 같은 빌딩 또는 같은 층에 위치한 몇 개의 컴퓨터가 서로 연결되어 동일한 작업환경을 제공해 주는 네트워크이다. 이러한 호스트들 사이에서는 일상적으로 파일을 서로 공유하고, 다른 기계에 깔려있는 어플리케이션들을 실행하는 등의 일을 하게 될 것이다. 이러한 작업은 완전히 다른 방식의 네트워킹을 요구한다. 온전한 파일과 처리 작업 명령을 전달하는 대신에, 모든 자료는 작은 덩어리(패킷)로 뉘어, 도착지 호스트로 지체없이 발송되고, 도착지 호스트에서는 이 덩어리들이 다시 하나로 모아지게 된다. 이 네트워크 형태를 packet-switched 네트워크라고 부른다. 여러 특징들 가운데에서도 이러한 네트워크는 대화형식 어플리케이션을 실행할 수 있다는 특징을 갖는다. 그 대가는 물론 소프트웨어가 엄청나게 복잡해 진다는 것이다. UNIX 시스템 - 물론 비 UNIX 사이트에서도 - 이 도입한 이런 네트워킹의 구체적 솔루션이 TCP/IP라고 알려진 프로토콜이다. 이 절에서는 TCP/IP의 기초적인 개념들을 살펴보겠다.
Introduction to TCP/IP-NetworksTCP/IP는 1969년 미 국방성에서 DARPA (Defense Advanced Research Projects Agency) 라는 연구 프로젝트가 그 시초이다. 이것이 ARPANET 이라는 실험용 네트워크로, 문제없다는 판단이 선 1975년에는 실제로 운용가능한 형태로 변환되었다. 1983년에는 새 프로토콜 스위트인 TCP/IP가 표준 프로토콜로 채택되었으며, 그 네트워크에 있는 모든 호스트들은 TCP/IP 프로토콜을 사용하도록 하였다. ARPANET이 마침내 인터넷(1990년에는 ARPANET 자체는 이미 없어져 버렸다.)으로 성장하였을 때 TCP/IP의 사용은 인터넷의 범위를 넘어 많은 네트워크로 퍼져나갔다. 가장 주목할 만한 것은 랜을 들 수 있지만, ISDN과 같은 빠른 디지털 전화망의 출현을 앞 둔 현재, TCP/IP는 앞으로 다이얼업 네트워크를 위한 전송에도 이용되리라고 본다. 다음 절에서는 TCP/IP에 관해 구체적으로 예를 들어 설명해 보기로 하겠다. Fredland 어딘가에 있는 Groucho Marx University (GMU)가 우리의 무대이다. 대부분의 학과는 각기 하나의 랜 네트워크를 갖고 있을 것이지만, 몇 학과는 둘 이상이 하나의 랜 네트워크를 공유하고 있을 것이고, 어떤 학과는 둘 이상의 네트워크를 갖고 있을 것이다. 모든 망은 서로 연결되어 있으며, 이 모든 것은 하나의 고속 링크를 통하여 인터넷으로 연결되어 있다. 여러분의 컴퓨터가 수학과에 있는 UNIX 호스트 (그 이름은 erdos {{{.erdos는 유명한 20세기의 수학자 이름이다.}}}) 에 LAN으로 연결되어 있다고 가정하자. quark {{{.quark는 물질을 구성하는 기본입자이다.}}}라고 부르는 물리학과에 있는 호스트로 접근하기 위해, 다음과 같은 명령을 입력하라.
$ rlogin quark.physics
Welcome to the Physics Department at GMU
(ttyq2) login:
프롬프트에서, andres같은 로긴명과 해당하는 패스워드를 입력하라. 그러면 quark 에서 그 시스템 콘솔 환경에 있는 것과 똑같이 명령을 입력할 수 있는 셸을 준다. 그 셸을 빠져나가면, 다시 자기 컴퓨터의 프롬프트로 되돌아 가게 된다. 여러분은 방금 바로 TCP/IP에서 제공하고 즉각적으로 반응하는 대화식 어플리케이션인 remote login을 사용한 것이다. quark로 원격으로 접속해 있는 동안 플로팅 프로그램이나, PostScript previewer 같은 X11 기반 어플리케이션을 쓰고 싶을 지도 모른다. 어플리케이션에게 당신 자신의 호스트 화면에서 출력을 보고 싶다고 알려주려면, DISPLAY 환경 변수를 설정해야 한다:
$ export DISPLAY=erdos.maths:0.0
이제 어플리케이션을 실행시킨다면, 어플리케이션은 quark의 X서버 대신에 당신의 erdos의 X 서버와 접촉하여 모든 윈도우를 당신의 화면에서 띄울 것이다. 물론, 이렇게 하려면 여러분이 erdos상에서 X11을 미리 실행시킬 필요가 있다. 여기서 요점은 TCP/IP를 이용해 quark와 erdos가 X11 패킷을 주고 받으며 여러분이 단일 시스템에서 어플리케이션을 돌리는 것 같은 착각을 줄 수 있다는 것이다. 여기서 네트워크는 거의 투명하게 되어 있다. TCP/IP 네트워크의 또 다른 중요한 어플리케이션으로는 NFS (Network File System을 뜻한다.)을 들 수 있다. 이 어플리케이션 또한 네트워크 투명성을 보인다. 왜냐하면, NFS는 기본적으로 다른 호스트로부터 디렉토리 계층을 마운트하여, 그것들이 로컬 파일 시스템인 것처럼 느끼게 해 준다. 예를 들면, 사용자의 홈 디렉터리들을 중앙 서버에 놓고, LAN상에 있는 다른 모든 호스트들이 이 디렉터리를 마운트 할 수 있도록 하자. 이렇게 하면, 사용자는 어떤 호스트로 접속한다고 해도 같은 홈 디렉터리와 파일 환경에 놓이게 된다. 이와 비슷하게, 오직 한 대의 컴퓨터에만 TEX 같은 거대한 양의 디스크 영역이 필요한 어플리케이션을 설치해 놓고, 다른 기계에서 이 디렉터리들을 올릴 수 있도록 할 수 있다. NFS에 대해선 11장에서 다시 자세하게 다룰 것이다. 물론, 이것들은 TCP/IP 네트워크에서 할 수 있는 것중 두 가지 예에 불과하다. TCP/IP 네트워크에서 할 수 있는 것은 거의 무한하다. 자 이제 TCP/IP가 어떻게 동작하는지 좀 더 자세하게 알아보도록 하자. 원리를 알면 컴퓨터를 왜, 그리고 어떻게 설정해야 할 지 이해할 수 있을 것이다. 우선 하드웨어부터 살펴보고 하나씩 위 층으로 올라가자.
EthernetsLAN을 통해서 사용하는 하드웨어 형태중에서 일반적으로 가장 널리 사용하는 것이 이더넷(Ethernet)이다. 이더넷은 커넥터, 탭이나 트랜스 시버를 통하여 그것에 접속하게 되는 하나의 단독 케이블로 이루어져있다. 초당 10M bit를 전송할 수 있는 이더넷이 그다지 비싸지 않기 때문에 상당한 인기를 구가하고 있다. 이더넷에는 세 가지 기본적인 요소 즉, thick, thin 그리고 twisted pair로 이루어져 있다. Thin과 Thick 이더넷는 각각 하나의 동축케이블을 사용하고 있으며. 각각은 대역, 케이블을 호스트를 연결하는 방법 등에 차이가 있다. Thin Ethernet은 꼬인선에 접속되어 있는 T 형 "BNC" 커넥터를 컴퓨터 뒷부분에 있는 플러그에 꽂아 넣는다. Thick Ethernet은 핀을 이용해서 선에 작은 구멍을 뚫고, 거기에 트랜스 시버를 꽂아 넣는다. 여러개의 호스트를 트 랜스 시버에 연결할 수 있다. Thin 과 thick Ethernet 선은 각각 최대 200 또는 500미터까 지 사용할 수 있고, 이것을 10base-2 그리고 10base-5라고 부른다. Twisted pair는 원래 전 화 설치시 찾을 수 있었던, 두 개의 동선으로 이루어진 케이블이다. 그러나 대개 10base-T 라고 알려진 하드웨어가 추가적으로 필요하다. 비록 thick Ethernet에 흐스트를 추가시키는 작업이 약간은 힘들긴 하지만, 그것은 네트워크를 망가뜨리지 않는다. 반면, thinnet 설치시 호스트를 추가하기 위해서는, 최소한 몇분이라도 네트워크 서비스를 중단해야 한다. 왜냐하면, 커넥터에 꽂을 선을 잘라야 하기 때문이다. 대부분의 사람들을 가격이 싸다는 이유로 thin Ethernet을 더 좋아하는 경향이 있다: PC 카드는 적어도 US 달러로 $50정도 되고, 전선은 미터당 2내지 3센트정도이다. 그러나 대용 량 필요로 하는 곳에는 thick Ethernet가 더 적당하다. 예를 들면, GMU의 수학부는 thick Ethernet를 사용한다. 그래서, 네트워크에 호스트를 추가할 때마다 서비스를 중단시키는 일은 없을 것이다. 이더넷 기술의 약점이라고 한다면, 케이블 길이에 제한이 있다는 것이다. 이것이 LAN을 사용할 경우, 방해가 되는 부분이다. 그러나, 여러 이더넷 부분들은 리피터, 브릿지, 또는 라 우터를 사용해서, 서로를 연결할 수 있다. 리피터는 단순히 두 개 이상의 요소들 사이에 있는 신호들을 복사한다. 그래서, 모든 부분들이 하나의 이더넷인 것처럼 행동한다. 필요 조 건이라면, 네트워크에다가 두 개의 호스트에 네 개이상의 호스트를 달순없다. 브리지와 라우터는 더욱더 복잡하게 되어 있다. 이것들은 들어오는 데이터를 분석해서, 로컬 호스트상에 수신 호스트가 없다면, 그것을 앞쪽으로 끄집어 낸다. 이더넷은 하나의 호스트가 같은 이더넷상에 있는 다른 호스트로 최고 1500바이트 패킷 (또는 프레임)을 보내주는 버스 시스템처럼 작동한다. 그 호스트는 이더넷 보드의 펌웨어로 여섯 바이트씩 주소화되어 있다. 이러한 주소들은 대개 두 개의 숫자가 콜론으로 구별되어 여섯 개씩 순차적으로 쓰여져있다. 예를 들어, aa:bb:cc:dd:ee:ff. 프레임은 하나의 스테이션이 마치 접속되어 있는 모든 스테이션처럼 보이게끔 해서 보낸 다. 하지만 목적 호스트는 실제로 스테이션을 찾아내어서 처리한다. 만약 두 개의 스테이션 을 동시에 보내려고 시도했을 때, 발생하는 충돌은 두 개의 스테이션의 보내기를 중지시킴 으로써 그러한 문제가 해결되며, 몇분후에 재시도한다.
Other Types of HardwareGroucho Marx University와 같은 거대한 장소에서, 이더넷는 오직 하나의 형태로 사용되는 것은 아니다. Groucho Marx University에서, LAN의 각 부는 campus backbone으로 연결되 어 있고, 그것은 FDDI (Fiber Distributed Data Interface)를 사용하는 광학섬유전선 이다. FDDI는 전송중인 자료를 완전히 다르게 접근하여 사용한다. 이것은 기본적으로, 여기저기에 보내는 즉 다시말해서, 만약 그것이 토큰을 포착한다면 하나의 스테이션이 단지 프레임을 보내기 위해 허가하게 될 tokens의 수를 포함한다. FDDI의 주요 이점으로는 100Mbps 의 속도를 낼 수 있고, 최대 선길이가 최고 200km까지 가능하다는 것이다. 먼거리의 네트워크을 연결하기 위해, 다른 종류의 기계가 자주 사용되며, 그 기계는 X.25 에 기초를 두고 있다. U.S.에 있는 Tymnet나 독일에 있는 Datex-P와 같은 Public Data N- etwork는 이 서비스를 제공하고 있다. X.25는 즉, Packet Assembler/Disassembler 또는 PAD와 같은 특별한 하드웨어를 필요로 한다. X.25는 네트워킹 프로토콜을 정의함에도 불구 하고, TCP/IP 그리고 다른 프로토콜을 사용하고 있는 네트워크를 접속하기 위해 자주 사용 된다. IP 패킷이 X.25에 정밀하게 표시할 수 없게된 이후에, 그것들은 단순히 X.25에 싸여서 네트워크에 보내지게 된다. 자주, 무선 아마추어들은 네트워크에 접속하기 위해 대개 그들의 컴퓨터를 장비로 사용 한다: 이것은 packet radio 또는 ham radio라 부른다. ham radio에 의해 사용되 는 프로토콜 을 우리는 AX.25라 부른다. 이것은 X.25에서 유래한 것이다. 다른 기술로는 사용자체가 좀 느리지만 값은 싼 다이얼업 엑세스를 위한 시리얼 라인을 포함하고 있다. 이것들은 이직도 패킷을 보내기 위해, SLIP나 PPP와 같은 또 다른 프로토 콜을 필요로 한다. 이것은 아래에 기술되어 있다.
The Internet Protocol물론 여러분의 네트워크를 하나의 이더넷으로 제한하길 원치 않을 것이다. 이상적으로 말하 면, 어떤 하드웨어를 사용하고 있는지 또는 얼마나 많은 서브유니트를 가지고 있는지에 상 관없이 네트워크를 사용하고 싶어할 것이다. 예를 들어, Groucho Marx University와 같은 거대한 장소에서, 여러분은 대개 여러 가지 방법으로 접속해야 하고, 여러개로 분리되어 있 는 이더넷를 가지고 있을 것이다. GMU에서, 수학부는 두 개의 이더넷s을 사용한다: 하나는 교수들이나 졸업생들을 위해 빠른 기계를 사용하는 네트워크와 또 다른 하나는 학생들을 위 해 조금 더 느린 기계를 사용하는 네트워크가 있다. 둘다 FDDI campus backbone에 연결되 어 있다. 이 연결은 이른바 gateway라고 하는 제공된 호스트에 의해 처리된다. 게이트웨이는 두 개의 이더넷과 광학섬유전선 사이에서 그것들을 복사함으로써, 들어오는 패킷과 나가는 패 킷을 처리한다. 예를 들어, 만약 여러분이 Maths Department에 있고, 리눅스 컴퓨터에서 물리학과의 LAN 상에 있는 quark 호스트로 접근하고 싶다면, 네트워킹 소 프트 웨어는 패킷을 quark로 직접 보낼 수 없다. 왜냐하면, 같은 이더넷상에 있는 것이 아 니기 때문이다. 그래서 게이트웨이가 운송업자 역할을 한다. 백본을 사용해서, sophus라 이 름지 어진 게이트웨이는 물리학과에 있는 동급의 게이트웨이인 niels에게 이들 패킷 을 보낸다. niels는 목적 호스트로 패킷을 전달하는 역할을 한다. erdos와 quark의 데이터 흐름도는 그림 1.1에 나와 있다.
그림 1.1: erdos에서 quark으로 자료를 세 단계로 보내는 과정
리모트 호스트로 보내는 자료의 방향을 계획하는 작업을 routing라고 하며, 이러한
관계로
볼 때, 패킷은 대개 datagrams에 적용된다. 이러한 작업을 용이하게 하기 위해, 하드
웨어와
독립적으로 사용되는 단독 프로토콜 즉, IP 또는 Internet Protocol이 자료 교환작업을
제어
한다. 2장에서, IP와 라우팅에 관해 좀 더 상세하게 다룰 것이다.
IP의 주요 잇점으로는 물리적으로 다른 네트워크를 외관상으로 동질의 네트워크로 변화 시켜준다. 이것을 인터네트워킹이라고 하고, 그 결과 발생하는 "meta-network"를 internet이 라 부른다. 여기에서 an internet과 the Internet은 미묘한 차이점이 있다는 것을 주의하라. 물론, IP는 또한 하드웨어를 독립적으로 어드레싱하는 작업이 필요하다. 이러한 작업은 IP 어드레스라고 부른는 하나의 유일무일한 32비트 수를 각 호스트에 할당함으로써 완성된 다. 하나의 IP 어드레스는 대개 네 개의 십진수를 도트문자로 구별해놓고, 각자리에 8비트씩 분배해 놓는다. 예를 들어, quark는 0x954C0C04라는 IP 어드레스를 가지고 있고, 그것은 다시 149.76.12.4로 표현한다. 이러한 형태를 dotted quad notation이라고 부른다. 자 그럼, 여러분은 우리가 세가지 다른 형태의 주소를 가지고 있다고 말할 것이다. 즉, 첫 번째는 quark와 같은 호스트명, 그리고 IP 어드레스, 마지막으로, 6바이트 이더넷 주소와 같은 하드웨어 주소가 있다. 어쨋든간에, 이러한 모든 주소들이 하나같이 일치해야된다. 그 래서, 여러분이 rlogin quark라고 입력하면, 네트워킹 소프트웨어는 quark의 IP 어드레스를 줄 수 있게 된다. 즉, IP가 어떤 자료를 물리학과's 이더넷로 넘겨줄 때, 그것은 어떻게해서 든지 이더넷 어드레스를 IP 어드레스와 일치시켜야 한다. 지금 이점에 대해서 자세하게 논의할 순 없지만, 2장에서 이것을 다루기로 하겠다. 지금 은 hostname resolution이라고 부르는 주소들을 찾는 단계와 호스트 명을 IP 어드레 스와 일치시키는 것, 문자들을 하드웨어 주소로 일치시키는 과정을 기억하는 것만으로도 충분하 다.
IP over Serial Lines사실 시리얼 라인에서, SLIP 또는 Serial Line IP라고 알려진 표준 프로토콜이 자주 쓰인다. CSLIP 또는 compress SLIP는 SLIP을 변형시킨 것이며, 이것은 시리얼 링크에 의해 제공되 는 대역폭을 상대적으로 낮게 사용하기 위해서 IP 헤더를 압축하는 작업을 한다. - SLIP은 RFC 1055에 기술되어 있다. 헤더를 압축하는 작업을 하는 CSLIP는 RFC 1144를 토대로 해서, 기술되어 있다. PPP 또는 Point-to-Point Protocol이라고 하는 또 다른 시리얼 프로토콜이 있다. PPP는 SLIP보다 더 많은 특징을 가지고 있다. SLIP에서는 제공하지 못하는 PPP만의 주요한 이점 으로는 IP 데이터그램을 전송하는 데에 제한이 없다는 것이다. 그것은 전달되는 어떠한 형 태의 데이터그램도 허용할 수 있게끔 제작되어 있다.
The Transmission Control Protocol물론 요즈음에는 하나의 호스트에서 다른 호스트로 자료를 보내는 기능만 있는 것은 아니 다. 만약 여러분이 quark로 접속하고자 한다면, erdos상에 있는 rlogin 프로세스와 quark 상에 있는 쉘 프로세스 사이에 믿을 수 있는 연결을 가지고 싶어할 것이다. 그리하여, 이 정 보가 보내지고 이것은 송신기에 의해 패킷으로 나누어지게 되며, 수신기에 의해 문자 스트림으로 다시 합쳐지게 되는 것이다. 이것이 사소한 것처럼 보이지만 매우 어려운 작업을 수 반하고 있다. IP에 관한 지식이 매우 중요하긴 하지만 그렇게 믿을 수 있는 것은 아니다. 여러분의 E- thernet상에 있는 열 명의 사람이 GMU의 FTP서버로부터 XFree86 최신 배포본을 전송받는 다고 가정하자. 여기서 발생하는 부하량은 실로 엄청날 것이며, 이것을 게이트웨이가 처리할 것이다. 왜냐하면, 전송속도가 매우 느릴 것이고, 메모리의 양이 부족할 지도 모르기 때문이 다. 지금 만약 여러분이 quark로 패킷을 보내고자 한다면, sophus가 잠시동안 버퍼 영역을 벗어날지도 모르기 때문에 그러한 것을 기대하기란 어렵다. IP는 단순하게 그것을 삭제함으 로써 그러한 문제를 해결한다. 그러면 패킷은 사라지며, 그것은 다시 되부를 수도 없다. 데 이터를 보존하고 완성하며, 에러를 찾아내어서 재전송하는 것이 통신 호스트의 주요 임무이 다. 이러한 작업은 아직도 TCP 또는 Transmission Control Protocol이라고 하는 또 다 는 프로토콜에 의해 수행되며, IP의 최상위에서 작업한다. TCP 본질적인 특성이라고 한다면, 여러분의 호스트와 리모트 머신상에 있는 두 개의 프로세스들을 단순히 연결시켜주는 착각 을 일으키게 하기 위해 IP를 사용하는 것이다. 그래서, 여러분은 자료가 어떤 경로롤 거치는 지는 알 필요가 없다. TCP 연결은 본질적으로 읽기도 하고 쓰기도 하는 프로세스 둘 다를 가지고 있는 송수신 파이프와 같이 동작한다. 즉 전화통화를 생각해 보면 된다. TCP는 두 개의 호스트를 수반하고 있는 IP를 거친 연결의 종점과 각 호스트상에 있는 이른바 port 수를 동일하게 간주한다. 포트들은 네트워크 연결을 위한 연결장치 관 점에서 본 것이다. 한가지 예를 들어 만약 여러분이 전화선을 변형시킬 수 있다면, IP 어드레스는 지역 코드 ( 즉, 도시와 연관시킬 수 있는 숫자)와 비교할 수 있고, 포트 번호는 로컬 코드 (즉, 각 개인의 전화와 연관시킬 수 있는 숫자)와 비교할 수 있다. rlogin을 예로 들어 보면, 클라이언트 어플리케이션 (rlogin)은 erdos상에 있는 하나의 포트를 열어주고, quark상에 있는 포트 번호 513에 연결시키며 rlogind 서버가 그 뒤를 따르는 것으로 알려져 있다. 이것으로 TCP 연결을 확립시킨다. 이러한 연결을 사용해서, rlogind가 인증 절차를 수행시키면 쉘이 나타나게 된다. 그 쉘의 표준 입력과 출력을 TCP가 연결되어 있는 곳에 전송시킨다. 그래서 여러분의 기계에서 rlogin라고 입력하게 되면, 이 입력된 신호가 TCP 스트림을 통과하게 될 것이고, 쉘의 표준 입력으로 받아들여지게 되는 것이다.
The User Datagram Protocol물론 TCP가 TCP 네트워킹에서 사용자 프로토콜로써만 존재하는 것은 아니다. 비록 rlogin 과 같은 어플리케이션에 적합한 프로토콜이라 하더라도, 그것에 수반되어 있는 오버헤드는 NFS와 같은 어플리케이션에는 대단히 부적합하다. 대신에, TCP와 유사한 프로토콜인 UDP 또는 User Datagram Protocol을 사용한다. TCP와 같이 UDP 또한 리모트 머신상에 있는 어떤 포트에 서비스를 접속하기 위해 하나의 어플리케이션을 허용하고 있지만, 이것을 위한 연결을 확립해 놓진 않는다. 대신에, 여러분이 단독 패킷을 목적 서비스에 보내기 위해 사용 할 수도 있다. 여러분이 각 부의 중앙 NFS 서버 - galois로부터 계층적으로 TEX 디렉토리에 마운 트 되어 있고, LATEX 사용방법에 대해 기술해 놓은 문서를 보고 싶어한다고 가정하자. 우선 파일 전체를 에디터로 읽어 들여라. 하지만, galois로 TCP 연결을 확립하고, 파일을 보내고, 그것을 다시 배포하는 데에는 너무나도 많은 시간이 걸릴 것이다. 대신에, galois로 만들어 진 하나의 요청 즉, 이것은 한쌍의 UDP 패킷에 있는 파일을 보내는 것이며, 속도면에서 훨 씬 더 빠르다. 하지만 UDP는 손실된 패킷이나 충돌이 일어난 패킷을 보존하지 않는다. 이 러한 경우에 가장 적절한 어플리케이션으로는 NFS가 있으며, 이것은 그러한 패킷들을 보호 해준다.
More on Ports포트는 네트워크 연결을 위한 연결 포인트로 볼 수 있다. 만약 하나의 어플리케이션이 어떤 서비스를 제공하고자 한다면, 그것은 하나의 포트에 그 자체를 연결시키고, 클라이언트를 기 다린다. (이것을 포트에 listening 한다고 부른다.) 이 서비스를 사용하길 원하는 클라 이언트 는 로컬 호스트에 하나의 포트를 할당하고, 리모트 호스트 상에 있는 서버의 포트에 연결시 킨다. 포트의 중요한 특성중에 하나로는 연결이 클라이언트와 서버사이에서 이루어지고, 서버 의 다른 복사본들이 서버 포트에 연결되며, 더욱더 많은 클라이언트를 위해 listen한다. 이를 테면, 이것은 모두다가 같은 포트 513을 사용해서, 같은 호스트에 여러 다른 원격 접속을 동 시에 허가한다. TCP는 이러한 서로를 간에 연결을 확립할 수 있다. 왜냐하면, 그것들이 모 두 다른 호스트나 포트에서 발달한 것이기 때문이다. 예를 들어, 만약 여러분이 erdos 에서 quark로 접속한다면, 첫 번째 rlogin 클라이언트가 로컬 포트 1023을 사용할 것이고, 두 번 째 클라이언트는 포트 1022를 사용할 것이다. 하지만 둘 다는 quark의 포트 513에 연 결될 것이다. 이 예제에서 포트의 사용은 하나의 클라이언트가 특별한 서비스를 얻기 위해서 특별한 포 트를 연결하는 랑데부 포인트로 볼 수 있다. 클라이언트의 순서를 위해 적절한 포트 번호를 식별하기 위해서는, 이러한 번호를 할당할 수 있는 양쪽의 시스템 관리자사이에 그러한 합 의가 이루어져야 한다. rlogin과 같이 널리 사용되는 서비스를 위해, 이러한 번호들은 중점 적으로 관리되어야 한다. 이것은 IETF - Internet Engineering Task Force에 의해 이 루어 지며, 그것은 할당 번호가 붙은 RFC를 정기적으로 배포한다. 이것은 다른 것들 중에 well-known services로 할당된 포트 번호들을 기술한다. 리눅스는 그러한 번호 를 위해 /etc/services라고 부르는 파일 매핑 서비스 명을 사용한다. 그것은 The services and proto cols Files (9.3절)에서 자세하게 기술할 것이다. 비록 TCP 와 UDP 연결이 포트들에 의존하고 있다 하더라도 이들 번호들은 절대 충돌 이 일어나지 않는다. 이 의미는 TCP 포트 513은 UDP 포트 513과 다르다는 것이다. 사실상, 이들 포트들은 두 개의 다른 서비스 즉, rlogin (TCP) 와 rwho (UDP)와 같은 두 개의 다른 서비스를 엑세스 포인트로 제공한다.
The Socket LibraryUNIX 운영 체제에서, 모든 작업과 위에서 기술한 프로토콜을 수행하는 소프트웨어는 대개 리눅스에서와 같이 커널의 일부분이다. UNIX 세계에서 가장 일반적으로 사용하는 프로그 래밍 인터페이스는 Berkeley Socket Library이다. 그것의 이름은 소켓을 포트로 보고 플러 그를 꽂아 접속하는 것과 같이 포트를 연결한다는 유추에서 유래한 것이다. 그것은 리모트 호스트와 전송 프로토콜 그리고 서비스를 명시하기 위해 (bind(2)) 호출을 사용한다. 이것으 로 인해 프로그램은 (using connect(2), listen(2), 그리고 accept(2))를 연결하거나 들을 수 있다. 소켓 라이브러리가 다소 보편적이기는 하지만, 그것은 소켓 (AF_INET 소켓)을 기본 으로 하는 TCP/IP 클래스 뿐만아니라 연결 지역을 기계 (AF_UNIX 클래스)로 조종하는 클래스를 제공한다. 몇몇 실행으로 XNS (Xerox Networking System) 프로토콜 또는 X.25 와 같은 또 다른 클래스 또 한 처리할 수 있다. 리눅스에서, 소켓 라이브러리는 표준 libc C 라이브러리의 일부분이다. 현재, 그것은 AF_INET와 AF_UNIX 소켓만을 지원하지만, Novell의 네트워킹 프로토콜 지 원을 통합시 키는 노력으로 인해, 마침내 하나 이상의 소켓 클래스를 통합시킬 수 있게 되었다.
1.4 Linux Networking리눅스는 전세계의 프로그래머들이 이루어낸 노력의 결과이며, 전세계 네트워크 없이는 가 능하지 못했다. 이미 초기 단계에서 여러 사람들이 네트워크 호환 작업을 이루어낸 것도 과 히 놀랄만한 것도 아니다. 이미 초기 단계에서 UUCP를 리눅스 상에서 실행에 옮겼으며, 1992년 가을에 Ross Biro와 다른 사람들이 TCP/IP를 기초로한 네트워킹을 시작하였고, 그 것은 Net-1으로 알려지게 되었다. 1993년 Ross가 개발 활동을 중단한 이후, Fred van Kempen이 새롭게 작업에 착수하기 시작하였고, 그러한 노력으로, Net-2를 만들어 내게 되었다. 1992년 여름에 첫 공식 배포본 인 Net-2d를 만들어 냈다. (이것은 0.99.10 커널의 일부분이다.) 그리고 여러 사람들 중에서 Alan Cox가 Net-2Debugged를 유지하고 실험하고 있었다. 심각한 버그를 수정하고, 코드에 여러 가지 수정작업이 이루어진 이후로, 그 이름이 Net-3으로 바뀜으로써 드디어 Linux 1.0 을 배포하기에 이르렀다. 현재에는 여러 가지 네트워킹 코드가 공식 커널 배포본에 포함되 어 있다. Net-3는 가장 광범위하게 변화하는 이더넷 보드 뿐만아니라, SLIP (시리얼 라인을 통해 네트워크 전송), 그리고 PLIP (패러랠 라인을 통해 네트워크 전송)을 위한 장치 드라이버를 제공한다. 랜 환경에서 가장 잘 동작하는 TCP/IP 구현을 가지고 있는 리눅스는 Net-3와 함 께 상업용 PC 유닉스를 능가하는 동작 가능 시간을 보여주고 있다. 현재 개발하고 있는 취 지는 인터넷 호스트 상에서 안정성있게 리눅스를 실행하는 것을 목표로 두고 활동하고 있 다. 이러한 작업을 더욱 용이하게 해주는 것으로써, 여러 가지 프로젝트가 추진중에 있으며, 리눅스의 융통성을 강화하는 데에 큰 몫을 해줄 것이다. PPP (Point-to-Point Protocol, 시 리얼 라인을 통해서 네트워크 전송을 하는 또 다른 방법)를 위한 드라이버가 현재 베타 단 계에 있으며, ham radio를 위한 AX.25 드라이버는 알파 단계에 와 있다. Alan Cox는 또한 Novell의 IPX 프로토콜을 위한 드라이버를 구현하고 있지만, 완전한 네트워킹을 위해 적합 한 호환성을 가지기 위한 노력으로 인해, Novell의 IPX 프로토콜 개발은 잠시 동안 주춤하 고 있다. 왜냐하면, 필요한 문서를 Novell 측에서 마지못해 제공해 주었기 때문이다. 장래가 유망한 또 다른 사업으로는, 유닉스를 위한 NetBIOS 서버인 samba가 있었으며, Andrew Tridgell에 의해 만들어 지고 있다.- NetBIOS는 lanmanager와 작업그룹들을 토대로 동작하는 Windows와 같이 어플리케이션상에 있는 프로토콜이다.
Different Streaks of Development그 동안에, Fred는 Net-2e의 개발 작업을 계속 진행하였으며, 더욱 더 개선된 네트워킹 계 층을 제작했다. 이 글을 쓰고 있는 현 시점에서, Net-2e는 여전히 베타 소프트웨어였다. Net-2e의 가장 주목할 만한 점이라면, DDI,Device Driver Interface를 합병한 것이 었다. DDI는 항상 동일한 엑세스와 모든 네트워킹 장치와 프로토콜을 위한 구성법을 제공하였다. Linux와 FreeBSD를 위한 ISDN을 만들어낸 Matthias Urlichs는 또 다른 TCP/IP 네트워킹 을 구현하였다. 이 작업을 위해 그는 몇몇 BSD 네트워킹 코드를 Linux 커널에 집적시켰다. 그러나 미래를 예견할 수 있었다 하지만 Net-3는 그대로 머물러 있었다. 현재 Alan은 ham radio amateurs를 사용하는 AX.25 프로토콜의 구현 작업을 하고 있다. 의심할 여지 없 이 커널을 위해 "module"이라는 코드를 개발하여 네트워킹 코드에 새로운 활력을 불어 넣 어 주었다. Modules은 여러분이 커널 실행시간에 드라이버를 추가할 수 있게끔 해준다. 네트워크를 구현하는 방법이 다르다 할지라도 모든 사람들은 같은 서비스를 제공하기 위 해 노력했다. 그래도 커널과 장치 레벨 사이에 주요한 차이점은 있었다. 그래서, 여러분들은 Net-2d 또는 Net-3, 그리고 vice versa로부터 유틸리티를 가지는 Net-2e 커널을 동작시키 는 시스템을 구성할 수는 없을 것이다. 이것은 단지 커널 내부를 다루는 명령을 제공해 줄 뿐이며, 오히려 어플리케이션이나 rlogin 또는 telnet과 같은 일반적인 네트워킹 명령에 더욱 더 가깝다. 그렇지만, 이러한 모든 네트워크 버전의 차이점이 여러분을 걱정시킬만큼의 문제거리는 아니다. 여러분이 개발 활동에 참여하지 않더라도, 여러분이 사용하는 TCP/IP 코드에 대해 걱정할 필요는 없는 것이다. 공식 커널 배포는 항상 커널에서 표현하는 네트워킹 코드와 호 환하는 네트워킹 도구집을 수반할 것이다.
Where to Get the Code리눅스 네트워크 코드의 최신 버전은 anonymous FTP를 사용하는 여러 사이트에서 구할 수 있다. Net3를 위한 공식 FTP 사이트는 sun.site.unc.edu 사이트의 system/Network/sunacm에 미러되어 있는 sunacm.swan.ac.uk이다. Net-2e의 최신 패치 키트와 바이너리들은 ftp.aris.com에서 찾아볼 수 있다. Matthias Urlichs' BSD-derived 네트워킹 코드는 ftp.ira.uka.de의 /pub/system/linux/netbsd방에서 구할 수 있다. 최신 커널은 uic.funet.fi의/pub/OS/Linux/PEOPLE/Linux에서 찾아 볼 수 있다.; sunsite와 tsx-11.mit.edu사이트가 이 디렉토리를 미러시켜 놓았다.
1.5 Maintaining Your System이 책을 통해서, 우리는 주로 설치와 구성에 관한 개관을 다룰 것이며, 특히 관리면을 집중 적으로 다룰 것이다. - 서비스를 셋팅한 후에, 여러분은 실행작업 역시 유지시켜 줘야 한다. 그러면 여러분에겐 mail과 news와 같은 서비스도 필요하게 될것이며, 여러분의 시스템을 최신식으로 유지하기 위해 루틴 작업도 해줄 필요가 있게 된다. 다음 장에서 이러한 작업에 관해 자세하게 다루어 보자. 에러 상태나 예상치 못한 일들을 대비하여 어플리케이션 로그 파일과 시스템을 검사하는 일은 시스템을 유지시키기 위한 최소한의 작업이다. 일반적으로, 여러분은 대개, 이러한 작 업을 하기 위해, 한 쌍의 관리 쉘 스크립트를 작성해서, 이것들을 cron 항목에 넣어 두고 정 기적으로 실행하고 싶어할 것이다. smail 과 C News와 같은 몇몇 주요한 어 플리케이션의 소스 배포에 있어서는 그런 스크립트를 포함시키고 있다. 여러분이 필요한 것이 무어인지, 더 좋아하는 것이 무엇인지 파악해서, 스크립트를 작성해야 한다. cron 작업에서 얻어지는 출력은 관리 계정으로 우송된다. 많은 어플리케이션들은 에러 보고서, 사용량 또는 root 계정으로 요약하는 로그파일을 보낼 것이다. 만약 여러분이 root 계정으로 자주 로그인 한다면, 이것은 대단히 민감해질 것이다. ; 여러분의 개인 계정으로 root의 메일을 전송하기 위해서는 14장에서도 언급하게될 mail alias를 설정하는 것도 좋은 방법이 될 것이다. 하지만 여러분은 여러분의 사이트를 주의깊게 설정해야 한다. Murphy's law는 표면화되 는 몇몇 문제들을 보증해준다. 그러므로, 시스템을 유지시킨다는 것은 그러한 불평거리를 쓸 모 있게 만든다는 의미이다. 대개 사람들은 시스템 관리자가 적어도 root 계정을 사용해서, email을 통해 접근한다고 예상하고 있지만, 관리 측면에서 확실하게 책임을 져야할 사람들 이 접근하기 위해 일반적으로 사용하는 또 다른 주소가 있다. 이를테면, 작동불능 상태의 메 일 구성에 대해 불평하는 것은 대개 postmaster로 주소화 되어 있다. ; news 시스템 에 관 한 문제거리들은 newsmaster 이나 usenet으로 보고가 될지도 모른다. hostmaster 로 발송되는 메일은 호스트의 기본 네트워크 서비스와 만약 여러분이 네임 서버를 실행하 고 있다면, DNS 네임 서비스를 담당하고 있는 사람에게 재전송되어야 한다.
System Security네트워크 환경에 있어서 시스템 관리 측면의 또 다른 중요한 작업으로는 침입자로부터 여러 분의 시스템과 사용자를 보호하는 것이다. 부주의하게 시스템을 관리하는 것은 고의적으로 사람들에게 표적을 제공하는 것과 마찬가지이다. ; 패스워드를 추측하는 것에서부터 Ethern et을 기웃거리는 일은 공격 범위를 줄여주는 결과를 초래할 것이며, 날조된 메일 메시지에 서 데이터 손실까지 또는 사용자의 사생활 침해와 같은 문제를 일으키게 된다. 우리는 그것 들이 발생할 수도 있는 배경을 논의하면서, 그러한 특별한 문제에 관해 해결방안을 모색할 것이다. 이 절에서는 시스템 보안을 다루는 기본적인 기술과 그에 따른 예를 들어 보일 것이다. 물론, 이 화제들로 여러분이 직면하게 될 모든 보안 문제들을 다룰수는 없다. ; 단지 일어날 수 있는 문제들을 다룰뿐이다. 그래서, 보안에 관련되어 있는 좋은 책을 읽는 것 또한 중요 하며, 그것이 시스템을 네트워크에 올려놓기 위해선 필수적이다. Simon Garfinkel의 "Practical UNIX Security" ([Spaf93]을 참조하라.) 는 상당히 추천할 만 한 책이다. 시스템 보안은 좋은 시스템을 관리하기위해 시작되었다. 이것은 중요한 모든 파일과 디 렉토리의 소유권과 허가권을 검사하고, 특별하게 사용하는 계정의 상태를 확인하는 작업도 포함하고 있다. 이를테면, COPS 프로그램은 보기드문 허가 또는 다른 예외적인 상황들을 위해, 파일시스템과 일반적인 구성 파일들을 검사할 것이다. 그리고 사용자의 패스워드를 어 떤 특별한 규칙에 따라 추측하기 힘들게 만드는 것도 현명한 방법이다. 이를테면, 쉐도우 패 스워드는 적어도 다섯 개의 문자를 가지는 패스워드를 필요로 한다. 그 패스워드에는 대소 문자와 번호를 포함하고 있다.
2. Issues of TCP/IP Networking이 장에서는 여러분의 리눅스 머신을 TCP/IP 네트워크로 연결할 때, 부딪치게 될 세부사 항들과 IP 어드레스, 호스트 네임, 라우팅의 유래에 관해 알아본다. 그리고, 필요한 설정작업을 이 해하기 위해서 알아야 되는 기본적인 개념들과, 이러한 설정작업에 필요한 도구들을 다루어 보기로 하자.
2.1 Networking Interfaces네트워킹 환경에서 사용되는 설비의 다양성을 감추기 위해서, TCP/IP는 하드웨어를 제어하 기 위 한 하나의 추상적인 interface를 정의해 두고 있다. 이 인터페이스는 한 쌍의 연산자를 제공한다. 그리고, 그것은 모든 종류의 하드웨어를 같은 형태로 두고, 패킷을 보내고 받는 작업을 한 다. 네트워크에 사용되는 각 주변장치들은 그에 해당하는 인터페이스가 커널에 표시되어 있어 야 한다. 예를 들어, 리눅스에서 사용하는 Ethernet 인터페이스는 eth0 그리고, eth1 로 표시되어 있고, SLIP 인터페이스는 sl0, sl1 등등으로 표시되어 있다. 이들 인터페이스의 이름은 여러분이 커널에 특별한 물리적인 장치의 이름을 매기고 싶을 때, 구성 목적으로 사용한다. 그것들이 꼭 특별한 의미를 가지고 있는 것은 아니다. TCP/IP 네트워킹을 사용 가능하게 하기 위해서, 하나의 IP 어드레스에 하나의 인터페이스 를 할당해야 한다. IP 어드레스는 전세계에서 통신을 할 경우, 자신의 신분을 밝혀주는 유일한 수단 이 된다. 이 어드레스는 위에서 언급한 인터페이스의 이름과는 다르다. ; 만약 여러분이 인 터페이 스를 문에 비유한다면, 어드레스는 그 문에 붙어 있는 문패와 같다. 여러분이 설정해야 하는 또 다른 장치 인수들이 있다. 이것들중 하나로써 데이터 그램의 최 대 크기를 설정하는 부분이 있다. 이것으로 하드웨어의 특별한 부분들을 처리할 수 있다. 이것을 MTU 또는 Maximum Transfer Unit라고 부른다. 다른 속성들은 다음에 소개하기로 하자.
2.2 IP Addresses1 장에서 언급한대로, IP 네트워킹 프로토콜이 이해할 수 있는 어드레스수는 32비트이다. 네트워 킹 환경에 있는 모든 기계들은 이 수의 범위내에서 할당할 수 있다. 만약 여러분이 다른 네트워 크와의 TCP/IP 교환이 이루어지지 않는 일반적인 지역 네트워크를 운영하고 있다면, 여 러분의 개인 취향에 따라 이들 번호들을 할당할 수 있을 것이다. 그러나, 인터넷에 있는 모든 사이 트들은 중앙기관 즉, NIC - Network Information Center - 대개, 프로바이더들이 여러분에게 IP address를 할당하며, 여러분은 그것을 사야한다. 또는 여러분들이 원하는 IP address를 직접 NIC에 연락해서 구할 수도 있다. 연락 주소는 다음과 같다. hostmaster@internic.net에 의해 그 번호들을 할당 받을 것이다. IP address를 쉽게 읽기 위해서, octet라고 부르는 네 개의 8비트 수로 나누어 놓았다. 예를 들 어, 0x954C0C04의 IP address를 가지는 quark.physics.groucho.edu는 실제로 149.76.12.4로 쓰여져 있다. 이러한 형태를 dotted quad notation이라 부른다. 이 표기법을 쓰는 또 다른 이유로써, IP address는 맨 앞쪽 옥텟을 network 숫자로, 나머지 부 분을 host 숫자로 구분해 놓고 있다. 여러분이 NIC에게 IP address를 요청할 때, 여러분이 계획한 대로 할당해 주진 않는다. 대신에, 여러분이 하나의 네트워크 숫자를 받았다면, 그 네트워크 범위 내에서 여러분의 선호도에 따라, 모든 유효한 IP address를 할당할 수는 있다. 호스트 부분은 네트워크 규모에 의존하기 때문에 더욱더 작아지거나, 크게될 필요가 있다. 그 러한 여러 가지 필요성을 충족시켜주기 위해 네트워크에도 여러 클래스가 있으며, 이것은 또 다 른 관점에서 IP address를 분할해 놓고 있다.
1장에서 보인 것을 예로 든다면,quark의 주소인 149.76.12.4는 Class B에 해당하 는 네트워크 149.76.0.0는 호스트 12.4를 가진다고 말할 수 있다. 위애서 보인 글에서 여러분은 호스트 부분에 있는 각 옥텟이 가능한 모든 값들을 허용하지 않 는다는 사실을 어쩌면 알아차렸을 지도 모른다. 왜냐하면, 모든 0과, 모든 255를 가지는 호스트 숫자들은 특별한 목적을 위해 이미 예약되어 있기 때문이다. 모든 호스트 부분에 있는 주소 비트 들이 0인것은 네트워크를 나타내고, 그 부분이 1인 것은 브로드캐스트 주소라고 부르고, 이것은 네트워크에 명시되어 있는 모든 호스트를 나타낸다. 그래서, 149.76.255.255는 사용할 수 있는 호스트 주소가 아니라, 네트워크 149.76.0.0에 있는 모든 호스트를 나타낸다. 특별히 예약되어 있는 두 개의 네트워크 주소 즉, 0.0.0.0과 127.0.0.0가 있다. 첫 번째 주소는 다른 말로 default route라고 부르고, 그 다음 것은 loopback address라고 부른다. 디폴트 라우트는 IP의 경로 배정 방법에 관한 정보를 포함하고 있으며, 그 내용은 다음에 설명할 것이다. Network 127.0.0.0 is reserved for IP traffic local to your host.
2.3 Address Resolution이제까지 여러분은 IP address가 어떻게 만들어지는지 보아왔다. 여러분은 그것들이 각각 다른 호스트에 있는 Ethernet상에서 어떻게 사용되는지 궁금할지도 모른다. 결국, Ethernet 프로 토콜은 여섯 개의 옥텟숫자로 호스트를 증명하는데, 그것은 일반적인 하나의 IP address를 가지는 것은 아니다. 그렇지 않은가? 그렇다. 그것은 Ethernet address위에 IP address를 대응시키기 위한 메카니즘이 필요한 이 유 이다. 이것을 다른말로, Address Resolution Protocol 또는 ARP라고 부른다. ARP는 Ethernet를 전혀 제한하지는 않지만, ham radio와 같은 또 다른 형태의 네트워크에서도 사용된다. ARP 에 기 초를 두고 있는 생각으로서, 150여명의 군중속에서 Mr. X. Ample를 찾아야 할 때, 대부분 의 사람 들은 어떻게 할까? ; 주위를 둘러 보면서 그의 이름을 부르면, 그가 대답할 것이다. ARP가 주어진 IP address와 일치하는 Ethernet address를 찾고자 할 때, Ethernet의 특징중 의 하나인 "브로드캐스팅"을 사용한다. 그것은 네트워크에 있는 모든 지역에 자료를 동시에 보내는 형태이다. ARP가 보내는 브로드캐스트 자료는 IP address를 위한 하나의 질의를 포함하고 있다. 그 자료를 받는 각 호스트는 그 자체의 IP address와 그것을 비교해서, 만약 그것이 일치 한다면, 조회중인 호스트는 그 대답을 ARP로 보낸다. 그 조회중인 호스트는 대답을 보낼 송신자의 Ether net address를 알아낼 수 있다. 물론 여러분은 전세계에 퍼져 있는 무수히 많는 Ethernet을 그 호스트가 어떻게 찾을지, 또 왜 꼭 Ethernet이어야 하는지 궁금할 것이다. 이러한 질문속에는 라우팅이라는 것이 무엇인지 도 포함 하게 된다. 즉, 라우팅은 네트워크에 있는 호스트의 물리적인 위치를 알아내는 것이다. 이것 에 대 해서는 다음 절에서 자세하게 다룰 것이다. 잠깐동안, ARP에 관한 이야기는 접어두기로 하자. 한때, 호스트가 Ethernet address를 발견 해 서, 그것을 ARP 캐쉬에 저장했다. 그래서, 다음번에 자료를 호스트로 보내고자 할 경우, 그것을 위한 질의는 가지고 있지 않았다. 아무리 그러하더라도, 이 정보를 영원히 보존하고자 하는 생각 은 현명하지 못한 것이다. 이를테면, 기술적인 문제로 인해 리모트 호스트의 Ethernet 카드 를 대 신할 수도 있다. 그래서, ARP는 그다지 쓸모가 없게 되었다. IP address를 위한 또 다른 질의를 추출해내기 위해서, ARP 캐쉬에 있는 개체들을 언젠가는 버리게 된다. 때때로, 주어진 Ethernet address와 관련되어 있는 IP address를 발견하는 것도 필요하다.
이
것은 디스트없는 기계가 네트워크에 있는 서버로부터 부트하고자 할 경우에 발생한다. 랜
에서는
이러한 현상이 결코 드물지만은 않다. 그러나 디스트없는 클라이언트는 가상적으로 그 자체
에 관
한 어떠한 정보도 가지고 있지 않다. - Ethernet address를 제외하고!
2.4 IP Routing
IP Networks여러분이 누군가에게 편지를 보낼 때, 대개 여러분은 우편봉투에 국가, 시(군), 우편번호 등 등, 완 벽한 주소를 기입할 것이다. 여러분이 그것을 우편함에 넣으면, 우편업무를 하는 우체부 아 저씨가 그것을 목적 주소로 가져갈 것이다; 그것은 핀지봉투에 명시되어 있는 국가 또는 시(군)으 로 보내 질 것이다. 그러면, 그곳에 있는 우체국에서는 그 편지를 목적지로 보낼 것이다. 계층적 구성은 오히려 분명하다; 여러분이 편지나 소포를 어디에서 부치던간에, 그 지역 우체국장은 그 편지(소 포)가 가야할 곳을 대략 알 것이다. 그러나, 그 편지가 목적주소로 어떻게 가는지는 알 필요 가 없 을 것이다. IP 네트워크도 이와 유사한 형태로 되어있다. 전체 인터넷은 automonous systems라 고 불리우 는 몇 개의 네트워크로 이루어져 있다. 각 시스템은 내부적으로 각 구성 호스트사이에서 라우팅 을 수행한다. 그래서, 목적 호스트의 네트워크으로 가는 경로를 발견함으로써, 데이터그램을 운반 하는 작업의 양을 줄일 수 있다. 이것은 데이터 그램이 특별한 네트워크에 있는 어떤 호 스트로 옮겨지자 마자, 오로지 네트워크 그 자체에 의해서, 그것을 처리한다는 의미를 담고 있다.
Subnetworks위에서 설명한 것과 같이, IP address를 호스트 부분과 네트워크 부분으로 나눔으로써, 이 구조를 나타낼 수 있다. 목적 네트워크는 IP address의 네트워크 부분에서 유래한 것이다. 그래서, 동일 한 IP 네트워크 번호를 가진 호스트들은 같은 네트워크에서 발견된다. - Autonomous 시스템들 이 조금더 일반적이다. 그것들은 여러개의 IP 네트워크를 포함할 지도 모른다. 그것이 수백개의 더욱더 작은 네트워크 집합과 Ethernet와 같은 물리적인 네트워크로 이루 어 진 가장 작은단위들로 이루어진 후로는, 네트워크에서 inside라고 하는 유사한 스키마 를 제공하는 것도 이치에 맞는 말이다. 그러므로, IP는 하나의 IP 네트워크로 세분화되고, 그것이 여러개의 subnet으로 나누어진다. IP 네트워크 부분에서 특정 IP address 범위로 데이터 그램을 배달하는 일을 하나의 IP 서 브 넷이 맡고 있다. 클래스 A, B, 또는 C와 같이 그것도 IP address의 네트워크 부분으로 화 인되었 다. 그러나 요즘에는 호스트 부분에 몇 비트를 포함시킴으로써, 네트워크 부분을 확장시킨 다. 서 브넷 번호로 해석되는 비트들의 번호는 subnet mask 또는 netmask에 의해 주 어진다. 이것은 32 비트로 이루어진 숫자들이며, IP address의 네트워크 부분을 위한 비트 마스크를 표시한다.
Figure 2.1: Subnetting a class B network
그러한 네트워크의 한 예로써, Groucho Marx University의 네트워크를 들 수 있다. 그것은
클
래스 B에 해당하는 네트워크 번호 149.76.0.0을 가지며, 그것의 넷 마스트는
255.255.0.0이 된다.
내부적으로 GMU 대학의 네트워크는 여러개의 작은 네트워크로 이루어져 있다. 그래서, IP 주 소의 범위가 254개의 서브넷 즉, 149.76.1.0에서 149.76.254.0으로 분해되었다. 예를 들어, Theoretical Physics 부는 149.76.12.0으로 할당되었다. 그리고 campus backbone은 그자체의 네트워크를 가지며, 149.76.1.0을 할당받았다. 이러한 서브넷들은 같은 IP 네트워크 번호를 공유하고 있다. 반면에 세 번째 옥텟은 그것들 사이에서 구분되어 사용된다. 그리하여 그것들은 255.255.255.0이라는 하나의 서브넷 마스크를 사용할 것이다. 그림 2.1은 quark의 주소인 149.76.12.4가 어떤 식으로 해석되는지를 보여준다. 그 주소가 어떻게 클래스 B 네트워크에 속하게 되는지 또, 어떻게 서브네팅을 사용하는지도 보여준다. 서브네팅 (기술적인 용어로 서브넷을 이렇게도 부른다.)이 오직 네트워크에서 internal division 으로서만 가치있는 것은 아니다. 보통 네트워크 관리자가 이 서브넷을 관리하게 되는데, 대 개 현 존하는 경계를 나타내기 위해 서브넷을 만든다. 그것들은 물리적 (두개의 Ethernet 사이에 서)이고, 관리적 (두 department사이에서) 이며, 또한 지리적이며, 이러한 서브넷들을 능가하는 권한 이 몇 몇 사람들에게 주어진다. 하지만 이 구조는 오직 네트워크의 내부적인 활동에 영향을 미칠 수 있 으며, 바깥 세계에서는 그 모습이 나타나지 않는다.
Gateways서브넷팅을 함으로써, 관리상의 이점만을 얻는 것은 아니다. 그것은 자주 하드웨어 한계의 중요성 을 우리에게 인식시켜 주기도 한다. Ethernet와 같이 물리적인 네트워크에 있는 호스트 관 점에서 본다면, 매우 제한되어 있다. 그 제한사항이라는 것은 직접적으로 통신할 수 있는 호스트는 오직 해당 네트워크상에 있어야 한다는 점이다. 다른 모든 호스트들은 gateways라는 것을 통해 서 연결 될 수 있다. 게이트웨이는 두 개이상의 물리적인 네트워크에 동시에 연결되어 있는 하나의 호스 트이다. 그리고 그것은 그것들 사이에서 패킷을 교환하는 작업을 구성해 준다. 만약 호스트가 논리적인 물리 네트워크에 있다면, IP를 쉽게 인식시키기 위해서, 다른 물리 적 네트워크는 또 다른 IP 네트워크에 속해 있어야 한다. 예를 들어, 네트워크 번호 149.76.4.0이 mathematics LAN에 있는 호스트로 예약되어 있는 경우, 그 데이터 그램 을 quark로 보내고자 할 때, erdos상에 있는 네트워크 소프트웨어는 즉시 IP address, 149.76.12.4를 나타내어 준다. 그리고, 그 자료는 게이트웨이 (초기값으로는 sophus로 되어 있다.)를 거쳐서, 목적 호스트에 도착할 것이다. sophus 그 자체는 두 개의 전혀 다른 서브넷에 연결되어 있다. : 수학과, 그리고 campus backbone. 그것은 eth0와 fddi0라고 하는 각각 다른 인터페이스를 거쳐서 접근한다. 지금 현재, 우리가 할당할 IP address는 무엇일 까? 그리고 서브넷 149.76.1.0 또는 149.76.1.4 중에 어디에 그것을 할당해 주어야 할 까? 답은 둘다이다. Maths LAN에 있는 호스트와 통신을 하고자 할 때, sophus는 IP address 149.76.4.1를 사용해야 하고, 백본에 있는 호스트와 통신을 하고자 할 경우에는 149.76.1.4를 사용해야 한다. 그리하여, 게이트웨이는 네트워크당 하나의 IP address를 할당받는다. 이러한 address들은 각 해당하는 인터페이스와 일치되어 있으며, 게이트웨이를 거쳐서, 서브넷에 연결된다. 다음 표에서 는 sophus에서 일치하는 인터페이스와 어드레스를 보여주고 있다. 마지막에 보이는 개체는 루프백 인터페이스인 lo이다. 이것은 2.2절에서 소개가 되었 다. 그림 2.2는 Groucho Marx University (GMU)에 있는 네트워크 토폴로지의 단면을 보여주고 있다. 두 개의 서브넷에 있는 호스트들은 양쪽으로 물려있는 address를 보여주고 있다.
Figure 2.2: A part of the net topology at Groucho Marx Univ.
일반적으로, 여러분은 호스트나 인터페이스에 어드레스를 추가시키는 방법의 차이점에 대해 서 는 무시해 버려도 상관없다. erdos와 같이 하나의 네트워크에 있는 호스트들을 위해 서, i 엄밀히 말해 여러분은 이곳저곳의 IP address를 가지고 있는 호스트를 조회해 볼 것이다. 하지만, 여러분이 게이트웨이를 참조할 때, 이 차이점이 매우 중요한 작용을 할 수도 있다.
The Routing Table여기서는 데이터 그램을 리모트 네트워크로 넘겨줄 때, 어떻게 IP가 사용할 게이트웨이를 선택하 는지에 초점을 맞출 것이다. quark로 데이터 그램을 보내줄 때, erdos는 목적 주소를 검사하고, 지역 네트워크 에 그것이 실제로 존재하는지를 확인하였다. 이 작업과 erdos가 디폴트 게이트웨이인 sophus로 자료를 보내는 작업은 같은 맥락이라고 볼 수 있다. sophus는 quark가 어떤 네트워크와도 직접적으로 연결되어 있지 않다는 것을 인식한다. 그래서, sophus 는 다음에 거치게 될 다른 게이트웨이를 찾아내게 될 것이다. 정확하게 선택했다면, 그것은 물리학과로 가는 게이트웨이인 niels일 것이다. sophus는 적합한 게이트웨이를 가진 목적 네트워크와 교신하기 위한 몇몇 정보를 필요로 하게 된다. 이것을 사용하는 라우팅 정보 IP는 기본적으로 게이트웨이에 연결되어 있는 네트워크 테이 블 을 의미한다. 일반적으로 다목적용 개체를 제공해야 하며, 이것은 네트워크 0.0.0.0과 관련되어 있는 게이트웨이이다. 알려지지 않은 네트워크로 모든 패킷들은 디폴트 라우트를 거쳐서 보내지게 된다. sophus상에서, 이 테이블은 다음과 같이 보일 것이다. sophus가 직접적으로 연결되어 있는 네트워크에서의 라우트는 게이트웨이를 필요로 하지 않 는다. 이러한 경우의 게이트웨이 개체는 "-"로 표시되어 있다. 라우팅 테이블은 여러 가지 의미로 해석할 수 있다. 규모가 작은 LAN을 위해서는 부트시간 때 에 수동으로 route 명령어를 입력해서 그것들을 IP로 피드백하고, 구성하는 것이 가장 효과 적이 다. (5장을 참조하라). 이것보다 조금 더 큰 네트워크를 위해서는 실행시간에 routing daemons를 조절해 주어야 한다. 이것들은 네트워크의 중앙 호스트에서 실행되며, 네트워크 사이에서 최적의 라우트를 설정해 주기 위해서 라우팅 정보를 교환할 것이다. 네트워크의 규모에 의존하는 또 다른 라우팅 프로토콜을 사용할 것이다. Groucho Marx campus와 같은 자발적인 시스템에서 라우팅을 하기 위해서는 internal routing protocols을 사용 한다. 가장 두드러지게 사용하는 것중 하나가 바로 RIP, Routing Information Protocol 이며, 그것은 BSD routed 데몬에 의해 실행된다. 자발적인 시스템에서 라우팅을 하기 위해서는 EGP (Ext ernal Gateway Protocol) 또는 BGP (Border Gateway Protocol) 과 같은 external routing protocols를 사용해야 한다. RIP 뿐만 아니라 이러한 것들도 Cornell's 대학의 gated 데몬에 의해 실행되고 있다. - 많은 사람들이 routed가 불안정하다고 생 각한다. gated가 RIP를 지원하는 이후로는 routed대신에 gated를 사용하는 편이 더 낫다.
Metric ValuesRIP를 기본으로 하고 있는 동적 라우팅은 어떤 목적 호스트나 "hops" 번호에 기초를 두고 있는 네트워크를 위해 최고의 라우트를 선택한다. 그리고 데이터 그램은 도착하기 전에 게이트 웨이를 거쳐야 한다. 단거리 라우트는 RIP보다 전송률이 더 좋다. 16이상의 홉(라우팅 경로에서 차 지하는 하나의 포지션)을 거치는 장거리 라우트는 쓸모 없는 것으로 간주되며, 폐기 처리된다. 다시 말해 서 접속이 안된다는 의미이다. 여러분의 지역 네트워크에 있는 라우팅 정보를 관리하고, RIP를 사용하기 위해서는 모든 호 스 트에 gated를 실행시켜야 한다. 부트시간에 gated는 네트워크 인터페이스에서 일어나는 모 든 활 들을 검사한다. 활동하고 있는 인터페이스가 하나 이상이라면 (여기서 루프백 인터페이스는 계산 하지 않는다.) 호스트가 여러 네트워크 사이에서 패킷들과 라우팅 정보를 활발히 교환하고 제공한 다고 말할 수 있다. 그렇지 않다면, 즉 다시말해 활동하고 있는 인터페이스가 없다면, RIP에 관한 최신 정보를 받거나 지역 라우팅 테이블을 갱신하는 작업이 소극적으로 이루어지고 있다고 말할 수 있다. 지역 라우팅 테이블로부터 정보를 제공할 때, gated는 라우팅 테이블 엔트리와 관련되어 있 는 metric value 로 라우트 길이를 계산한다. 라우트를 구성할 때, 시스템 관리자가 이 미터값 을 계 산하며, 이 라우트를 사용하는 실제 비용을 곰곰히 생각해 보아야 한다. 그러므로 호스트와 직접 적으로 연결되어 있는 서브넷의 미터값은 항상 0이 되어야 한다. 반면에, 두 개의 게이트웨 이를 거치는 하나의 라우트는 미터값이 두자리가 되어야 한다. 하지만, 여러분이 RIP나 gated를 사용 하지 않을 때는 미터값에 대해서 걱정하지 않아도 된다.
2.5 The Internet Control Message ProtocolIP는 우리가 아직 언급하지 못한 companion protocol을 가지고 있다. 이것은 다름아닌 Internet Control Message Protocol (ICMP) 이며, 다른 호스트와의 메시지 교류시 발생하는 에러를 교환하기 위해 커널 네트워킹 코드를 사용한다. 이를테면, 여러분이 현재 erdos상에 있고, quark에 있는 12345 포트로 원격 접속하고자 하며, 그 포트에서는 어떤 프로세스 listening도 하지 않고 있다고 가정한다. 이 포트를 위한 첫 번째 TCP 패킷이 quark에 도착할 때, TCP의 네트워킹층은 도착한 패킷을 인식할 것이고, 즉시 "Port Unreachable" 상태의 ICMP 메시지를 erdos로 되돌려 줄 것이다. 이해할 수 있는 ICMP 메시지는 수 없이 많으며, 그 중에는 에러 상태를 취급하는 메시지도 있다. 그 중에 Redirect message라 불리우는 매우 흥미로운 메시지가 하나 있다. 비록 더욱더 짧은 경로가 있다하더라도, 그것은 라우팅 모듈에 의해 운영되며, 다른 호스트가 게이트웨이를 통해서 그것을 사용할 때 감지된다. 예를 들어, 부팅한 후에 sophus의 라우팅 테이블이 불완전한 상태가 될 수도 있고, Mathematics 네트워크와 FDDI 백본에 경로가 포함되어 있을 수도 있으며, Groucho Computing Center's gateway (gccl)에 있는 라우트 포인팅이 초기값으로 설정되어 있을 수도 있다. 그래서 quark에 있는 패킷들이 물리학과에 물려있는 게이트웨이인 niels보다 오히려 gccl로 보내질 것이다. 형편없는 경로 배정으로 어떤 데이터 그램을 전송받을 때, gccl은 그 패킷들을 niels로 다시 전송할것이고, 동시에 최상의 경로 배정을 지시하는 ICMP Redirect 메시지를 sophus로 전송할 것이다. 지금하게될 내용이 가장 기본적인 설정작업을 수동으로 해야하는 번거로움을 피하기 위한 좋 은 방법처럼 보일수도 있지만 RIP나 ICMP Redirect messages가 동적 라우팅 구성에 의 존하고 있다하더라도 이것이 항상 좋은 생각만은 아니다. ICMP Redirect 와 RIP는 몇몇 라우팅 정보가 실제로 믿을 만한 것인지를 검증하기 위한 어떤 선택사항도 제공해 주지 않는다. 이것이 혹 여러 분의 전체 네트워크 트래픽을 분열시키기 위해 고의로 쓸데 없는 작업을 허용하고 있는지도 모른 다. 이러한 이유 때문에, 그것들이 마치 호스트의 경로를 재 발송하는 것처럼, 네트워크 라 우트에 영향을 미치는 Redirect messages들을 치료하기 위한 몇몇 Linux 네트워킹 코드가 있다.
2.6 The Domain Name System
Hostname Resolution위에서 기술한 대로, TCP/IP 네트워킹에서 어드레싱은 32비트 숫자들로 운영된다. 하지만, 여러 분들은 이 숫자들을 기억하는데 많은 어려움을 느낄 것이다. 그래서, 호스트는 일반적으로 gauss 또는 strange와 같은 정규 이름을 가지고 있다. 이 이름과 일치하는 IP 어드레스를 찾는 것 이 어 플리케이션의 의무이다. 이러한 과정을 host name resolution이라고 부른다. 주어진 호스트명의 IP 어드레스를 찾아야 하는 어플리케이션은 호스트와 IP 어드레스를 찾 기 위해 자체적으로 어떤 체계를 가지고 있진 않다. Instead, it relies on number of library functions that do this transparently, called gethostbyname(3) and gethostbyaddr(3). 전통적으로, 이러한 것들과 그 절차에 연관되어 있는 숫자는 resolver library라고 하는 여러개의 라이브러리로 그룹화되어 있다; 리눅스 상에서 이러한 것들은 표준 libc에 한 부분이다. 일상적으로, 기능들의 모음들을 "the resolver"라고 부른다. 현재 Ethernet과 같은 조그마한 네트워크에서나 심지어 그것들의 클러스터에서도 호스트명 을 어드레스에 대입시키는 테이블을 유지하기란 정말 힘든 작업이다. 이러한 정보들은 대개 파 일명 이 /etc/hosts라고 하는 곳에서 유지되고 있다. 호스트를 추가하거나 삭제할 때, 또는 어드레스들을 반환할 때, 여러분은 모든 호스트에 있는 hosts파일을 갱신해 주어야 한 다. 분명히 이것은 몇대의 컴퓨터로 네트워크를 구성하는 것보다 더 귀찮은 작업일지도 모른다. Sun Microsystems가 개발한 NIS, Network Information System에서 이러한 문제를 해결하기 위한 하나의 방편으로 YP 즉, 옐로우 페이지라는 것을 내 놓았다. NIS는 마스터 호스트에 있는 데이터 베이스에 hosts 파일과 또 다른 정보들을 저장해 놓는다. 그러면 클라이언트는 필요 한 정 보를 데이터 베이스에서 검색할 수 있다. 이러한 방법은 아직 LAN과 같은 중급 네트워크에 적합 한 방법이다. 왜냐하면, 전체 hosts 데이터 베이스를 유지하고, 그것을 모든 서버에 분배해 주어야 하기 때문이다. 인터넷 상에서, 어드레스 정보는 기본적으로 HOSTS.TXT라고 하는 데이터베이스에 저장되어 있다. 이 파일은 Network Information Center 또는 NIC에 의해 유지되고 있으며, 이 것은 모든 참 여 사이트에 전송되고 설치되어야 한다. 네트워크가 계속해서 성장할 때, 이러한 구성에는 몇가지 문제점들이 발생한다. 게다가 관리상의 문제점으로써, 정규적으로 HOSTS.TXT파일을 설치 해야 하고, 그 파일을 서버에 정기적으로 분배해야 하는 문제점도 포함하고 있다. 심지어 NIC에 등록 되어야 하는 모든 이름에 심각한 문제점들이 발생할 수도 있으며, 이름을 가지고 있지 않은 것이 밖으로 유출되는지를 확인해 보기도 해야 한다. 1984년, 이러한 이유로써, 새로운 이름 해결 방법 즉, Domain Name System이라는 것이 채택 되었다. DNS는 Paul Mockapetris가 개발하였고, 그와 동시에 주소와 관련된 모든 문제들을 해결 했다.
Enter DNSDNS는 도메인과 호스트명을 계층적으로 구성하고 있다. 도메인은 어떤 의미와 연관되어 있는 사이트들의 집합이다. -- 도메인이 적절한 네트워크 형태 (예를 들어 대학에 있는 모든 기 계들, 또는 BITNET에 있는 모든 호스트들)로 되어 있기도 하고, 특정 기구 (미국 정부) 또는 지 리적으 로 묶여 있기도 하다. 이를 테면, 대학들은 edu 도메인으로 그룹화되어 있고, 각 종합대학과 단과대학은 다시 그것들의 호스트를 포함하고 있는 여러개의 subdomain을 사용한다. Groucho Marx University는 groucho.edu 도메인을 부여받았을 것이고, 수학과의 LAN은 maths.groucho.edu를 할당받았을 것이다. 부문 네트워크에 있는 호스트들은 그 자체의 호스트명을 도메인명으로 사용할 것이다; 그래서 erdos가 erdos.maths.groucho.edu로 알려져 있는것인 지도 모른다. 이것을 fully qualified domain name 또는 FQDN이라 부르며, 이것으로 인해 특정 호스트가 전세계에서 유일 무이하게 입증될 수 있다.
Figure 2.3: A part of the domain name space
그림 2.3은 도메인 네임 영역을 보여주고 있다. 이 트리에서 루트에 있는 개체는 하나의 점-도트- (이것을 root domain이라 부른다.) 으로 표시한다. 그리고 다른 모든 도메인을 포 함 하고 있다. 호스트명을 어떤 함축적인 의미를 가진 지역 도메인명을 사용하기 보다 오히려 fully qualified domain name으로 표시하기 위해, 때때로 그것은 trailing dot로 쓰여진다. 이것은 그 이름의 마지막 요소가 루트 도메인이라는 것을 의미한다. 이름 개체에 의존하고 있는 하나의 도메인은 top-level, second-level, 또는 third-level이 라고 부르기도 한다. 그리고 많은 레벨들이 세분화되고 있지만, 그렇게 많은 것은 아니다. 다음에 여러 분이 자주 볼수 있는 top-level에 관해 설명해 놓았다.
인터넷에서는 법적으로 네 개의 도메인 (edu, net, mil, gov)을 미국에서만 사용할 수 있게 하고 있으나 미국에 속해있지 않은 나라에서도 이들 도메인을 사용하는 경우가 있다. 그 중 특수하게, net 도메인을 들수가 있지만, mill과 gov는 오로지 미국에서만 사용할 수 있다. 미국 이외의 나라에서는 일반적으로 ISO-3166에 정의되어 있는 두 개의 문자로 각 나라의 top-level 도메인을 나타낸다. 이를테면, 필란드는 fi 도메인을 사용하고, 프랑스는 fr을, 독일은 de, 그리고 호주는 au를 top-level 도메인으로 사용한다. top-level 도메인 다음에오는 호스트 명은 각나라의 NIC에서 자유롭게 구성할 수 있다. 예를 들어, 호주에서 second-level 도메인을 국제적으로 사용하는 top-level 도메인과 유사하게 즉, com.au 또는 edu.au처럼 사용할 수 있다. 독일과 같은 나라에서는 특별한 도메인을 써서 특정 기구를 직접적으로 언급하기 위해 약간은 긴 이 름을 사용하기도 한다. 예를 들어, ftp.information.unierlangen.de 와 같은 호스트명을 사용하는 것이 보기 드문 것만은 아니다. 독일과 같은 능력있는 나라에서는 보통 사용하는 호스트명과 완전히 다른 것을 사용하기도 한다. 물론, 이러한 국제적인 도메인이 아래에서 설명하게될 호스트를 의미하는 것은 아니다. 그 도 메인은 실제로 그 나라에 위치하고 있다; 오직 그 나라의 호스트는 그 나라의 NIC에서 등 록시키 고 있다. 스웨덴의 회사가 호주에 지사를 둘 경우, 그 지사에 있는 모든 호스트들은 그들의 top-level 도메인을 se 로 등록시킨다. 현재, 네임 영역에 있는 도메임 네임을 계층적으로 구성하게 되면, 그 이름들이 중복되는 문 제를 말끔히 해결할 수 있다. ; DNS와 호스트의 이름은 전세계에서 오직 하나이어야 한다. 게다 가, fully qualified name들은 기억하기 쉬워야 한다. 그리고 이미 거대한 하나의 도메인을 여 러 서브 도메인으로 나누기 위한 좋은 방법들이 나와있다. 그리고 DNS는 심지어 관리자를 거쳐서 해야하는 작업 즉, 서브도메인을 만들 수 있는 권한 을 여러분에게 위임해주는 것보다 더 한 것을 허가해 주기도 한다. 예를 들어, Groucho Computing Center에 있는 유지자(maintainer)가 각 부(department)를 위한 서브 도메인을 만들 수도 있다. 이미 위에서 maths와 physics라는 서브도메인을 보았다. 만약 물리학과에 있는 네트 워크가 엉망진창인 상태로 발견이 된다면, 이 네트워크 관리자에게 physics.groucho.edu 도 메인 을 관리하게끔 할지도 모른다. 어쩌면 이 사람들은 그들이 좋아하는 호스트명을 사용할 수 도 있 고, 유행에 따라 네트워크를 관리할 수도 있으며, 외부 간섭을 전혀받지 않은 상태에서 IP 주소를 할당할 수도 있다. 이런식으로 일어날 수 있는 현상들 때문에, 네임 영역은 zone으로 나누어지게 되며, 각 네임 영 역은 하나의 도메인으로 뿌리를 내리게 된 것이다. 여기서 zone과 domain사이에는 아주 민감한 차이가 있다는 것을 주의하라; domain groucho.edu는 Groucho Marx University에 있는 모든 호스트를 둘러싸고 있는 반면에 zone groucho.edu는 Computing Center가 직접적으로 관리 하는 호스트 예를 들어 수학부 (수학과)만을 포함하고 있다. Physics Department에 있는 호스트들은 다른 zone 즉, physics.groucho.edu에 속해 있다. 그림 2.3에서, 하나의 zone의 시작이 작은 원으로 표시되어 있고, 그 원의 왼쪽에는 도메인이 있다.
Name Lookups with DNS잠깐 보아서 이러한 모든 도메인과 존(zone)은 대단히 복잡한 작업에 대한 하나의 해결방 안처럼 보인다. 결국, 호스트명을 할당할 수 있는 중심 권한이 없다면, 보잘 것 없는 어플리케이션 이라도 어떻게 안다고 가정할 수 있겠는가? 여기 DNS에 관해 정말 소박하게 답변해 놓은 것이 있다. 만약 여러분이 erdos의 IP 주소 를 찾고 싶다면, DNS는 그것을 관리하고 있는 사람에게 물어보라고 말할 것이다. 그러면 그 관리자 가 여러분이 알고 싶어 하는 정보를 알려줄 것이다. 사실, DNS는 거대하게 분포되어 있는 데이터베이스이다. 이것은 네임 서버의 의미로써 수 행 되는데 주어진 도메인과 도메인 집합에 관한 정보를 제공한다. 각 존(zone)을 위해서, 적어 도 두 개의 네임 서버가 있으며, 그 네임 서버는 그 존(zone)에 있는 호스트에 관한 모든 정보를 가지고 있다. erdos의 IP 주소를 구하기 위해서는, groucho.edu zone을 위한 네임 서버에 접속해 서, 바 라는 정보를 얻어야 한다. 여러분이 생각하는 것보다 어쩌면 더 쉬울 지도 모른다. 내가 Groucho Marx University에 있 는 네임 서버에 어떻게 도달할 수 있는가? 또, 여러분의 컴퓨터가 address-resolving oracle 도 갖 추어 놓지 않은 경우에도 DNS는 또한 그러한 것을 제공해 준다. 여러분의 어플리케이션이 erdos 에 관한 정보를 찾아내고자 할 경우, 로컬 네임서버에 접속해서, 이른바 interative query를 수행 한다. 여러분의 로컬 네임서버는 루트 도메인을 위한 네임서버에게 질의를 보냄으로써 작업 을 시 작하게 된다. 그리고 그것은 네임서버에게 erdos.maths.groucho.edu의 주소를 요청한다. 루트 네임서버는 이 이름이 루트권한에 속하지 않는다는 것을 인식하게 되며, 오히려 edu 도메인 에 그 러한 권한이 있다고 판단한다. 그래서, 루트 네임서버는 더 자세한 정보를 알고 싶다면, edu zone 네임서버로 접속하라고 말해줄 것이며, 그들의 주소와 함께 모든 edu 네임서버 목록을 폐쇄 한다. 그러면, 여러분의 로컬 네임 서버는 edu 네임 서버중의 하나, 이를테면 a.isi.edu에게 질의 를 보 내게된다. 루트 네임 서버와 유사한 방법으로써, a.isi.edu는 groucho.edu가 있는 지역을 알 아차 리고, 여러분에게 그 서버가 있는 위치를 가르쳐 준다. 그러면 로컬 네임 서버는 erdos에게 질의 를 보내게 되며, 마지막으로 그것은 그 주소가 있는 지역을 알아차리게 되고, 일치하는 IP 주소를 그 어플리케이션으로 보내게 된다. 지금까지 설명한 것에서 보면, 단순하게 IP 주소를 찾는데에 엄청나게 많은 트래픽이 걸리 는 것처럼 보인다. 하지만 HOSTS.TXT에서 보게될 엄청나게 많은 양의 문서를 읽는 것보다는 간단 한 작업이다. 그러나 이러한 과정속에서도 개선되어야 할 많은 문제점들이 있다. 미래에는 질의를 하는동안 그 응답시간을 줄이기 위해, 네임서버는 로컬 cache에다가 구한 정 보를 저장할 것이다. 그래서 다음에 여러분의 로컬 네트워크에서 누구나가 groucho.edu에 있는 호스트의 주소를 찾고자 할 경우, 여러분의 네임서버는 전체 과정을 또 다시 거치지 않고 직접적 으로 groucho.edu에 접속하게 될 것이다. - 만약 그렇지 않다면, DNS가 다른 것과 같이 안좋은 방법일지도 모른다. 왜냐하면, 각 질의가 루트 네임 서버를 필요로 하기 때문이다. 물론, 네임서버가 영원히 이 정보를 간직하고 있지는 않을 것이다. 오히려 약간의 기간이 지 나 면, 그것을 폐기 처분할 것이다. 이러한 만료시간을 time to live 또는 TTL이라고 부 른다. 한 지 역을 책임지는 관리자가 DNS 데이터 베이스에 있는 각 자료에 이 TTL을 할당한다.
Domain Name Servers네임서버들은 authoritative로 불리는 지역안에 있는 호스트에 관한 정보를 가지고 있다. 그 래서, 때때로 그것은 master name servers라고 하기도 한다. 이 지역에 있는 호스트에게 보내는 어떠 한 질의조차도 마지막에는 이러한 마스터 네임 서버에서 끝나게 된다. 한 지역의 간섭화면을 제공하기 위해서는 그것의 마스터 서버가 더 잘 표시해 줄 것이다. 데 이터 파일로부터 얻은 정보를 그 지역에 적재시키는 마스터 서버중에 하나인 primary 서버 를 만 들고, 규칙적인 간격으로 primary 서버에서 자료를 그 지엑에 전송해 주는 또 다른 secondary 서 버들을 만들어 줌으로써 이러한 작업을 이루어 낼 수 있다. 여러 네임서버를 가지는 이유중에 하나로는 적재 작업을 분산시키기 위해서이고, 또 다른 이 유로는 과다한 작업양을 여러 네임서버에 분배하기 위해서이다. 하나의 네임 서버 머신이 충돌이 나 손실과 같은 현상으로 인해 네트워크 연결에 실패했다면, 다른 서버로 모든 질의를 요청 할 것 이다. 물론, 이러한 구성이 여러분을 서버고장 (모든 DNS 요청에 대해 잘못된 결과를 산출 해내는 경우, 예를 들어 서버 프로그램으로 인해 소프트웨어 버그가 발생되는 경우)으로부터 보호 해 주지 는 못한다. 물론 여러분은 또한 실행하고 있는 네임 서버에서 제공되는 어떤 도메인도 믿지 못할 것 이 다. - 어쩌면 거의 그럴지도 모른다. 적어도 네임서버는 localhost를 위한 네임 서비스 와 127.0.0.1에 해당하는 룩업을 예약해 주어야 한다. 그럼에도 불구하고 이러한 서버 형태가 유용한 경우도 있다. 이것은 여전히 로컬 네트워크 에서 실행하고 있는 어플리케이션을 위한 DNS 질의들을 처리하고 그 정보를 저장할 수 있 다. 이 러한 형태를 caching-only 서버라고 부른다.
The DNS Database우리는 위에서 DNS가 호스트의 IP 주소를 처리하는 것 뿐만 아니라 네임서버에서 정보를 교환하는 일도 한다는 것을 알았다. 사실 DNS 데이터베이스는 많은 다른 형태의 엔트리를 가지고 있 다. DNS 데이터 베이스에 있는 하나의 정보 조각들을 resource record 줄여서 RR이라고 부른다. 각 레코드는 그것과 관련되어 있는 형태를 가지고 있고, 그것을 표현하는 데이터층을 기술 해 주 고 있으며, 하나의 클래스는 그것을 사용하는 네트워크 형태를 명시해 주고 있다. 후자는 IP 주소 들 (the IN class) 또는 MIT에서 사용되는 Hesiod 네트워크의 주소와 같은 또 다른 어드레 싱 방 법의 필요를 수용시키고 있다. 기본적인 resource record 형태는 하나의 IP 주소와 함께 하나의 fully qualified domain name과 관련되어 있는 하나의 레코드를 말한다. 물론, 호스트가 여러개의 이름을 가질 수도 있다. 하지만 이러한 이름들중 하나는 꼭 공식적 으 로 확인될 수 있는 canonical host name 이어야 한다. 반면에 다른 이름들은 단순히 전자에 서 언 급하고 있는 가명들이다. 이 두가지 형태에서 차이점을 말한다면, canonical 호스트명은 관 련되어 있는 레코드가 오직 하나밖에 없지만, 다른 호스트명은 canonical 호스트명을 가리키고 있는 CN- AME형태의 레코드를 가지고 있다. 우리가 여기서 모든 형태의 레코드를 다룰 수는 없지만, 다음장에서 몇 개를 설명해 놓았으 며, 여기 믿을 만한 예제를 들어 놓았다. 그림 2.4는 physics.groucho.edu 지역(zone)을 위한 네 임서 버로 적재되는 도메인 데이터베이스의 한 부분을 보여주고 있다.
Figure 2.4: An excerpt from the named.hosts file for the 물리학과
A와 CNAME은 일단 제쳐놓고, 여러분은 파일의 제일 윗 부분에서 특별한 레코드를 볼수 있 다. 이것은 SOA (Start of Authority) 리소스 레코드이다. 이것은 그 지역에 있는 일반적인 정보 를 가지고 있다. 이를 테면, 이것은 모든 레코드를 위한 time-to-live의 초기값을 포함하고 있다. 예제 파일에서 도트(.)로 끝나지 않는 모든 이름은 groucho.edu 도메인과 연관되어 해석된 다 는 것을 명심하라. SOA 리소스에서 사용되는 특별한 이름인 "@"은 그 자체의 도메인 네임 을 나 타낸다. 우리는 위에서 groucho.edu 도메인을 위한 네임서버들이 어쨋든 간에 physics 지역(zone) 에 관한 정보를 알고 있고, 그래서 그들의 네임서버로 질의를 요청할 수 있는 것을 보아왔다. 이것은 대개 한쌍의 레코드에 의해 수행된다 ; NS 레코드는 서버의 FQDN을 가지고 있고, 하나의 레코 드는 그 이름과 관련되어 있는 주소를 가지고 있다. 이러한 레코드가 네임 영역에 함께 저 장되는 이래로, 그것들을 자주 glue records라고 부르기도 한다. 이것들은 부 지역(parent zone)이 실제로 종속 지역에 있는 호스트에 관한 정보를 가지고 있는 레코드들의 대표적인 예이다. glue 레코드 는 그림 2.5에서 보는 것과 같이 physics.groucho.edu를 위한 네임서버를 가리키고 있다.
Figure 2.5: An excerpt fro the named.hosts file for GMU.
Reverse Lookups호스트에 속해 있는 IP-주소를 찾는 것 이외에도 주소에 해당하는 찾는 것이 때때로 더 바람하다. 이것을 reverse mapping라 부르고 신분을 검증하기 위 해서 여러 네트워크 서비스에 의해 사용된다. 단독 hosts 파일을 사용할 때, reverse lookups는 단순히 그 질 의에 해당하는 IP 주소를 가지는 호스트를 위한 파일을 찾아준다. DNS를 가지고 네임 영역 을 철 저하게 찾는 작업은 물론 질의와는 상관없는 작업이다. 대신에, 지금까지 만들어 지고 있는 특별 한 도메인인 in-addr.arpa은 dotted-quad 표기법으로 모든 호스트의 IP 주소를 포함하고 있다. 이를 테면, 149.76.12.4라는 IP 주소는 4.12.76.149.in-addr.arpa라는 이름과 일치한다. 이러한 이름들을 그것들의 canonical 호스트명과 연결시킨 리소스 레코드를 PTR이라고 부른다. 어떤 권한을 가지는 지역을 만들어 내는 것은 대개 그 지역을 관리하는 사람이 IP 주소를 호 스트명에 할당하는 모든 작업을 완전하게 통제할 수 있다는 것을 의미한다. 그들은 대개 수동으 로 설정할 수 있는 하나이상의 IP 네트워크와 서브넷을 가진 이래로, DNS 지역(zone)과 IP 네트 워크를 1 대 ? (one-to-many)로 매핑하는 경향이 있다. 이를테면, 물리부(Physics Department)는 서브넷 149.76.8.0, 149.76.12.0 그리고 149.76.14.0를 포함하고 있다. 그 결과, in-addr.arpa 도메인에 있는 새로운 지역은 physics 지역에 따라 만들어 져야 하고, 그 부(department)에 있는 네트워크 관리자에게 권한을 위임받아야 한다; 8.76.149.in-addr.arpa, 12.76.149.in-addr.arpa 그리고, 14.76.149.in-addr.arpa. 그렇지 않고, Collider Lab에 다가 새로운 호스트를 설치하는 경우, 그들의 in-addr.arpa 지 역 (zone) 파일에 입력되어 있는 새로운 주소를 가지기 위해서 그들의 부(parent) 도메인에 접속할 필요가 있을 것이다. 서브넷 12를 위한 지역(zone) 데이터베이스가 그림 2.6에 나타나 있다. 그들의 부 지역 (parent zone)의 데이터 베이스와 일치하는 glue 레코드들은 그림 2.7에 나타나 있다.
Figure 2.6: An excerpt from the named.rev file for subnet 12
Figure 2.7: An excerpt from the named.rev file for network 149.76.
이것들중 가장 중요한 결과를 들자면, 지역(zone)은 단지 IP 네트워크의 superset으로 만들 어 질 수 있고, 이러한 네트워크의 넷마스크는 바이트를 경계로 해야 한다. Groucho Marx 대학에 있는 모든 서브넷들은 255.255.255.0인 넷마스크를 가지며, 어쨋든 in-addr.arpa 지역은 각 서브넷을 위해 만들어 질 수 있었다. 그러나, 대신에 넷마스크를 255.255.255.128 로 준다면, 서브넷 149.76.12.128을 위한 지역을 절대 만들어 질 수 없다. 왜냐하면, 12.76.149.in-addr.arpa 도메인이 권한을 가지는 두 개의 지역 (각각 호스트명이 하나는 1에서 127까지, 또 하나는 128에서 255까지의 지역)으로 나누어져 있다고 DNS에게 말할 수 있는 방법이 없기 때문이다.
3. Configuring the Networking Hardware
3.1 Devices, Drivers, and all that현재까지 우리는 네트워크 인터페이스와 일반적인 TCP/IP 개관에 대해 이야기 해 보았 다. 하지만, 하드웨어의 한 부분을 제어하는 커널에서 "Networking code"가 도대체 무슨일 을 하는지 정확히는 알지 못한다. 이러한 경우를 위해서, 이 장에서는 인터페이스와 드라이 버의 개념에 대해 다루어 볼까 한다. 우선 하드웨어 그 자체를 설명할 것이다. 예를 들어, 이더넷 보드; 이것은 얇은 에폭시 수지로 이루어져 있고, 그 속에는 각 번호를 가진 많은 양의 작은 칩들로 채워져 있으며, 그 보드를 PC의 슬롯에 꽂아 넣으면 된다. 여기서는 이런식으로 장치에 대해 설명할 것이다. 이더넷 보드를 사용할 수 있게 하기 위해서, 리눅스 커널에 특별한 기능(옵션) 을 표시해 두어야 한다. 그러한 특별한 방법으로 장치를 제어해 주어야 한다. 이러한 것들을 이른바 장 치 드라이버라고 한다. 예를 들어, 리눅스는 기능면에서 이더넷 보드와 유사한 종류의 장치 드라이버를 가지고 있다. 그러한 장치 드라이버는 그것의 제작자인 Donald Becker의 이름을 따서 "Becker Series Drivers"라고 부른다. 다른 예를 들어, D-Link 드라이버라는 것 이 있는 데, 이것은 병렬 포트에 연결되어 있는 D-Link 패킷 어댑터를 처리해 준다. 그런데, 장치 드라이버를 "처리한다"라는 말은 어떤 의미일까? 위에서 이더넷 보드에 대 해 설명해 놓은 부분으로 가보자. 드라이버는 어쨋든 간에, 주변장치의 내장 로직과 통신할 수 있어야 한다 : 즉, 드라이버는 보드로 명령어와 데이터를 보내야 하는 반면에, 보드는 드 라이버로 부터 받은 어떠한 데이터라도 전송받을 수 있어야 한다. PC에서의 이러한 통신은 입출력 메모리 영역에서 이루어지며, 그것은 내장 레지스터와 대응할 수 있다. 입출력 메모리는 일반적으로 레지스터의 시작 부분이나 base address에 기 술되어 있다. 이더넷 보드의 전형적인 베이스 주소는 0x300, 또는 0x360이다.
그림 3.1: 장치 드라이버, 인터페이스 그리고 하드웨어와의 관계
대개, 여러분은 베이스 주소와 같은 하드웨어 개관에 대해서는 걱정하지 않아도 된다. 왜 냐하면, 커널이 부트시간에 보드의 위치를 감지해 내기 때문이다. 이러한 것을 autoprobing이라고 부른다. 즉, 이것은 커널이 여러 메모리 위치를 읽어 들이고, 어떤 이더넷 보드가 설치되어 있는지를 그 데이터와 비교한다. 하지만, 자동으로 감지해낼 수 없는 이더넷 보드 또한 있을지도 모른다; 표준 보드와 전혀 호환성이 없는 값싼 이더넷 카드를 만들어 내는 경우이다. 그리고 나서 커널을 부팅할 때, 이더넷 장치를 감지해 내려고 시도할 것이다. 만약, 여러분이 하나 이상의 보드를 사용하고 있다면, 이러한 정보를 커널에 기술해 놓아야 한다. 여러분이 커널에 기술해 놓아야 하는 또 다른 변수로는 인터럽트 요청 채널이 있다. 커 널에서는 각 하드웨어 부품에 대해 인터럽트를 매기는데, 그들 부품들은 이 인터럽트에 의 해 처리될 필요가 있는 경우가 있다. 예를 들어, 어떤 데이터가 도착할 때, 특별한 상태가 발생하기도 한다. PC에서, 인터럽트들은 0과 1 그리고 3에서 15까지 번호를 부여한 15개의 인터럽트 채널들 중 하나에서 발생한다. 하드웨어 부품들이 각각 하나씩 인터럽트번호를 가 지고 있으며, 이러한 인터럽트번호를 interrupt request number, 또는 IRQ. - IRQ 2와 9는 실제로 같다. 왜냐하면, PC는 각 8개의 IRQ를 가진 인터럽트 프로세서를 두줄로 직렬배열하고 있기 때문이다. 즉, 두 번째 프로세서는 첫 번째 프로세서의 IRQ 2에 연결되 어 있다.라고 부른다. 2장에서 기술한대로, 커널은 이른바 인터페이스를 통해 장치(device)를 엑세스한다. 인터 페이스는 모든 종류의 하드웨어에서 데이터를 받거나 보내거나 하는 추상적인 기능을 제공 한다. 인터페이스는 그 이름과 동일한 것으로 간주한다. 이러한 것들은 커널에서 정의된다. 즉, /dev 디렉토리에 꼭 장치 파일이 있는 것은 아니다. 전형적으로 이더넷 인터페이스를 위한 이름으로는 eth0, eth1이 있다. 각 장치에 해당하는 인터페이스의 할당은 그 장치가 구성되 어 있는 순서에 따라 결정된다; 이를테면, 첫 번째로 설치되어 있는 이더넷 보드는 eth0이 될것이고, 다음것은 eth1으로 이름지어 질 것이다. 이러한 규칙들 중 물론 예외도 있다. SLIP 인터페이스는 동적으로 할당된다. 다시 말해서, SLIP 연결이 확립될 때, 인터페이스가 시리얼 포트에 할당된다. 그림 3.1에서 우리는 하드웨어, 장치 드라이버 그리고 인터페이스간의 관계를 볼 수 있다. 부팅할 때, 커널이 감지하는 장치와 설치되어 있는 인터페이스가 화면에 나타난다. 다음 예는 우리가 흔히 볼 수 있는 부트 화면이다.
.
.
This processor honours the WP bit even when in supervisor mode. Good.
Floppy drive(s): fd0 is 1.44M
Swansea University Computer Society NET3.010
IP Protocols: ICMP, UDP, TCP
PPP: version 0.2.1 (4 channels) OPTIMIZE_FLAGS
TCP compression code copyright 1989 Regents of the University of California
dl0: D-Link DE-600 pocket adapter, Ethernet Address: 00:80:C8:71:76:95
Checking 386/387 coupling... Ok, fpu using exception 16 error reporting.
Linux version 1.1.11 (okir@monad) #3 Sat May 7 14:57:18 MET DST 1994
지금 이것은 커널에서 TCP/IP 와 SLIP, CSLIP 그리고 PPP를 사용가능하게 컴파일하는 과 정의 일부분이다. 밑에서 세 번째 행은 D-Link 포켓 어댑터가 감지되었고, 설치되어 있는 인터페이스는 dl0라는 것을 말해준다. 만약 여러분이 다른 종류의 이더넷 카드를 가지고 있 다면, 커널은 대개 그 종류에 해당하는 카드를 감지해서, eth0 라는 인터페이스를 시작시키 는 행을 출력해 줄 것이다. 만약 여러분이 현재 설치되어 있는 이더넷 카드를 가지고 있다 면, 어떤 메시지도 볼 수 없다. 즉 이것은 커널이 여러분의 보드를 감지해낼 수 없다는 것을 뜻한다. 이것에 대해서는 다음절에서 상세히 다루겠다.
3.2 Kernel Configuration대부분의 리눅스 배포본에서는 모든 일반적인 종류의 PC 하드웨어를 구동시켜 주는 부트 디스크를 가지고 있다. 이것은 그 부트 디스크에서 커널이 모든 일반적인 종류의 드라이버 를 가지고 있다는 것을 의미한다. 그러나 커널이 그 부분을 스왑 아웃 할 수 없기 때문에 이전의 시스템 메모리를 소비하게 된다. 그러므로, 여러분은 실제로 필요로 하고, 원하는 드 라이버만 포함시켜서 커널을 구성해야 한다. 리눅스 시스템을 구동시킬 때, 여러분은 꼭 자기가 만들고 있는 커널을 잘 알고 있어야 한다. 이것에 대해 기본적으로 설명하고 있는 문서로는 Matt Welsh가 쓴 " Installation and Getting Started"가 있다. 이것도 또한 Linux Documentation Project (LDP) 시리즈중 하나 이다. 이 절에서, 우리는 네트워킹과 관련되어 있는 구성 옵션만을 다룰 것이다. 여러분이 make config를 실행하기에 앞서, 일반적인 구성에대해 답해야 할 것이다. 이 를테면, 여러분이 커널의 수치연산 프로세서를 원하고 있는지 아닌지... 이러한 것들중 하나 로써, TCP/IP 네트워킹을 원하는지도 답해야 한다. 실제로 네트워킹을 하고 싶다면 'y'를 입력해야 한다.
Kernel Options in Linux 1.0 and Higher일반적인 옵션에 대한 답변을 완성한 후에, SCSI 드라이버와 같은 여러 가지 전반적인 형 태에 대한 질문에 답변해야 한다. 다음에 보이는 것은 네트워킹 지원에 관한 질문이다. 이 구성옵션에 관한 세부 항목들은 이 질문이 끝난후 계속해서 나타날 것이며, 이러한 질문도 커널이 발전해 감에 따라 더 늘어날 것이다. 지금 보이는 것은 대부분의 커널 버전 1.0과 1.1에서 제공되는 옵션이다. (그에 관한 주석문은 이탤릭체로 나타낸다.);
*
* Network device support
*
Network device support? (CONFIG_ETHERCARDS) [y]
꺽쇠 묶음([])에서 나타난 매크로 이름은 무시해 버려라. 여러분이 어떤 형태의 네트워킹 장 치 즉, 이더넷, SLIP 또는 PPP를 사용하고자 한다면, 이 질문에 'y'라고 답해야 한다. 이 질 문에 'y'라고 답했다면, 자동으로 이더넷 류의 장치를 지원하게 된다. 다른 형태의 네트워크 드라이버를 지원하고자 한다면, 개별적으로 선택해야 한다.
SLIP (serial line) support? (CONFIG_SLIP) [y]
SLIP compressed headers (SL_COMPRESSED) [y]
PPP (point-to-point) support? (CONFIG_PPP) [y]
PLIP (parallel port) support? (CONFIG_PLIP) [n]
이러한 질문에 답변하려면 적어도 리눅스에서 제공하는 여러 가지 프로토콜에 대해서 약 간의 지식은 알고 있어야 한다. SLIP은 시리얼 라인을 통해서 IP 데이터 그램을 전송하는 것이다. compressed headers 옵션은 CSLIP을 위한 지원사항을 물어보는 것인데, 이 CSLIP 는 TCP/IP 헤더를 적어도 세바이트로 압축하는 기술을 말한다. 이 커널옵션이 자동으로 CSLIP을 지원해 주는 것이 아님을 기억하라. 대개 이것을 위해 특 별한 커널 기능을 필요로 한다. PPP는 시리얼 라인을 통해서 네트워크 트래픽을 보내주는 또 다른 프로토콜이다. SLIP 보다 약간더 다루기 쉽고, IP에 제한되어 있지 않으며, 그것이 수행될 때, IPX를 지원해 준 다. 최근에 들어와서 이 PPP 옵션을 제공해 주고 있지만, 이 커널에서는 아직 이 옵션이 없 다. PLIP는 패러랠 포트와의 연결을 통해서 IP 데이터 그램을 보내주는 방법을 제공한다. 이 것은 대개 DOS를 실행하고 있는 PC와 통신하기 위해서 사용한다. 다음 질문은 여러 컴퓨터 회사에서 만들어낸 이더넷 보드에 관한 질문들이다. 더욱더 많 은 드라이버가 개발되고 있다. 만약 여러분이 여러 다른 기계에서 사용할 수 있는 커널을 만들고자 한다면, 하나이상의 드라이버를 선택할 수 있다.
NE2000/NE1000 support (CONFIG_NE2000) [y]
WD80*3 support (CONFIG_WD80x3) [n]
SMC Ultra support (CONFIG_ULTRA) [n]
3c501 support (CONFIG_EL1) [n]
3c503 support (CONFIG_EL2) [n]
3c509/3c579 support (CONFIG_EL3) [n]
HP PCLAN support (CONFIG_HPLAN) [n]
AT1500 and NE2100 (LANCE and PCnet-ISA) support (CONFIG_LANCE) [n]
AT1700 support (CONFIG_AT1700) [n]
DEPCA support (CONFIG_DEPCA) [n]
D-Link DE600 pocket adaptor support (CONFIG_DE600) [y]
AT-LAN-TEC/RealTek pocket adaptor support (CONFIG_ATP) [n]
*
* CD-ROM drivers
*
...
파일 시스템 절(section)에서, 마지막으로, 환경 구성 스크립트는 여러분에게 NFS, 네트 워킹 파일시스템을 지원할 것인지를 물어볼 것이다. NFS는 파일시스템을 여러 호스트로 보 내주는 역할을 한다. 꼭 그것이 호스트에 붙어 있는 임시 하드 디스크 인것처럼 파일을 보 여 준다.
NFS filesystem support (CONFIG_NFS_Fs) [y]
Kernel Options in Linux 1.1.14 and Higher리눅스 1.1.14에서는 약간의 구성환경을 바꾸었으며, IPX 지원을 추가시켰다. 다음절에서는 여러분이 원하는 일반적인 네트워킹 옵션을 물어볼 것이다. 이것은 여러 가지 네트워킹 옵 션에 관한 질문을 말한다.
*
* Networking options
*
TCP/IP networking (CONFIG_TNET) [y]
여러분이 TCP/IP 네트워킹을 사용한다면, 이 질문에 'y'라고 답해야 한다. 그렇지 않고 'n'이라고 답했다 하더라도, IPX를 지원하는 커널을 컴파일할 수 있다.
IP forwarding/gatewaying (CONFIG_FORWARD) [n]
두 개의 이더넷이나 이더넷과 SLIP 링크사이에서 여러분의 시스템을 게이트웨이로써 사 용하고 있다면, 이 옵션을 사용할 수 있다. 이 옵션을 초기값대로 사용하지 않는다 하더라 도, 이른바 방화벽으로 호스트를 구성하고 싶어할 지도 모른다. 방화벽은 두 대 이상의 네트 워크에 연결되어 있는 호스트이지만, 그 네트워크 사이에서 라우트 트래픽을 하진 않는다. 방화벽은 대개 내부망에서 위험부담을 느끼고 있는 회사망으로부터 사용자들을 보호하는데 에 사용된다. 사용자들은 방화벽에 접속해서, 인터넷 서비스를 사용하지만, 그 회사망으로 들어오는 어떤 연결도 방화벽에 접근할 수 없기 때문에, 외부 공격으로부터 그 회사의 기계 를 보호할 수 있다.
*
* (it is saft to leave these untouched)
*
PC/TCP compatibility mode (CONFIG_INET_PCTCP) [n]
이 옵션은 몇몇 PC/TCP버전과, DOS를 기초로하는 PC에서, 구동하는 상업용 TCP/IP와는 비호환적으로 작동한다. 만약 여러분이 이 옵션을 사용한다면, 일반적으로 사용하는 UNIX 기계와 통신할 수 있지만, 그 기계에 연결하는 속도는 느려지게 될지도 모른다.
Reverse ARP (CONFIG_INET_RARP) [n]
이 기능은 RARP, Reverse Address Resolution Protocol을 사용할 수 있게 해준다. RARP는 디스크없는 클라이언트와 부팅할 때, IP 어드레스를 필요로하는 X 터미널에 사용 된다. 여러분이 몇몇 클라이언트를 제공할 계획이라면, RARP를 사용해야 한다. 최근에 나 온 네트워크 패키지들 (net-0.32d)은 rarp라고 하는 작은 유틸리티를 포함하고 있다. 이 유 틸리티로 시스템을 RARP 캐쉬에 추가시킬 수 있다.
Assume subnets are local (CONFIG_INET_SNARL) [y]
TCP를 통해서 데이터를 보낼 때, 데이터가 IP로 들어가기 전에, 커널은 여러패킷의 흐름을 중단시켜야 한다. 호스트를 위해서는 이더넷과 같은 로컬 네트워크를 통해서 데이터를 보낼 수있으며, 그 호스트는 먼거리에서 들어오는 데이터나 거대한 패킷또한 사용할 수 있을 것 이다.{{. 이것은 매우 작은 최대 패킷크기의 분열을 피하기 위한 방법이다. }} 만얀 여러분이 SNARL을 사용하지 않는다면, 커널은 그들의 네트워크들이 실제로 하나의 인터페이스를 가지고 있는 로컬네트워크라고 가정할 것이다. 그럼에도 불구하고 여 러분이 Groucho Marx University에 있는 클래스 B 네트워크를 찾고자 한다면, 클래스 B의 전체네트워크가 로컬이 되지만, 대부분의 호스트들의 인터페이스는 단지 하나이상의 서브넷 만을 가질 것이다. 만약 여러분이 SNARL을 사용한다면, 커널은 모든 서브넷이 로컬이라고 가정할 것이며, 대학에 있는 모든호스트와 통신할 때, 거대한 패킷을 사용하게 될 것이다. 만약 여러분이 특별한 호스트에 보내는 데이터를 위해서 조그마한 패킷을 사용하고자 한 다면, (이를테면, SLIP연결을 통해 데이터를 보내고자 하는 경우) 여러분은 route에 mtu옵 션을 사용해서, 그 문제를 해결할 수 있다. 이것에 대해서는 이장의 맨끝부분에서 거론할 것 이다.
Disable NAGLE algorithm (normally enabled) (CONFIG_TCP_NAGLE_OFF) [n]
Nagle는 이른바 tinygrams라고 부르는 특별하게 보내는 작은 IP 패킷을 피하기위한 규
칙이다. 대화식 네트워킹 툴이 이러한 tinygram을 만들어 내는데, telnet 또는 rsh와 같은
네트워킹 툴로 이러한 tinygram을 보낸다. SLIP과 같은 저 대역폭 연결에서는 tinygram을
파과할 수 있다. Nagel 알고리즘은 어떤 상황하에서 발생하는 데이터를 TCP 전송층으로 걷
어들이는 작업을 할 것이다. 만약 여러분이 전송도중 패킷을 잃어버릴 염려가 있다면,
Nagle 알고리즘을 사용하지 않을 수도 있다.
The IPX protocol (CONFIG_IPX) [n]
이 옵션은 노벨 네트워킹에서 사용하는 전송프로토콜인 IPX를 사용할 수 있게 해준다.
이것은 여전히 개발중에 있고, 아직 실제로는 사용할 수 없다. 이것을 사용하는 한가지 이점
이라면, 언젠가는 여러분이 IPX를 기반으로하고 있는 DOS 유틸리티를 사용할 수 있고,
PPP 연결을 통해서, 노벨에 기초를 두고 있는 네트워크에서 라우트 트래픽이 가능하다는
것이다. 노벨 네트워킹에서 고급 프로토콜을 지원할 날이 그다지 가깝지만은 않지만, 현재
소비되는 끔직한 많은 양의 비용을 생각해 보면, 반가운 소식중의 하나일 것이다.
1.1.16 커널에서, 리눅스는 또 다른 종류의 드라이버와 더미 드라이버를 지원해 주고 있 다. 다음 질문은 장치 드라이버를 사용할 것인지를 물어보는 질문이다.
Dummy net driver support (CONFIG_DUMMY) [y]
더미 드라이버를 사용하는 사람이 그다지 많지는 않지만, 스탠드얼론이나 SLIP 호스트에
서는 매우 유용하게 사용할 수 있다. 이것은 기본적으로 루프백 인터페이스를 매스커레이드
한 것이다. 루프백 인터페이스를 사용하는 이유는 이더넷에서가 아닌 SLIP을 사용하는 호스
트에서 구동하기 때문이며, 이것은 항상 여러분의 IP 어드레스를 유지시키는데에 도움을 준
다. 더미 인터페이스에 관한 더 자세한 것은 5장에서 다루것이다.
3.3 A Tour of Linux Network Devices리눅스 커널은 여러형태의 장비를 위해서 많은 하드웨어 드라이버를 지원해 준다. 이 절에 서는 흔히 볼 수 있는 드라이버와 그것에 해당하는 인터페이스에 대해 간략히 설명하겠다. 리눅스에서는 표준으로 사용하는 인터페이스가 몇몇있다. 하나이상의 인터페이스를 지원 하는 대부분의 드라이버는 그 인터페이스 이름이 eth0, eth1과 같이 각각에 번호를 부여하 고 있다.
ISDN 또는 AX.25와 같은 인터페이스 드라이버들은 미래에 추가될지도 모른다. IPX (노 벨 네트워킹 프로토콜)과 AX.25 (ham radio amateurs에서 사용됨)를 위한 드라이버들은 현 재 개발중에 있으나 아직 초기 단계에 머물러 있다. 다음 절에서 우리는 위에서 기술한 드라이버 사용에 관한 자세한 정보를 다룰 것이다.
3.4 Ethernet Installation현재 리눅스 네트워크 코드는 여러 가지 이더넷 카드 상표를 지원해 주고 있다. 대부분의 드라이버는 Donald Becker (becker@cesdis.gsfc.nasa.gov)에 의해 만들어 지고 있다. 그 는 National Semiconductor 8390 chip을 사용하는 카드를 위한 드라이버를 만들어낸 사람이 다. 이 드라이버는 Becker Series Drivers로 우리에게 잘 알려져 있다. 이 드라이버 중에는 패러랠 포트를 통해서 이더넷에 접근할 수 있게 해주는 D-Link 포켓 어댑터를 위한 드라이 버도 있다. 이러한 드라이버는 Bj rn Ekwall (bj0rn@blox.se)에 의해 만들어 졌다. DEPCA 드라이버는 David C. Davies (davies@wanton.lkg.dec.com)에 의해 만들어 졌다.
Ethernet Cabling만약 여러분이 일생에 딱 한번 이더넷을 설치하고자 한다면, 여기 케이블링이란 용어가 여 러분에게 적합할 것이다. 이더넷은 케이블링에 대해서는 매우 까다롭다. 이 케이블 양쪽 끝 레지스터는 50 옴(ohm)으로 맞추어져 있어야 하며, 여러분은 어떻게 해서든지 그것들을 분 기시켜 놓으면 안된다. (이를테면, 세 개의 케이블은 스타형(star-shape)으로 연결되어야 한 다. 만약 여러분이 T자 형태로 접합되어 있는 BNC 커넥터와 함께 얇은 동축 케이블을 사 용하고 있다면, 반드시 보드의 커넥터에 접합할 부분을 꼬아서 연결시켜야 한다. 만약 여러분이 thicknet에 연결하려고 한다면, 반드시 트랜스시버를 거쳐서 여러분의 호 스트를 접촉시켜야 한다. (때때로 이것을 Ethernet Attachment Unit라고 부른다.) 여러분은 그 트랜스시버를 보드에 있는 15핀 AUI 포트에 꽂아넣고 실드 케이블을 사용할 수도 있다.
Supported Boards지원하고 있는 보드의 완전한 리스트를 볼려면 Ethernet HOWTO 문서를 참고하라. 이것은 매달 Paul Gortmaker. - Paul에게 문의할 사항이 있다면, gpg109@rsphysse.anu.edu.au로 연락하기 바란다. 에 의해 comp.os.linux.announce에 포스트되고 있다. 여기에서 보는 목록들은 리눅스에서 지원하는 가장 널리 알려진 보드를 말해주고 있다. 실제로 HOWTO 목록에는 여기서 보는 것의 세배정도의 목록을 볼 수 있다. 이 목록에서 여러분이 가지고 있는 이더넷 보드를 찾으려고 한다면, HOWTO 문서를 보는편이 더 낫다. 이 문서에는 때때로 이러한 카드를 운영하는 중요한 세부항목들을 포함하는 경우도 있다. DMA에 기초를 두고 있는 이더넷 보드는 Adaptec 1542 SCSI controller과 같은 DMA 채널 을 사용한다. 여러분이 이더넷 보드의 DMA 채널을 다른 것으로 바꾸어 놓지 않는한, 이더 넷 보드가 만들어내는 패킷 데이터가 위치하는 지역이 마음대로 변할수도 있다.
리눅스에서 이러한 카드 중 하나를 사용하고자 한다면, 리눅스 배포본에 포함되어 있는 커널을 컴파일하여 사용할 수도 있다. 이러한 카드는 일반적으로 그에 해당하는 드라이버를 가지고 있다. 장기간 동안 사용하고자 한다면, 여러분이 실제로 필요한 드라이버를 커널에 포함시켜서 컴파일 하는 편이 더 낫다.
Ethernet Autoprobing부팅할 때, 이더넷 코드는 여러분의 보드를 지정된 지역에 놓으려고 할 것이다. 이 코드는 다음에 보이는 어드레스와 순서대로 카드를 검사할 것이다. 오토프로빙 코드에는 두가지 한계가 있다. 그중 하나는 모든 보드를 적절히 인식할 수 없다는 것이다. 이것은 일반적인 보드의 호환기종과 WD80x3 보드에서 종종 발생하는 현상 이다. 두 번째 문제는 커널이 순간에 하나 이상의 보드를 오토프로브할 수 없다. 이러한 현 상은 여러분이 어떤 보드가 어떤 인터페이스를 제어하는지를 모르는 것과 같이 생각해 볼 수있다. 만약 여러분이 하나이상의 보드를 사용하고 있거나, 오토프로브가 여러분의 보드를 감지 하는데에 실패했다면, 여러분은 반드시 카드의 베이스 어드레스와 이름을 커널에 명시해야 한다. Net-3에서, 이것을 수행하기 위해서는 두가지 다른 형태의 방법을 취할 수 있다. 그 중 한가지 방법으로는 커널 소스 코드에 있는 drivers/net/Space.c 파일 (드라이버에 대한 모 든 정보를 담고 있다.)에 특정 정보를 변경시키거나 추가시켜 주는 것이다. 여러분이 네트워 킹 코드에 익숙해 있다면 이 방법을 추천해 주고 싶다. 더 나은 방법으로는 부팅할 때, 이 정보를 커널에 제공하는 것이다. 만약 부트 시스템으로 lilo를 사용한다면, lilo.conf 파일에 append 옵션을 명시해 둠으로써 커널에 있는 변수들을 그냥 지나칠 수 있다. 이더넷 장치 를 위한 정보를 커널에 명시하기 위해서는, 다음에 보이는 변수들을 없애줄 수 있다.
ether=irq, base_addr, param1, param2, name
처음 네 개의 변수들은 숫자로 되어 있는 반면에 마지막 변수는 장치명을 뜻하는 것이 다. 모든 숫자값들은 임의로 추가시킬 수 있다; 만약 그것들을 생략하거나 0으로 설정해 두 었다면, 커널은 그 장치를 검사함으로써, 그 값을 감지해내려 하거나 초기값을 사용할 것이 다. 첫 번째 변수는 장치에 할당되어 있는 IRQ를 설정하는 부분이다. 초기값으로, 커널은 장 치의 IRQ 채널을 자동으로 감지할 것이다. 3c503 드라이버는 특별한 형태를 가지고 있다. 이것은 IRQ를 5, 9, 3, 4를 선택하고, 이 라인에서 사용하기 위한 보드를 구성한다. base_addr 변수는 보드에 I/O 베이스 어드레스값을 주는 역할을 한다; 위에서 봤던 어 드레스를 검사하기 위해서는 커널에 0이라는 값을 주어야 한다. 나머지 두 개의 변수들은 다른 형태의 드라이버에서 다르게 사용될 수도 있다. WD80x3 과 같은 공유 메모리 보드를 사용하기 위해서는, 공유 메모리 지역의 시작과 끝 어드레스를 명시해 주어야 한다. 다른 카드는 대개 디버깅 정보를 설정하기 위해서 param1 변수를 사 용한다. 1부터 7까지의 숫자는 그 디버깅 정보의 수준이 증가하는 것을 나타낸다. 반면에 8 은 완전히 다른 역할을 한다; 0은 초기값을 의미한다. 3c503 드라이버는 내부 트랜스시버 (초기값) 또는 외부 트랜스시버 (숫자값은 1)를 선택하기 위해서 param2를 사용한다. 전자 는 보드에 붙어있는 BNC 커넥터를 사용하고, 후자는 AUI 포트를 사용한다. 만약 여러분이 두 개의 이더넷 보드를 가지고 있다면, 리눅스를 자동감지해 주는 하나의 보드를 가질 수 있으며, lilo에서 두 번째 보드의 변수를 지나칠 수 있다. 그러나 여러분은 먼저 드라이버가 실제로 두 번째 보드를 찾는지 확인해야 한다. 그렇지 않으면, 또 다른 하 나가 전혀 등록되지 않는 현상이 발생할 수도 있다. 여러분은 lilo에 있는 reserve 옵션을 그냥 지나치게 함으로써 이러한 문제를 해결할 수 있다. 두 번째 보드에 주어진 I/O 영역의 감지를 피하기 위해서는 커널에 분명히 명시해 두어야 한다. 이를테면, 여러분이 인터페이스가 eth1이고 어드레스 0x300에 있는 이더넷 보드를 리눅 스에 설치하고자 한다면, 여러분은 커널에 있는 다음과 같은 변수를 없애주어야 한다.
reserve=0x300,32 ether=0,0x300,eth1
reserve 옵션은 어떤 장치를 검사할 때, 보드의 I/O 영역에 접근하는 장치가 없는지를 확인한다. 여러분은 또한 eth0를 오토프로빙하는 작업을 무시해 버리기 위해서도 커널 변수 를 사용할 수 있다.
reserve=0x340,32 ether=0,0x340,eth0
완전히 오토프로빙을 해제하기 위해서는, 다음과 같은 변수를 base_addr에 명시해 줄 수 있 다.
ether=0, -1, eth0
3.5 The PLIP DriverPLIP, Parallel Line IP는 여러분이 두 대의 컴퓨터 만을 연결해서 네트워크를 구성하고자 할 때 사용하는 아주 값싼 방법이다. 이것은 패러랠 포트와 10kBps에서 20kBps까지의 속도 를 낼수 있는 특별한 케이블을 사용한다. PLIP는 원래 주식회사 Crynwr에서 제작한 것이다. 이것은 패러랠 포트를 사용하여 PC 에서 장시간동안 네트워크를 하기위해 만들어 졌으며, 단 방향 프린터 포트를 사용한다; 이 것은 PC에서 주변장치로 데이터를 보낼 때 단지 여덟 개의 데이터 라인만을 사용할 수 있 다. PLIP는 입력을 위해서 포트의 다섯가지 상태 라인만을 사용함으로써 이러한 작업을 수 행한다. 그리고 PLIP는 모든 데이터를 4비트씩 전송해야하는 제한 사항을 가지고 있다. 이 러한 운영 모드를 mode zero PLIP라고 부른다. 오늘날, 이러한 단 방향 포트는 더 이상 사 용되지 않고 있다. 그래서, mode 1이라고 부르는 PLIP 확장시킨 것이 나왔는데, 이것은 전 체 8비트 인터페이스를 사용하게끔 제작되었다. 현재, 리눅스는 오직 mode 0만을 지원해 주고 있다. 이것은 PLIP의 초기 코드와는 그 성격이 판이하게 다르다. 지금은 Crynwr에서 수행하는 PLIP와 NCSA telnet. - NCSA telnet는 이더넷 또는 PLIP를 통해 DOS에서 TCPIP를 구현해주는 특별한 프로그램이며, telnet와 FTP를 지원해 주고 있다./에서 사용하는 PLIP 드라이버와 호환성을 갖도록 만들어내고 있는 추세이다. PLIP를 사용해서 두 대의 컴퓨터를 연결하기 위해서는, 몇 몇 가게에서 판매하고 있는 "Null Printer" 또는 "Turbo Laplink" 케이블과 같은 특별한 케이블을 사용해야 한다. 하지만 여러분 자신도 쉽게 이것을 만들 수 있다. 이것에 대한 자세한 사항은 부록 A에 소개하고 있다. 리눅스에서 사용하는 PLIP 드라이버는 무수히 많은 사람들이 이루어낸 성과이다. 이것은 현재 Niibe Yutaka가 관리하고 있다. 만약 이 드라이버가 추가되어 있는 커널이 컴파일되어 있다면, 각 프린터 포트를 위한 네트워크 인터페이스가 설정되어 있을 것이다. plip0는 패러 랠 포트 lp0와 일치하며, plip1은 lp1과 일치한다. 포트에 인터페이스를 매핑하는 작업은 다 음과 같다; 만약 여러분이 다른 방법으로 프린터 포트를 구성하고 있다면, 리눅스 커널 소스 또는 새로운 커널에 있는 drivers/net/Space.c에 있는 값을 변경시켜 주어야 한다. 하지만 이러한 매핑작업으로 인해 평상시 사용하는 패러랠 포트를 사용할 수 있다는 의 미는 아니다. 일치하는 인터페이스가 구성되었을때만 PLIP 드라이버를 엑세스할 수 있다.
3.6 The SLIP and PPP DriversSLIP (Serial Line IP)와 PPP (Point-to-Point Protocol)은 시리얼 라인을 통해 서 IP 패킷을 보내는 프로토콜로 널리 알려져 있다. 리눅스에서는 인터넷에 여러분의 컴퓨터를 접근시키기위해 동적 SLIP 과 PPP연결을 제공해 주고 있다. 그래서 각 사용자에게 IP 연결을 제공해 주고 있다. SLIP와 PPP를 실행하기 위해서, 하드웨어 정보를 수정할 필요는 없다; 여러분은 어떤 시리얼 포트를 사용할 수 있다. 시리얼 포트 환경이 TCP/IP 네트워킹에 명시되어 있지 않 은 관계로 여러 장에서 이것에 대해 기술해 놓고 있다. 더 자세한 정보를 얻고 싶다면, 4장 을 참고하기바란다.
4. Setting up the Serial Hardwarenetland에 사는 몇몇 사람들은 T1 인터넷 링크에 돈을 소비하지 않고, 자신의 PC에 정성을 쏟는다는 유머가 있다. 그럼에도 불구하고, 매일 뉴스와 메일을 받기 위해서, SLIP 링크, UUCP 네트워크, 공용 전화망을 사용하는 전자게시판 시스템에 의존한다고 말하고 있다. 이 장에서는 그러한 연결을 유지하기 위해 모뎀에 의존하는 모든 사람들에게 필요한 정 보를 가져다 줄 것이다. 하지만 이장에서 그러한 모든 정보를 가져다 줄 수 있는 것은 아니 다. 이를테면, 여러분의 모뎀을 다이얼인 방식으로 구현하는 방법같은 것들... 이러한 모든 화제들은 Greg Hankings. - 그의 주소는 gregh@cc.gatech.edu이다. 가 쓴 Serial HOWTO에 기록되어 있을 것이며, 정기적으로 comp.os.linux.announce에 포스팅된다.
4.1 Communication Software for Modem Links리눅스에서 유용하게 사용할 수 있는 몇가지 통신 패키지가 있다. 이것들 대부분이 terminal program이라고 하는 것인데, 이것은 사용자가 다른 컴퓨터에 접속하는 것을 도와 준다. 일반적으로 사용하는 터미널 프로그램으로는 kermit가 있다. 전화번호부와 원격 컴퓨 터 시스템에 접속하거나 전화를 걸어주는 스크립트 언어를 제공해주는 더욱더 안정되고, 유 용한 프로그램들이 얼마든지 있다. 그것들 중에 하나가 minicom이라는 것이 있는데, 이것은 도스에 길들어져 있는 사용자들이 터미널 프로그램을 사용할 수 있게 도와준다. 이러한 프 로그램들 중 seyon이라고 하는 X윈도우용 통신 패키지도 있다. 리눅스용 BBS 패키지들 또한 전자게시판을 구현하려는 많은 사람들에게 도움을 주고 있다. 이러한 패키지 중 일부는 sunsite.unc.edu사이트의 /pub/Linux/system/Network 디 렉토리에서 찾을 수 있다. 터미널 프로그램과는 다르게 여러분의 컴퓨터에서 다른 곳으로 데이터를 전송하기 위해 대화식 시리얼 링크를 사용하는 소프트웨어도 있다. 이 기술을 사용해서 얻는 이점이라면, 몇 수십 킬로바이트 크기의 데이터를 전송받을 때, 이를테면, 메일박스에 있는 온라인 메일 을 받을때나, 게시판에서 재미있는 글을 읽을 때의 시간을 좀더 줄일 수 있다는 것이다. 다 른 한편으로, 여러분이 받는 정보를 적재하지 않기 때문에 더욱더 많은 디스크 공간을 필요 로 한다. 이러한 종류의 전형적인 통신 소프트웨어라고 한다면, 그것은 바로 UUCP일 것이다. 이 것은 이쪽 호스트에서 저쪽 호스트로 파일을 복사할 때나, 원격 호스트에서 프로그램을 실 행시키고자 할 때, 적합한 프로그램이다. 이것은 대개 개개인의 네트워크에서 뉴스나 메일을 받을 때 자주 사용한다. 리눅스에서 실행할 수 있는 Ian Taylor의 UUCP 패키지는 다음 장 에서 설명하겠다. 비대화식 통신 소프트웨어는 Fidonet를 거쳐 사용된다. ifmail과 같은 Fidonet 어플리케이션 포트또한 유용하게 사용할 수 있다. SLIP, serial line Internet protocol은 대화식 (interactive)과 비대화식 프로그램사이에 서 중간 매개 역할을 한다. 많은 사람들이 그들의 대학망을 다이얼업하거나 FTP 세션을 구현 하기 위해 일반적으로 사용하는 공용 SLIP 서버를 위해 SLIP를 사용한다. SLIP은 또한 영 구적으로나 반영구적인 연결방법으로 LAN-to-LAN 커플링을 위해 사용하기도 하며, ISDN 에서도 사용한다.
4.2 Introduction to Serial Devices시리얼 장치를 엑세스하기 위해 제공되는 유닉스 커널 장치를 tty, TeletypeTM이라 고 부른 다. 이것은 초기 유닉스 시절에 터미널 제조 업체중 한군데에서 사용했다. 현재는 문자로 데 이터를 처리하는 터미널 형태로 사용하고 있다. 이 장을 통해서, 우리는 커널 장치에 대한 용어를 정립해 나갈 것이다. 리눅스 배포본에는 세가지 형태의 tty: (가상) 콘솔, pseudo(의사)-터미널 (X11과 같은 어플리케이션으로 사용하는 two-way 파이프와 유사하다.) 그리고 시리얼 장치를 사용한다. 맨 마지막것도 시리얼 연결을 통해서 대화식 세션을 수행하기 때문에 이것도 tty에 포함시 킨다: 이것은 터미널 라인을 통한 하드 와이어드 터미널이나 리모트 컴퓨터에서 유래한 것 이다. Tty는 구성 변수값을 가지고 있으며, 이것은 ioctl(2) 시스템 콜을 사용하도록 설정되어 있다. 이것들 중 다수의 tty는 여러 가지 형태의 연결을 처리하기 위해 더욱더 유연하게 다 룰 필요가 있은 후로, 오직 시리얼 장치에 맞추어져 있다. 가장 특이할 만한 라인 변수에는 라인 속도와 패리티를 들 수 있다. 그리고, 대문자와 소 문자를 변환시켜주는 옵션과 개행문자 (line feed)로 바꾸어주는 옵션도 있다. 또한 tty 드라 이버는 line discipline를 지원해 주는데, 이것은 완전히 다르게 동작하는 장치 드라이버를 만들 때 사용한다. 예를 들어, 리눅스에서 사용하는 SLIP 드라이버를 line discipline로 사용 하기도 한다. 라인의 속도를 측정할 때 사용하는 비트가 있다. 올바른 용어는 Bit rate라고 하는데, 이 것은 라인의 전송 속도를 의미하며, 초당 전송되는 비트수 (bps)를 말하는 것이다. 때때로, 여러분은 사람들에게 Baud rate라고 하는 말을 들었을 것이다. 이것은 그다지 올바른 용어 는 아니다. 이러한 두가지 형태의 용어는 절대 바꾸어서 말할 수 없다. Baud rate라는 말은 몇몇 시리얼 장치의 물리적인 특성을 말하는 것이며, 주로 전송되는 펄스의 클럭수를 말하 는 것이다. Bit rate는 두지점간에 존재하는 시리얼 연결의 현재 상태를 의미하는 것이며, 주로 초당 전송되는 평균 비트 수를 가리킨다. 전기적인 펄스가 발생할 때 생성되는 하나 이상의 비트를 인코드 시키는 대부분의 장치에서는 이 두가지 용어가 다르게 사용된다는 것 을 아는 것은 매우 중요하다.
4.3 Accessing Serial Devices유닉스에서 사용하는 모든 장치와 유사하게, 시리얼 포드또한 특별한 장치 파일을 통해서 엑세스할 수 있다. 그 장치 파일은 /dev 디렉토리에 위치해 있다. 이 장치파일들은 시리얼 드라이버와 각 포트에 연관되어 있는 장치파일의 두가지 양상을 띄고 있다. 이러한 파일에 의존하고 있는 장치들은 완전히 다르게 동작할 것이다. 첫 번째 장치파일은 포트를 통해서 다이얼링인을 할 때마다 사용한다; 네 개의 주번호를 사용하며, 그 이름은 ttyS0, ttyS1등이 있다. 두 번째 장치 파일은 포트를 통해서 다이얼링 아 웃을 할 때 사용되며, 파일 이름은 cua0, cua1을 사용한다. 다섯 개의 주번호를 사용한다. 만약 여러분이 COM1에서 COM4 포트중 하나를 사용한다면, 부 번호는 COM 포트번호 에 63을 더한 값이 될 것이다. 만약 이와 다르게 설정해 놓았거나, 다중 시리얼 라인을 지원 하는 보드를 사용하고 있다면, Serial HOWTO를 읽어보기 바란다. 여러분이 모뎀을 COM2에 맞추어 놓았다고 가정하자. 부번호는 65가 될것이며, 주번호 는 다이얼링 아웃을 위해 5를 사용할 것이며, 장치로는 cua1을 사용해야 한다. /dev 디렉토 리에 시리얼 tty목록이 있다. 다섯 번째와 여섯 번째 칸은 각각의 주 번호와 부 번호를 보 여주는 것이다.
$ ls -l /dev/cua*
crw-rw-rw- 1 root 5, 64 Nov 30 19:31 /dev/cua0
crw-rw-rw- 1 root 5, 65 Nov 30 22:08 /dev/cua1
crw-rw-rw- 1 root 5, 66 Oct 28 11:56 /dev/cua2
crw-rw-rw- 1 root 5, 67 Mar 19 1992 /dev/cua3
이러한 것들이 아무것도 없다면, 루트로 접속해서, 이러한 것을 만들어 주어야 한다
# mknod -m 666 /dev/cua1 c 5 65
# chown root.root /dev/cua1
어떤 사람들은 사용자들이 모뎀이 위치한 포트가 cua1이라는 것을 기억하지 않아도 되 도록 /dev/modem에 심볼릭 링크를 만들기를 권하기도 한다. 그러나 어떤 프로그램에서는 이 modem이라는 장치를 사용할 수 없고, 실제 장치명을 사용해야 하는 경우도 있다. 이러 한 프로그램들은 그 장치가 사용하는 신호에 이른바 lock files라는 것을 사용하기 때문이다. 관례에 따르면, cua1을 사용하는 잠금 파일은 LCK...cua1이 된다. 같은 포트를 대해 다른 장 치 파일을 사용한다는 것은 프로그램들이 각각의 다른 lock file들을 인식하지 못하고 있으 며, 동시에 장치 파일들을 사용한다는 의미이다. 결과적으로 보면, 어플리케이션들은 전혀 작동하지 않을 것이다.
4.4 Serial Hardware현재 리눅스에서는 RS-232를 표준으로 사용하는 거의 모든 시리얼 보드를 지원해 주고 있 다. RS-232는 현재 PC 시장에서 사용되는 모든 시리얼 통신의 표준 규격이다. 이것은 단독 비트 전송 뿐만아니라 비트 동기를 위한 몇몇 회로들을 사용한다. 추가로 사용되는 라인들 은 모뎀에서 사용하는 반송파와 handshake의 존재 유무를 나타내주기 위한 것이다. 비록 하드웨어 handshake를 임의로 사용하는 것이지만, 매우 유용하게 쓰인다. 이것은 데이터를 받을 준비가 되어 있는지를 나타내 주는 상태와 수신자가 들어오는 데이터를 처리 할때까지 잠시 멈추어 있어야 하는 상태가 있다. 이러한 상태를 각각 "Clear to Send" (CTS) 와 "Ready to Send" (RTS)라고 부르며, 일반적으로 하드웨어 handshake 로써, 주로 "RTS/CTS"라고 부른다. PC에서, RS-232 인터페이스는 대개 National Semiconductor 16450 칩 또는 이것의 새로 운 버전인 NSC 16550A. - NSC 16550이라는 것도 있지만, 이것의 FIFO는 절대 작동 하지 않는다.에서 유래한 UART 칩을 사용한다. 몇몇 제품들 (Rockwell 칩셋을 사용하는 대부분의 내장형 모뎀)은 완전히 다른 칩을 사용하고 있으며, 그 칩은 마치 16550 인 것처럼 작동하도록 프로그램되어 있다. 16450칩과 16550칩의 주요 차이점이라고 한다면, 후자는 16 바이트 FIFO 버퍼를 가지고 있는 반면, 전자는 단지 1 바이트 버퍼를 가지고 있다는 것이다. 즉 16450칩은 최고 속도 9600 보드에 적합하게 만들어져 있는 반면, 16550 호환 칩은 그 이상의 속도를 필요로 한다. 리눅스는 원래 UART 칩이였던 8250 칩도 지원한다. 커널이 기본 환경설정을 할 때, COM1에서 COM4까지 네 개의 표준 시리얼 포트를 확 인한다. 이전에 설명했듯이 이 포트들은 부번호 64에서 67까지의 장치를 할당받을 것이다. 여러분이 시리얼 포트를 적절하게 구성하려 한다면, rc.serial 스크립트에 Ted Tso의 setserial 명령을 설치해야 한다. 시스템 부팅시에 이 스크립트는 /etc/rc를 호출할 것이다. 전형적인 rc.serial 스크립트는 다음과 같다:
# /etc/rc.serial - serial line configuration script.
#
# Do wild interrupt detection
/sbin/setserial -W /dev/cua*
# Configure serial devices
/sbin/setserial /dev/cua0 auto_irq skip_test autoconfig
/sbin/setserial /dev/cua1 auto_irq skip_test autoconfig
/sbin/setserial /dev/cua2 auto_irq skip_test autoconfig
/sbin/setserial /dev/cua3 auto_irq skip_test autoconfig
# Display serial device configuration
/sbin/netserial -bg /dev/cua*
각 변수에 대한 설명을 알고 싶다면, setserial에 함께 따라오는 문서를 읽어보기 바란다. 만약 여러분의 시리얼 카드가 감지되지 않았거나, setserial -bg 명령어가 잘못된 설 정을 화면에 출력한다면, 여러분이 직접 그 구성환경을 설정해 주어야 한다. Rockwell(라겔) 칩셋 을 가지고 있는 내장형 모뎀을 사용하는 사용자들이 이 문제에 대해 보고해 주었다. 예를들 어 UART 칩이 NSC 16450으로 보고되었다면, 사실 그것은 NSC 16550 호환칩이다. 여기서 여러분은 다음과 같이 구성 명령을 바꾸어 주어야 한다.
/sbin/setserial /dev/cua1 auto_irq skip_test autoconfig uart 16550
COM 포트, 베이스 어드레스 그리고 IRQ 설정을 변경하는 옵션도 이와 유사하다. 이것 에 대해서는 setserial(8) 매뉴얼 페이지를 참고하기 바란다. 여러분의 모뎀이 하드웨어 핸드셰이크를 지원하고 있다면, 그것이 사용가능한지를 확인 해야 한다. 대부분의 통신 프로그램들은 이것을 사용가능하게 만들어 주지 않는다. 꼭 여러 분이 수동으로 설정해 주어야 한다. stty 명령을 사용하면, rc.serial 스크립트에서 가장 잘 수행된다:
$ stty srtscts < /dev/cua1
하드웨어 핸드셰이크를 효과적으로 검사하기 위해서는 다음과 같이 설정해 주어라.
$ stty -a < /dev/dua1
이것은 여러분에게 장치를 위한 모든 옵션을 보여줄 것이다; 옵션앞에는 꼭 '-'를 붙여 준다. 예를 들어 -crtscts옵션은 그것이 꺼져있다는 것을 의미한다.
5. Configuring TCP/IP Networking이 장에서는 여러분의 컴퓨터에서 TCP/IP 네트워킹 설정에 필요한 모든 사항들을 다루어 불 생각이다. IP 주소 할당을 시작으로 해서, 천천히 TCP/IP 네트워킹 인터페이스의 환경구 성을 해나갈 것이다. 그리고 여러분이 네트워크 설치를 할 때 발생하는 여러 가지 문제를 해결하기 위해 유용하게 사용할 수 있는 몇가지 도구도 소개할 생각이다. 이 장에서 하는 대부분의 작업은 일반적으로 한번은 해야 할 작업이다. 여러분의 네트워 크에 새로운 시스템을 추가시키거나 시스템 전체를 재구성할 때, 대부분의 구성파일들을 손 봐주어야 한다. TCP/IP를 구성하기 위해 사용하는 어떤 명령들은 시스템이 부팅되는 시간 에 실행된다. 시스템 부팅시 실행되는 파일들은 /etc/rc 스크립트에서 불러온다. 이 스크립트에서 네트워크와 관계되어 있는 내용을 기술해 놓은 파일을 rc.net 또는 rc.inet라고 한다. 때때로, 여러분은 rc.inet1 과 rc.inet2라고 하는 두 개의 스크립트를 볼 수 도 있을 것이다. 전자가 커널의 네트워킹 부분을 초기화 시키는 반면, 후자는 기본적인 네트워킹 서비스와 어플리케이션을 실행시키는 역할을 한다. 지금 부터는 후자와 관계된 내용만을 다룰 생각이다. 이 장에서는 rc.inet1 스크립트가 수행하는 작업에 대해 다룰 것이고, 다음 장(6장)에서 는 그것과 관계되어 있는 어플리케이션에 대해 다룰 것이다. 여러분이 이 장을 다 읽어 본 다 면, 여러분의 컴퓨터에 TCP/IP 네트워킹을 적절하게 구성할 수 있을 것이다. 그럼 먼저, rc.inet1에 있는 예제 명령을 사용해서 스크립트를 구성하라. 그리고 나서, 시동 시간에 rc.inet1이 실행되는지 확인하고 컴퓨터를 재부팅하라. 여러분이 좋아하는 리눅 스 배 포본에 rc 스크립트와 관련되어 있는 좋은 예제 파일이 있을 것이다.
5.1 Setting up the proc FilesystemNet-2 배포본의 몇몇 구성 도구는 proc 파일시스템에 의존하고 있다. 이것은 파일시스템과 같은 메카니즘을 통해서 커널로 run-time 정보를 엑세스하게 하는 인터페이스이다. 마운트 되면, 여러분은 다른 파일시스템에서와 같이 파일을 나열하거나 그 내용을 볼 수 있다. 시스 템 평균 적재량을 나타내는 loadavg 파일과 meminfo를 포함하고 있는 항목들은 현재 core 메모리와 스왑 사용법을 나타내 준다. 여기에 사용되는 네트워킹 코드는 net 디렉토리를 추가한다. 이 디렉토리에는 커널 ARP 테이블, TCP/IP 연결 상태, 그리고 라우팅 테이블과 같은 몇 개의 파일을 포함한다. 대부분 의 네트워크 관리 도구들은 이들 파일로부터 그와 관련되어 있는 정보를 얻는다. proc 파일 시스템 (또는 procfs 로도 알려져 있다.)은 대개 부팅시간에 /proc와 마운트된 다. 가장 좋은 방법은 /etc/fstab에 다음과 같은 라인을 추가시켜 주는 것이다.
# procfs mont point:
none /proc proc defaults
그리고, /etc/rc 스크립트에서 "mount /proc"를 실행시킨다. 요즈음에 와서 procfs는 대부분의 커널에서 기본값으로 설정되어 있다. 만약 procfs가 여 러분의 커널에 있지 않다면, 여러분은 "mount: fs type procfs not supported by kernel" 과 같은 메시지를 얻을 것이다. 이럴 때는 커널을 재 컴파일하고 그 과정에서 procfs 지원 여 부를 묻는 질문에, 'y'라고 답해야 한다.
5.2 Installing the Binaries만약 여러분이 이전에 패키지화된 리눅스 배포본을 사용하고 있다면, 그것은 아마도 네트워 킹 어플리케이션과 유틸리티에 따라오는 예제파일을 포함할 것이다. 그러한 경우에만, 여러 분이 새로운 커널 배포본을 설치하고자 할 때, 새로운 유틸리티를 구하던지 다시 설치를 해 주어야 한다. 새로운 커널은 때때로 변경된 커널 네트워킹 층에 관한 정보를 포함하는 경우 도 있다. 이러한 경우에 여러분은 기본 구성 도구를 갱신해주어야 한다. 어쩌면, 커널을 재 컴파일 하는 경우에만 최신 바이너리 패키지가 필요한 경우도 있다. 이것들은 대개 커널과 함께 net-XXX.tar.gz라는 이름으로 압축되어 배포된다. XXX는 버전 번호이다. 리눅 스 1.0 에 맞는 배포본은 0.32b이며, 1.1.12버전 이후의 커널은 0.32d를 필요로 한다. 여러분 힘으로 표준 TCP/IP 네트워크 어플리케이션을 설치하고 컴파일하고자 한다면, 여러분은 대부분의 리눅스 FTP 사이트에서 커널 소스를 구할 수 있다. Net-BSD 또는 다 른 소스에서는 다소 심하게 패치한 것도 있다. Xmosaic, xarchie 또는 Gopher과 IRC 클라 이언트와 같은 어플리케이션들은 개별적으로 구해야 한다. Net-3의 공식 FTP 사이트는 sunsite.unc.edu 이며, 그 아래 system/Network/sunacm에 미러되어 있는 sunacm.swan.ac.uk도 있다. 최신 Net-2e 패치 킷과 바이너리들은 ftp.aris.com 에서 찾아 볼 수 있다. BSD에서 파생된 Matthias Urlichs의 네트워킹 코드는 ftp.ira.uka.de에 있는 /pub/system/linux/netbsd에서 구할 수 있을 것이다.
5.3 Another Example이 책의 나머지 부분에서는 Groucho Marx University보다 조금 더 단순한 예를 들기로 하 겠다. 그리고 여러분이 실제로 부딪치게될 작업에 조금더 가까이 가보기로 하겠다. virtual beer를 양조하는 Virtual Brewery라고 하는 조그마한 회사가 있다고 가정하자. 그들의 사업 을 더욱더 효과적으로 관리하기 위해서, virtual 양조자가 그들의 컴퓨터를 네트워크에 연결 하려고 한다. 그리고 네트워크에 연결하고자 하는 컴퓨터는 리눅스 1.0을 구동시키려 한다. 양조장 건물 건너편에는 그와 비슷한 일을 하는 Virtual Winery가 있다. 여기서는 그들 자체내에 이더넷을 가지고 있다. 두 회사는 경영상의 목적으로 그들만의 네트워크를 구성하 려고 한다. 첫 단계로써, 두 서브넷 사이에서 데이터를 전송하기 위해 게이트웨이 호스트 컴 퓨터를 설정할 것이고, 메일과 뉴스를 교환하기 위해, UUCP를 바깥 세상에 링크시키려 할 것이다. 그리고 가끔 인터넷과의 연결을 위해서 SLIP 연결을 설정하려 할 것이다.
5.4 Setting the Hostname비록 전부다 그렇다고 할 순 없지만, 대부분의 네트워크 어플리케이션은 로컬 네트워크명에 의존하고 있으며, 이치에 맞는 값으로 설정되어 있다. 이것은 대개 부팅할 동안 hostname 명령을 실행시킴으로써 설정된다. hostname에 이름을 설정하기 위해서는 다음과 같이 해야 한다.
# hostname name
이것을 위해서는 도메인네임없는 호스트명 (unqualified hostname)을 사용하는 것이 실 용적이다. 이를테면, Virtual Brewery에 있는 호스트는 vale.vbrew.com 또는 vlager.vbrew.com을 사용할 수도 있다. 이것들은 공식적으로 사용 하는 이름이며, fully qualified domain name (FQDN)이다. 그들의 로컬 호스트네임은 vale 와 같은 첫 번째 이름이 될 것이다. 하지만 로컬 호스트네임은 호스트의 IP 주소를 찾아내 는데에 자주 사용되기 때문에, 여러분은 resolver library가 호스트의 IP 주소를 찾아낼 수 있는지를 확인해야 한다. 즉, 이것은 여러분이 /etc/hosts에 그 이름을 입력해 주어야 된다 는 의미이다. 몇몇 사람들은 FQDN의 나머지 부분에 도메인 네임을 설정하기 위해서, domainname이 라는 명령어를 사용하라고 제안하기도 한다. 이 방법으로 여러분은 hostname과 domainname에서 나오는 결과물을 조합해서, 다시 FQDN을 얻을 수 있다. 하지만 이것이 최고의 방법은 아니다. 호스트의 NIS 도메인을 설정하기 위해서 일반적으로 domainname 명령을 사용한다. 이 도메인은 여러분이 속해 있는 도메인과는 다르다. NIS는 10장에서 다 루기로 하겠다.
5.5 Assigning IP Addresses여러분의 호스트에서 standalone operation (이를테면, INN 넷뉴스 소프트웨어를 실행할 수 있어야 한다.)을 위한 네트워킹 소프트웨어를 구성한다면, 이절을 읽지 않아도 된다. 왜냐하 면, 여러분에게 필요한 것은 루프백 인터페이스 (항상 127.0.0.1이다.)를 위한 IP 주소만을 필요로 하기 때문이다. 이더넷과 같은 실제 네트워크에서는 좀더 복잡한 작업을 필요로 한다. 여러분의 호스트 를 실제 존재하고 있는 네트워크에 연결하기 하고자 한다면, 접속하고자 하는 네트워크에서 IP 주소를 받을 수 있는지 관리자에게 물어 보아야 한다. 여러분이 직접 모든 네트워크를 설정한다면, 이전에 설명한 대로 여러분 자신에게 IP 주소를 할당해 주어야 한다. 로컬 네트워크에 있는 호스트들은 대개 같은 논리적인 IP 네트워크와 주소를 공유해야 한다. 즉 여러분이 IP 네트워크 주소를 할당해 주어야 한다. 만약 여러분이 여러 가지 물리 적인 네트워크를 가지고 있다면, 다른 네트워크 번호를 그것들에게 할당해 주거나, 하나의 IP 주소를 여러 서브네트워크로 쪼개기 위해 서브네트워킹을 사용해야 한다. 여러분의 네트 워크가 인터넷에 연결되어 있지 않다면, 네트워크 주소를 마음대로 선택할 수 있다. 여러분 이 클래스 A, B 또는 C 중 하나를 선택하지 않았다면, 그 네트워크는 정확하게 작동하지 않을 것이다. 하지만, 여러분이 가까운 미래에, 인터넷을 사용할 생각이라면, 공식 IP 주소를 구해야 한다. 가장 최선의 방법은 여러분의 네트워크 서비스 프로바이더에게 물어보는 것이 다. 여러분이 인터넷에 접속할 경우에만 네트워크 번호를 구하고자 할 경우, hostmaster@internic.net으로부터 Network Address Application Form을 구해야 한다. 여러 가지 이더넷을 운영하기 위해서는 여러분의 네트워크를 서브넷으로 갈라놓아야 한 다. 서브넷팅은 단지 여러분이 하나 이상의 broadcast network를 가지고 있을 때만 필요하 다는 것을 알아 두어라; 여기서 point-to-point 링크는 생각하지 않는다. 예를 들어, 여러분 이 이더넷을 가지고 있고, 하나 이상의 SLIP를 바깥세상과 연결시키고자 한다면, 여러분의 네트워크를 서브넷으로 갈라 놓지 않아도 된다. 그 이유는 7장에서 설명하기로 하겠다. 한가지 예로, 양조장의 네트워크 관리자가 클래스 B에 해당하는 네트워크 번호를 NIC에 게 요청하고 나서 192.72.0.0을 부여받았다. 두 개의 이더넷을 수용하기 위해서, 관리 자는 추가적으로 서브넷 비트에 있는 호스트 부분에 해당하는 8 비트를 사용하기로 결정한다. 이 렇게 되면, 각 서브넷에 254개의 호스트를 부여할 수 있는 8 비트를 또 다시 가지게 된다. 그리고 나서, 관리자는 서브넷 번호로 brewery에게 1을, winery에게 2라는 번호를 할당한 다. 그러면, 각 네트워크 주소는 191.72.1.0과 191.72.2.0이 되며, 서브넷 마스크는 255.255.255.0이 될 것이다. 두 개의 네트워크에서 게이트웨이 역할을 하고 있는 vlager은 그것들 중 1이라는 호스 트 번호를 할당받았으며, IP 주소로는 각각 191.72.1.1과 191.72.2.1을 주었다. 그림 5.1은 두 개의 서브넷과 게이트웨이를 보여준다.
Figure 5.1: Virtual Brewery and Virtual Winery - the two subnets.
이 예제에서 나는 쉽게 이것을 유지하기 위해 클래스 B 네트워크를 사용하고 있다; 클래 스 C 네트워크가 조금더 현실적이다. 새로운 네트워킹 코드를 가지고 있는 서브넷팅은 바이 트 바운더리에 제한되어 있지 않다. 그래서, 심지어 클래스 C 네트워크를 여러개의 서브넷 으로 나누기도 한다. 이를테면, 여러분은 넷마스크에서 호스트 부분에 해당하는 2비트를 사 용할 수 있다. 그렇게 되면, 각 네 개의 서브넷에 64개의 호스트를 부여할 수 있게 된다. - 각 서브넷의 마지막 숫자는 브로드캐스트 주소로 예약되어 있다. 그래서 사실상 각 서브넷마다 63개의 호스트를 부여할 수 있다.
5.6 Writing hosts and networks Files여러분의 네트워크를 서브넷으로 나눈후, /etc/hosts 파일을 사용하기 위해서 몇가지 호스트 네임 리솔루션(hostname resolution)을 준비해야 한다. 만약 DNS나 address resolution을 위 한 NIS를 사용할 생각이 아니라면, hosts 파일에 모든 호스트를 넣어 두어야 한다. 비록 여러분이 정상작동하에서 DNS나 NIS를 실행하고자 하는 경우에라로, /etc/hosts에 있는 모든 호스트네임의 서브넷을 가지고 싶어할 지도 모른다. 한가지 예를 들어, 부팅시에 아무런 네트워크 인터페이스가 실행되고 있지 않다 하더라도, 여러분은 name resolution을 가지고 싶어 할 것이다. 이것이 매우 편한 것일 뿐만아니라, rc.inet 스크립트에서 상징화된 호스트네임을 사용하도록 허락해 준다. 그래서, IP 주소들을 변경하고자 할 때, 거대한 rc 파일을 개별적으로 편집하는 대신, 갱신된 hosts파일을 모든 컴퓨터에 복사하고 나서, 재부 팅해야 한다. 대개, 여러분은 hosts에 모든 로컬 호스트네임과 주소를 넣어 둘 것이다. 그리 고 만약 사용한다면, 게이트웨이와 NIC 서버도 추가시켜야 한다. - 만약 여러분이 Peter Eriksson의 NYS를 사용한다면, 어떤 NIS 서버의 주소가 필요 할 것 이다. ypbind를 사용한 다른 NIS 수행작업은 실행시간에 그들의 서버에 위치한다. 초기화 테스트동안에, 여러분의 resolver가 오직 hosts 파일에서 정보를 사용하는지 확인 해야 한다. 여러분의 DNS 또는 NIS 소프트웨어는 그것들이 사용되었을 때, 이상한 결과를 초래하는 예제파일과 같을지도 모른다. 호스트의 IP 주소를 찾을 때, 오직 /etc/hosts를 사 용하는 모든 어플리케이션을 |