여러분은 아래에 나오는 부분들을 알아야 할 필요가 있으며 실제로 여러분의 네트웍을 설정해보기 전에 이해해야 한다. 여러분이 사용할 네트웍의 정확한 특성에 관계없이 작동하는 기본적인 원리들이다.
네트웍을 설정하거나 꾸미기 전에 여러분은 몇가지 필요한 것이 있다. 그 중 가장 중요한 것들은 다음과 같다.
주의사항:
대부분의 최신 리눅스 배포판들은 네트워킹 지원이 가능한 상태로 나온다. 따라서 커널을 다시 컴파일할 필요는 없다. 만약 여러분이 3COM NIC나 NE200 NIC, 인텔 NIC 등의 잘 알려진 하드웨어를 사용한다면 아무 문제가 없을 것이다. 그러나 커널을 업데이트 해야 하는 상황에 놓여있다면 다음의 정보가 제공된다.
지금 돌리고 있는 커널이 여러분이 사용하고자 하는 네트웍 형식이나 카드에 대한 지원을 가지고 있지 않기 때문에 여러분은 알맞은 옵션으로 커널을 다시 컴파일하기 위해 커널 소스가 필요할 것이다.
Redhat이나 Caldera, Debian, Suse 같은 주요 배포본의 사용자들에겐 더이상 적용되지 않는다. 일반적으로 많이 사용하는 하드웨어를 사용한다면 매우 특별한 기능을 원치 않는 한 커널을 다시 컴파일할 필욘 없다.
여러분은 언제나 ftp.cdrom.com로부터 최신의 커널 소스를 얻을 수 있다. 이곳이 공식 사이트는 아니지만 훨씬 큰 bandwidth와 더 많은 동시사용자 수를 가지고 있다. 공식 사이트는 kernel.org 이지만 가능한한 위의 것을 이용하라. ftp.kernel.org 는 매우 붐빈다는 것을 상기하고 미러들을 이용하라.
보통 커널 소스는 /usr/src/linux 디렉토리에 풀려진다. 패치를
적용시키고 커널을 빌드하는 방법에 대한 정보를 얻기 위해선
Kernel-HOWTO를 읽어라. 커널 모듈 설정에
관한 정보를 위해선 ``Modules mini-HOWTO''를 읽어라. 또한 커널 소스 안의
README와 Documentation 디렉토리도 용감한 독자들에겐 매우
유익할 것이다.
특별히 따로 언급되지 않는 한 나는 여러분들이 안전을 위해 안정 커널 릴리즈 (버젼 번호의 두 번째 숫자가 짝수인 것)을 고수할 것을 추천한다. 개발 커널 릴리즈(버전 번호의 두 번째 숫자가 홀수인 것)은 여러분의 시스템의 다른 소프트웨어들과 함께 작동하는 데 있어 문제를 일으킬지도 모르는 구조적 혹은 여타 변화된 사항을 가지고 있을 수 있다. 여러분이 앞으로 있을 지 모를 소프트웨어 에러를 포함해 이 문제들을 해결할 수 있다고 확신하지 않는 한 이를 사용하지 말아라.
네트워크 툴들은 리눅스 네트웍 장치들을 설정하는 데 사용하는 프로그램들이다. 예를 들어 이 툴들을 이용하여 장치들에 주소를 할당하고 라우팅 정보를 설정할 수 있다.
대부분의 현대 리눅스 배포본은 네트웍 툴과 함께 제공되므로 만약 배포본을 깐 후 아직 네트워크 툴들 인스톨하지 않았다면 인스톨 해야 한다.
만약 배포본으로부터 인스톨하지 않았다면 소스를 구해서 직접 툴들을 컴파일해야 한다. 이는 어럽지 않다.
네트웍 툴들은 현재 Bernd Eckenfels에 의해 관리되고 있으며 ftp.inka.de에서 구할 수 있고 ftp.uk.linux.org에서 미러링되고 있다.
또한 net-tools-1.51-3.i386.rpm에서 최신의 RedHat 패키지를 구할 수 있다.
여러분이 사용하려 하는 커널에 알맞는 버젼을 선택하도록 주의하고 설치하기 위해선 패키지 안의 지시를 따른다.
이 글을 쓰는 현재의 최신 버젼을 설정하고 설치하기 위한 방법은 아래와 같다.
user% tar xvzf net-tools-1.33.tar.gz
user% cd net-tools-1.33
user% make config
user% make
root# make install
혹은 Redhat 패키지를 이용하기 위해선
root# rpm -U net-tools-1.51-3.i386.rpm
추가적으로 방화벽을 설정하거나 IP 마스커레이드 기능을 사용하길 윈한다면 ipfwadm 프로그램이 필요하다. 최신 버젼은 ftp.xos.nl 에서 구할 수 있다. 역시 많은 버젼이 존재하므로 여러분이 사용하는 커널에 가장 알맞는 것을 구하도록 한다. 리눅스의 방화벽 기능은 2.1의 개발동안 바뀌었고 커널 v2.2에서는 ipchains에 의해 계승되었다. ipfwadm은 커널 버젼 2.0에만 적용된다. 다음은 2.0 이하 버젼의 커널이 들어있는 배포본들이다.
Redhat 5.2 or below
Caldera pre version 2.2
Slackware pre version 4.x
Debian pre version 2.x
이 글을 쓰는 시점의 최신 버전을 설정하고 설치하기 위해선 The Linux Documentation Project 에 있는 IPChains howto를 읽을 필요가 있다.
만약 커널 버젼 2.2(혹은 2.1 이후)를 사용한다면 ipfwadm 은 방화벽 설정에 알맞은 툴이 아니다. 이 NET-3-HOWTO는 현재 새 방화벽 구성을 다루지 않고 있다. ipchain에 대한 자세한 정보를 원한다면 위의 문서를 참고하여라.
네트웍 응용 프로그램들은 telnet과 ftp 그리고 그에
관련된 서버 프로그램들이다. David Holland는 이것들의 가장 대표적인 배포본을
관리해 왔고 현재 netbug@ftp.uk.linux.org에서 관리되고 있다. 이 배포본은
ftp.uk.linux.org에서 구할 수 있다.
인터넷 프로토콜 주소(IP Address)는 네 바이트로 이루어져 있으며 편의상 `dotted decimal notation' - 직역하자면 점으로 구분되는 10진수 표기법 - 으로 표기된다. 이 형식에서 각 바이트는 0부터 255까지의 십진수로 바뀌며 각 바이트는 `.'으로 구분되어진다. 편의상 호스트나 라우터의 각각의 인터페이스는 IP 주소를 갖는다. 한 머신의 서로 다른 인터페이스들이 같은 IP 주소를 갖을 수도 있으나 보통은 각각의 인터페이스는 자신만의 주소를 갖는다.
인터넷 프로토콜 네트웍은 IP 주소들의 끊임없는 연속이다. 한 네트웍 안의 모든 주소들은 많은 숫자들을 공통적으로 가지고 있다. 그 네트웍 안의 모든 주소들 중에 공통적인 부분을 주소의 `network portion' 이라 부르고 나머지 숫자들을 `host portion' 이라 부른다. 한 네트웍 안의 모든 주소들에 의해 공유되는 bit 수를 넷마스크라 부르고 어느 주소가 해당 네트웍에 속해있는지 아닌지를 판단하는 것이 넷마스크의 역할이다. 예를 들어 아래를 보자.
----------------- ---------------
Host Address 192.168.110.23
Network Mask 255.255.255.0
Network Portion 192.168.110.
Host portion .23
----------------- ---------------
Network Address 192.168.110.0
Broadcast Address 192.168.110.255
----------------- ---------------
해당 넷마스크와 `bitwise anded'된 모든 주소들은 자신이 속한 네트웍 주소를 나타낸다. 따라서 네트웍 주소는 항상 그 네트웍의 주소 범위에서 최소값을 갖는 주소이며 host portion은 항상 모두 0이다.
브로드캐스트 주소는 그 네트웍 상의 모든 호스트들이 자신의 주소외에도 들을
수 있는 특별한 주소다. 네트웍 상의 모든 호스트가 정보를 받도록 하고 싶을 때
그 정보를 이 주소로 보낸다. 라우팅 정보나 경고 메시지 같은 특정 종류의
데이타그램들은 브로드캐스팅 주소로 보내어져서 네트웍 상의 모든 호스트들이
동시에 받을 수 있도록 한다. 브로드캐스트 주소에 대해선 널리 사용되는 두 가지
표준이 있다. 가장 많이 쓰이는 것은 한 네트웍상에서 가능한 제일 큰 주소를
브로드캐스트 주소로 사용하는 것이다. 위의 예에선 192.168.110.255가
될 것이다. 몇몇 이유 때문에 다른 사이트들은 네트웍 주소를 브로드캐스트 주소로
사용하는 방법을 이용한다. 실제로 어느 것을 사용하는 지는 별 문제가 되지 않지만
네트웍 상의 모든 호스트들이 같은 브로드캐스트 주소를 사용하도록 주의하여야
한다.
관리상의 이유 때문에 IP 프로토콜의 발전 초기에 임의의 주소들의 그룹들이 네트웍을 형성하게 되었고 이 네트웍들은 클래스라 불리우는 것으로 구분되어졌다. 이 클래스들은 할당 가능한 네트웍의 표준적인 크기를 규정하고 있다. 할당된 범위는 아래와 다음과 같다.
----------------------------------------------------------
| Network | Netmask | Network Addresses |
| Class | | |
----------------------------------------------------------
| A | 255.0.0.0 | 0.0.0.0 - 127.255.255.255 |
| B | 255.255.0.0 | 128.0.0.0 - 191.255.255.255 |
| C | 255.255.255.0 | 192.0.0.0 - 223.255.255.255 |
|Multicast| 240.0.0.0 | 224.0.0.0 - 239.255.255.255 |
----------------------------------------------------------
여러분이 사용해야할 주소들은 여러분이 하려는 것에 따라 달라진다. 필요한 모든 주소들을 얻기 위해선 아래의 작업들을 수행해야 할 것이다.
만약 여러분이 이미 존재하는 IP 네트웍 상에 리눅스 머신을 설치하고자 한다면 네트웍 관리자에게 가서 다음 정보들을 물어봐야 한다.
그리곤 여러분의 리눅스 네트웍 장치들을 위의 값들을 가지고 설정한다. 이 값들을 임의로 만들어 낸 후에 설정들이 동작하리라고 기대해선 안된다.
만약 여러분이 개인적인 네트웍을 구성하고 인터넷에 연결하지 않을 계획이라면 여러분이 좋아하는 어떤 주소라도 선택할 수 있다. 그러나 안전성과 일관성의 이유 때문에 이런 목적을 위해 특별히 예비되어 있는 IP 네트웍 주소들이 있다. RFC1597에 자세히 나와있으며 다음의 것들이다.
-----------------------------------------------------------
| RESERVED PRIVATE NETWORK ALLOCATIONS |
-----------------------------------------------------------
| Network | Netmask | Network Addresses |
| Class | | |
-----------------------------------------------------------
| A | 255.0.0.0 | 10.0.0.0 - 10.255.255.255 |
| B | 255.255.0.0 | 172.16.0.0 - 172.31.255.255 |
| C | 255.255.255.0 | 192.168.0.0 - 192.168.255.255 |
-----------------------------------------------------------
여러분은 우선 여러분의 네트웍의 크기를 결정해야 하고 그 다음에 필요한 만큼의 주소를 고른다.
리눅스 시스템의 부트 과정에는 몇 개의 다른 방식이 있다. 커널이 부팅된 후
항상 `init'라 불리는 프로그램이 실행된다. init 프로그램은
/etc/inittab라는 자신의 설정 파일을 읽어들인 후 부트 과정을
시작한다. 모든 사람들이 Miguel van Smoorenburg에 의해 개발된 System V (Five)
방식으로 수렴하고 있지만 몇개의 서로 다른 init 방식이 있다.
init 프로그램은 항상 동일하다는 사실에도 불구하고 각각의 배포본에서 시스템 부트의 구성은 다른 방식으로 설정된다.
일반적으로 /etc/inittab 파일은 아래와 같은 엔트리들을 포함하고 있다.
si::sysinit:/etc/init.d/boot
이 줄은 부트 과정을 실제적으로 처리하는 쉘 스크립트 파일의 이름을 명시한다.
이 파일은 MS-DOS의 AUTOEXEC.BAT 파일과 어떤 면에서 같은 것이다.
부트 스크립트라 불리는 다른 스크립트들도 일반적으로 존재하며 종종 이 많은 것들 중 하나 속에서 네트웍이 설정된다.
아래의 표는 여러분의 시스템에 대해 알려준다.
---------------------------------------------------------------------------
배포본 | Interface Config/Routing | Server Initialization
---------------------------------------------------------------------------
Debian | /etc/init.d/network | /etc/rc2.d/*
---------------------------------------------------------------------------
Slackware| /etc/rc.d/rc.inet1 | /etc/rc.d/rc.inet2
---------------------------------------------------------------------------
RedHat | /etc/rc.d/init.d/network | /etc/rc.d/rc3.d/*
---------------------------------------------------------------------------
Debian과 RedHat이 시스템의 서비스를 시작하는 호스트 스크립트들에 디렉토리
전체를 사용하고 있다는 것을 주목하라. (보통 정보는 이 파일들 안에 들어있지
않다. 예를 들어 RedHat 시스템은 모든 시스템 설정들을 /etc/sysconfig
안의 파일들에 보관한다.) 만약 부트 과정의 자세한 사항을 알고 싶다면
/etc/inittab과 init에 동반하는 문서를 들여다 볼 것을
권한다. 리눅스 저널 또한 시스템 초기화에 대한 글을 내놓을 예정이며 본 문서는
그 글이 웹에 올라오는 데로 링크시킬 것이다.
대부분의 요즘의 배포본은 많은 일반적인 네트웍 인터페이스들을 설정할 수 있는 프로그램들을 포함하고 있다. 이들중 하나를 가지고 있다면 손으로 직접 설정을 하기 전에 이 것들이 여러분이 원하는 것을 할 수 있는지를 먼저 보라.
-----------------------------------------
배포본 | 네트웍 설정 프로그램
-----------------------------------------
RedHat | /usr/bin/netcfg
Slackware | /sbin/netconfig
-----------------------------------------
많은 유닉스 운영체제에서는 네트웍 장치를 /dev에서 볼 수 있지만 리눅스에서는 아니다. 리눅스에서 네트웍 장치는 소프트웨어에서 동적으로 많들어 지며 장치 파일이 존재할 필요가 없다.
대부분의 경우에 네트웍 장치는 하드웨어의 위치를 정하고 초기화하는 동안 장치
드라이버에 의해 자동으로 생성된다. 예를 들어 이더넷 장치 드라이버는
eth[0..n] 인터페이스를 이더넷 하드웨어의 위치를 정하면서 순차적으로
생성한다.
그러나 slip과 ppp 같은 몇몇 경우에는 네트웍 장치는 유저 프로그램의 작동에 의해 만들어진다. 역시 순차적인 장치 번호가 메겨지지만 장치들이 부팅 시에 자동으로 생성되진 않는다. 이러한 이유는 이더넷 장치와는 달리 동작중인 slip 이나 ppp 장치들의 수가 머신의 가동 시간 동안 바뀔 수 있기 때문이다.
여러분이 필요한 프로그램과 주소, 네트웍 정보를 모두 가지고 있다면 네트웍 인터페이스를 설정할 수 있다. 네트웍 인터페이스 설정에 관해 말할 때 우리는 네트웍 장치에 알맞은 주소를 할당하고 다른 설정 변수들에 알맞은 값들을 할당하는 과정에 대해 말하고 있는 것이다.
전형적으로 여러분은 아래와 비슷한 명령어를 사용한다.
root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
이 경우에 나는 `192.168.0.1'의 IP 주소와 `255.255.255.0'의
네트웍 마스크를 가지고 이더넷 인터페이스 `eth0'를 설정하고 있다. 명령문의
마지막에 오는 `up'은 인터페이스에게 작동하도록 말을 하는 것이지만 기본
명령이므로 생략할 수 있다. 인터페이스의 작동을 멈추기 위해선 단순히
``ifconfig eth0 down''라고 명령을 내려주면 된다.
인터페이스를 설정할 때 커널은 어떤 기본값을 가정한다. 예를들어 여러분이
인터페이스에 네트웍 주소와 브로드캐스트 주소를 설정할테지만 만약 하지 않는다면
위의 내 예제처럼 커널은 여러분이 설정한 넷 마스크에 기초하여 적당한 추정값을
적용할 것이며 넷마스크를 설정하지 않았다면 설정된 IP 주소의 네트웍 클래스에
기초해서 값들을 추정할 것이다. 내 예제에서 커널은 인터페이스에 설정되는
네트웍이 C 클래스라 가정하고 네트웍 주소를 `192.168.0.0'으로, 브로드캐스트
주소를 `192.168.0.255'로 설정하였다.
이 외에도 ifconfig 명령어에는 많은 다른 옵션들이 있다. 이 것들 중 가장 중요한 것들은 다음과 같다.
이 옵션은 인터페이스를 작동시킨다(그리고 기본 설정이다).
이 옵션은 인터페이스의 동작을 멈춘다.
이 옵션은 이 인터페이스에서 address resolution protocol 의 사용을 키거나 끈다.
이 옵션은 모든 hardware multicast packet들의 수신 기능을 키거나 끈다. Hardware multicast는 호스트의 그룹들이 특정 목적지로 보내진 패킷을 받을 수 있도록 해준다. desktop videoconferencing 같은 응용 프로그램을 사용할 때 중요할지 모르나 일반적으론 사용하지 않는다.
이 변수는 장치의 MTU 값을 설정할 수 있게 해준다.
이 변수는 장치가 속한 네트웍의 네트웍 마스크를 설정할 수 있도록 해준다.
이 변수는 특정 종류의 하드웨어에서만 작동하며 장치 하드웨어의 IRQ 값을 설정할 수 있도록 해준다.
이 변수는 broadcast 주소로 보내지는 데이타그램들의 수신을 기능을 설정하고 키거나 끈다.
이 변수는 slip이나 ppp같은 point to point 연결의 원격지에서 머신의 주소를 설정할 수 있도록 해준다.
이 변수는 어떤 종류의 네트웍 장치들의 하드웨어 주소를 설정할 수 있도록 해준다. 이 기능은 이더넷에는 그다지 쓸모가 없지만 AX.25 같은 다른 종류의 네트웍에서는 유용하다.
여러분은 어떤 네트웍 인터페이스에도 ifconfig 명령을 사용할 수 있다. pppd나 dip같은 어떤 프로그램들은 네트웍 장치들을 만드는 동시에 설정 하므로 ifconfig을 직접 사용할 필요는 없다.
`Name Resolver'는 리눅스의 표준 라이브러리의 일부이다. 기본 기능은
사용자에게 편한 `ftp.funet.fi'같은 호스트명을 기계에게 편한
128.214.248.6같은 IP 주소로 바꿔주는 서비스를 재공하는 것이다.
여러분은 아마 인터넷 호스트명에 익숙할 것이나 그것들이 어떻게 생성되고 없어지는지는 이해하지 못할 것이다. 인터넷 도매인명은 근본적으로 계층적 형태이며 다시 말해 tree와 같은 구조를 가진다. `domain'은 name들의 묶음 혹은 집단이다. `domain'은 `subdomain'으로 다시 쪼개어 질 수 있다. `toplevel domain'은 subdomain이 아닌 domain이다. Top Level Domain은 RFC-920에 명시되어 있다. 가장 흔히 쓰이는 top level domain에 대한 예는 다음과 같다.
상업 기관
교육 기관
정부 기관
군사 기관
기타 기관
인터넷 관련 기관
특정 국가를 나타내는 두 글자의 코드이다. (역자주: 예를 들어 한국은 .kr, 일본은 .jp)
역사적인 이유 때문에 미국이 `.us'라는 국가 domain을 가지고 있음에도
불구하고 국가 의존적이지 않은 top level domain(ex. .com, .edu 등)에 속한
domain의 거의 대부분은 미국 내의 기관들에 의해 사용되었다. 그러나 .com
과 .org에 있어선 이제 그렇지 않으며 미국 외의 나라에서도 흔히 쓰인다.
이 top level domain들 각각은 subdomain들을 가지고 있다. 국가 이름에 기초한
top level domain들은 흔히 다시 com과 edu, gov, mil,
org domain들에 기초한 subdomain들로 쪼개진다. 예를 들어 오스트레일리아의
상업 기관과 정부기관을 위해 각각 com.au와 gov.au를 사용할 수 있다.
그러나 이는 일반적인 규칙은 아니며 각 domain 명명권한을 가진 쪽의 정책에
달려있다.
다음 레벨의 domain은 대부분 기관의 이름을 나타낸다. 그 이상의 subdomain은 매우 다양해서 흔히 기관의 부서 구조에 기초하거나 기관의 네트웍 관리자에 의해 중요하게 생각되는 기준에 따른다.
name의 최 좌측 부분은 항상 호스트 머신에 할당된 유일한 이름이며 `hostname'이라 불린다. hostname의 오른쪽에 있는 name의 부분은 `domainname'이라 불리고 전체의 name은 `Fully Qulified Domain Name'이라 부른다.
일례로 Terry의 호스트를 사용하기 위해선 fully qulified domain name은
`perf.no.itg.telstra.com.au'이다. 이것은 host name이 `perf'이고
domain name이 `no.itg.telstra.com.au'라는 것을 나타낸다. domain name은
그(Terry)의 국가, Australia에 기초한 top level domain에 기반을 두고 있으고
그의 email 주소는 상업 기관에 속해 있으며 `.com'이 다음 level의 domain
으로 쓰였다. 회사의 이름은 `telstrs'이며(였으며) 내부 명명 구조는 기관
구조에 기초하고 있는데 이 경우에 그 머신(Terry의 머신)은 Network Operations
section의 Information Technology Group에 속해있다.
일반적으로 name은 매우 짧다. 예를 들어 내 ISP는 ``systemy.it''라
불리고 내 비 영리 기관은 ``linux.it''이라 불리며 com이나 org
subdomain을 사용하지 않아서 내 호스트는 ``morgana.systemy.it''이고
rubini@linux.it은 가능한 email 주소이다. domain의 소유자가 subdomain
뿐 아니라 hostname을 등록할 권리를 가진다는 것을 명심해라. 예를 들어
linux.it의 소유자가 LUG를 위한 subdomain을 만드는 것에 찬성했기 때문에
내가 속한 LUG는 pluto.linux.it의 domain을 사용한다.
여러분은 여러분의 호스트의 이름이 속할 domain을 알아야 한다. name resolver software는 `Domain Name Server'에 요청을 하여 이 name 변환 서비스를 있으므로 여러분이 사용할 수 있는 local nameserver의 IP주소를 알 필요가 있을 것이다.
또 수정해야 할 파일이 세 개 있으며 이를 차례대로 다루겠다.
/etc/resolv.conf는 name resolver code에 대한 주 설정 파일이다.
형식은 매우 간단해서 줄당 한 개의 키워드를 갖는 텍스트 파일이다. 특별히 쓰이는
세 개의 키워드가 있으며 아래와 같다.
이 키워드는 local domain name을 명시한다.
이 키워드는 hostname을 찾기 위한 다른 domain의 리스트를 명시한다.
이 키워드는 name resolving을 위한 쿼리를 보낼 domain name server의 IP 주소를 명시하며 여러번 쓰일 수 있다. (역자주: hostname을 해당 IP 주소로 변환하는 것은 name resolving이라 한다. 이름 변환 등의 우리 말을 쓸 수도 있겠지만 정확한 의미 전달을 위해 name resolving을 이하 그대로 사용하겠다.)
/etc/resolv.conf의 예는 아래와 같다.
domain maths.wu.edu.au
search maths.wu.edu.au wu.edu.au
nameserver 192.168.10.1
nameserver 192.168.12.1
이 예는 unqualified name(domain이 없는 hostname)의 뒤에 붙을 기본 domain
name이 maths.wu.edu.au이며 이 domain에서 호스트를 찾지 못했으면
wu.edu.au domain을 직접 찾아볼 것을 명시하고 있다. 두 개의 nameserver
엔트리가 있는데 각각은 name을 resolve하기 위해 name resolver code에서 보낸
요구를 받을 것이다.
/etc/host.conf 파일은 name resolver code의 행동을 관리하는 몇몇
항목들을 설정하는 곳이다. 이 파일의 형식은 `resolv+' 맨 페이지에 자세히
나와있다. 거의 모든 환경에선 아래의 예가 잘 작동할 것이다.
order hosts,bind
multi on
이 설정은 name resolver에게 nameserver에게 쿼리를 보내기 전에
/etc/hosts 파일을 먼저 검사하고 처음 발견되는 하나 말고도
/etc/hosts 파일 안에서 발견된 호스트에 해당하는 모든 주소를 돌려주도록
하고 있다.
/etc/hosts 파일은 로컬 호스트들의 name과 IP 주소들을 넣어두는
곳이다. 이 파일 안에 호스트를 넣어 놓으면 IP 주소를 얻으려 할 때 domain
name server를 검색할 필요가 없다. 그러나 호스트의 IP 주소가 바뀌면 여러분
스스로가 이 파일을 최신으로 계속 갱신해야 한다는 것이 단점이다. 잘 정비된
시스템에서는 이 파일 안에 나오는 hostname들은 오직 loopback 인터페이스나
로컬 호스트들의 name이다.
# /etc/hosts
127.0.0.1 localhost loopback
192.168.0.1 this.host.name
첫 번째 엔트리처럼 한 라인에 둘 이상의 host name을 명시할 수 있으며 첫 엔트리는 loopback 인터페이스에 대한 표준 엔트리이다.
로컬 nameserver를 돌리기를 원한다면 쉽게 할 수 있다. DNS-HOWTO와 여러분이 가진 BIND (Berkeley Internet Name Domain) 버전에 포함된 문서들을 참조하라.
`loopback' 인터페이스는 여러분 자신에게 연결할 수 있도록 해주는 특별한
인터페이스이다. 이것이 필요한 여러 이유가 있는데 한 예로 네트웍의 다른 사람을
방해하지 않으면서 어떤 네트웍 소프트웨어를 시험해볼 수 있다. 편의상
`127.0.0.1'의 IP 주소가 loopback용으로 할당되어 왔다. 따라서 어떤 머신으로
가더라도 127.0.0.1로 telnet 연결을 연다면 로컬 호스트로 접속될 것이다.
loopback 인터페이스의 설정은 간단하며 반드시 해야 한다(그러나 이 작업은 보통 표준 초기화 스크립트에서 행해진다).
root# ifconfig lo 127.0.0.1
root# route add -host 127.0.0.1 lo
다음 부분에선 route 명령에 대해 말하겠다.
라우팅은 중요한 문제이며 그것에 대한 두꺼운 책들을 쓰는 것도 어렵지 않다. 여러분의 대부분은 매우 간단한 라우팅 조건을 가지고 있을 것이고 일부는 그것 조차 없을 것이다. 나는 라우팅의 일부 기본적인 기초에 대해서만 다룰 것이다. 만약 좀 더 자세한 내용에 관심이 있다면 이 문서의 처음에 나온 리퍼런스들을 볼 것을 권한다.
우선 정의부터 시작한다. IP 라우팅이란 무엇인가? 아래는 내가 사용하고 있는 정의이다.
IP 라우팅은 여러 개의 네트웍 연결을 가진 호스트가 자신이 받은 데이타그램을 전달할 곳을 결정하는 과정이다.
이를 간단한 예와 함께 설명하는 것이 유용할지 모른다. 전형적인 사무용 라우터를 생각해보면 그것은 인터넷으로의 PPP연결과 워크스테이션들에 연결된 많은 이더넷 부분들, 다른 사무실로의 PPP 연결을 가지고 있을 것이다. 라우터는 자신의 네트웍 연결 중 한 곳으로부터 데이타그램을 받으면 다음으로 그 데이타그램을 전달할 자신의 인터페이스를 결정하는데 이 메카니즘이 라우팅이다. 단순한 호스트들도 라우팅이 필요다. 모든 인터넷 호스트는 두 개의 네트웍 장치를 가지고 있는데 하나는 위에서 설명한 loopback 인터페이스이고 다른 하나는 이더넷이나 PPP, SLIP 같은 자신이 속한 네트웍과 통신하기 위해 사용하는 인터페이스이다.
그래서 라우팅은 어떻게 작동하는가? 각각의 호스트들은 라우팅 테이블이라 불리는 라우팅 규칙들의 특별한 리스트를 가지고 있다. 이 테이블은 일반적으로 세 개 이상의 필드를 갖는 열(row)들을 가지고 있다. 첫 번째는 목표 주소이고 두 번째는 데이타그램이 발송될 인터페이스의 이름이며 세 번째는 네트웍 상에서 데이타그램을 그 다음 단계에서 전달할 다른 머신의 IP 주소를 가지고 있을 수 있다. 리눅스에서 여러분은 다음과 같은 명령을 통해 이 테이블의 내용을 볼 수 있다.
user% cat /proc/net/route
혹은 다음 명령을 쓸 수도 있다.
user% /sbin/route -n
user% netstat -r
라우팅 과정은 매우 단순하다. 데이타그램이 받아지면 목적지 주소가 검사되고 테이블의 각 엔트리들과 비교된다. 그 주소에 가장 알맞는 엔트리가 선택되고 해당 인터페이스로 데이타그램이 전달된다. 게이트웨이 필드에 값이 존재한다면 데이타그램은 명시된 인터페이스를 통해 그 호스트로 전송될 것이고 그렇지 않다면 목적지 주소가 그 인터페이스가 속한 네트웍 상에 있다고 여겨진다.
이 테이블을 다루기 위해선 특별한 명령이 필요하다. 이 명령은 명령행 인자들을 받아들여 이를 커널에게 라우팅 엔트리를 추가, 삭제 혹은 수정하도록 요구하는 커널 시스템 콜로 변경한다. 이 명령은 `route'다.
간단한 예를 보자. 여러분이 이더넷 네트웍상에 있다고 하자. 주소가
192.168.1.0인 class-C 네트웍이라는 것을 알고 있고 192.168.1.10의
IP 주소를 사용하도록 배정받았으며 인터넷에 연결된 라우터가 192.168.1.1
이라는 것을 알고 있다.
먼저 할 일은 위에 나온 인터페이스를 설정하는 것이다. 다음과 같은 명령을 쓸 것이다.
root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
주소가 192.168.1.*에 해당하는 호스트들에게 가는 데이타그램들이
위의 이더넷 장치로 보내지도록 커널에 알려주기 위해선 라우팅 테이블에 엔트리를
삽입할 필요가 있다.
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
이 엔트리가 네트웍 라우트라는 것을 라우트 프로그램에 알려주기 위해서
`-net' 인자를 사용한 것에 주의한다. 이외에도 `-host'를 사용하여
특정한 한 IP 주소로의 라우팅을 설정할 수 있다.
이 라우팅은 여러분에게 여러분의 이더넷 네트웍 위의 모든 호스트들에 IP 접속을 할 수 있도록 해줄 것이다. 그러나 이 이더넷 네트웍 위에 있지 않은 IP 호스트들은 어떠한가?
모든 가능한 목적지 네트웍으로의 라우팅 정보를 추가하는 것은 매우 힘든 일이며
따라서 이 작업을 단순화하기 위해 사용되는, `default' 라우트 라 불리는
특별한 기법이 있다. default 라우트는 모든 가능한 목적지에 적용되나 매우
빈약해서 해당 주소에 적용되는 다른 엔트리가 있다면 이것이 default 라우트
대신 쓰인다. default 라우트의 개념은 단순히 "다른 모든 것들은 이곳으로
가야한다"고 말하도록 하는 것이다. 이 예에서 나는 여러분이 다음과 같은 엔트리를
사용하도록 했다.
root# route add default gw 192.168.1.1 eth0
`gw' 인자는 라우트 명령에게 다음 인자가 이 엔트리에 적용되는 모든
데이타그램이 다른 라우팅을 위해 보내져야 할 게이트웨이나 라우터 기계의 이름
혹은 IP주소라는 것을 말해준다.
따라서 완성된 설정은 아래와 같다.
root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# route add default gw 192.168.1.1 eth0
여러분의 네트웍 `rc' 파일을 자세히 들여다본다면 이와 비슷해 보이는
하나 이상의 것들을 발견할 것이다. 이는 매우 일반적인 설정이다.
좀 더 복잡한 라우팅 설정을 보도록 하자. 앞에서 나왔던, 인터넷으로 PPP 연결을 지원하고 사무실 안의 워크스테이션들간의 랜 연결을 지원하는 라우터의 설정을 한다고 생각해 보자. 이 라우터가 세 개의 이더넷 부분과 한 개의 PPP 연결을 가지고 있다고 가정하자. 우리의 라우팅 설정은 아래와 같을 것이다.
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# route add -net 192.168.2.0 netmask 255.255.255.0 eth1
root# route add -net 192.168.3.0 netmask 255.255.255.0 eth2
root# route add default ppp0
각각의 워크스테이션들은 위의 것보다 간단한 형식을 이용할 것이고 라우터만이
각 내트웍의 라우팅을 명시할 필요가 있다. 왜냐하면 워크스테이션들의 default
라우트 메카니즘은 라우팅 정보를 알맞게 분배하는 문제를 라우터에게 남겨둔 채로
이 정보들을 받아들이기 때문이다. 여러분은 위의 default 라우트가 `gw'를
명시하지 않은 것을 이상히 여길 것이다. 이유는 간단하다. PPP나 slip같은 시리얼
연결 프로토콜은 그 네트웍 상에 양 끝에 단 두 개의 호스트만을 가지고 있다.
연결의 반대 끝 호스트를 게이트웨이로 명시하는 것은 무의미하며 선택의 여지가
없기 때문에 중복적인 것이다. 따라서 이런 종류의 네트웍 연결에 대해선
게이트웨이를 설정해줄 필요가 없다. 이더넷이나 아크넷, 토큰 링 같은 다른 종류의
네트웍들은 많은 수의 호스트들을 지원하기 때문에 게이트웨이가 명시되어야 한다.
위에 설명된 라우팅 설정은 목적지까지 단순한 하나의 경로만이 존재하는 간단한 네트웍 환경에 가장 알맞다. 네트웍이 좀 더 복잡하다면 모든 것들이 더 복잡해진다. 운좋게도 여러분중 대부분에게 이것은 중요치 않을 것이다.
설명된것 같은 `수동 라우팅(manual routing)'이나 `고정 라우팅(static routing)' 이 갖는 큰 문제점은 네트웍 상의 연결이 끊어지거나 기계가 죽었을 때 데이타그램을 다른 경로 - 다른 경로가 있다면 - 로 돌리는 유일한 방법은 중간에 직접 끼어들어서 적당한 명령을 실행시키는 것이다. 당연히 이것은 불편하고 느리고 비현실적이며 문제를 일으킬 소지가 많다. 네트웍 문제 발생시 다른 경로가 존재할 때 라우팅 테이블을 자동으로 수정해주는 많은 기법들이 발전되어 왔고 이 모든 기술들은 `동적 라우팅 프로토콜(dynamic routing protocols)'이라는 말로 묶여진다.
여러분은 몇몇 일반적인 동적 라우팅 프로토콜에 대해 들어봤을 것이다. 가장 많이 사용되는 것은 RIP (Routing Information Protocol)와 OSPF (Open Shortest Path First Protocol)이다. RIP는 중소기업의 네트웍이나 빌딩 내부의 네트웍 같은 작은 크기의 네트웍에 매우 많이 이용된다. OSPF는 RIP보다 최근에 나왔고 규모가 큰 네트웍의 설정을 다룰 수 있고 네트웍 안에 가능한 경로의 수가 매우 많은 환경에 보다 더 적합하다. 이 프로토콜들의 대표적인 구현이 `routed' - RIP 와 `gated' - RIP, OSPF 등이다. `routed' 프로그램은 대부분의 리눅스 배포본에 기본으로 제공되며 혹은 위에서 자세히 설명한 `NetKit' 안에 포함되어 있다.
여러분이 동적 라우팅 프로토콜을 사용하는 곳과 방법의 한 예가 아래에 있다.
192.168.1.0 / 192.168.2.0 /
255.255.255.0 255.255.255.0
- -
| |
| /-----\ /-----\ |
| | |ppp0 // ppp0| | |
eth0 |---| A |------//---------| B |---| eth0
| | | // | | |
| \-----/ \-----/ |
| \ ppp1 ppp1 / |
- \ / -
\ /
\ /
\ /
\ /
\ /
\ /
\ /
\ /
ppp0\ /ppp1
/-----\
| |
| C |
| |
\-----/
|eth0
|
|---------|
192.168.3.0 /
255.255.255.0
우리는 A, B, C 이렇게 세 개의 라우터를 가지고 있다. 각각은 C 클래스 (넷마스크 255.255.255.0) 의 이더넷 네트웍 부분을 지원한다. 또한 각 라우터는 다른 라우터로의 PPP 연결을 가지고 있다. 네트웍은 삼각형 형테를 띤다.
라우터 A의 라우팅 테이블은 아래와 같아야 한다.
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# route add -net 192.168.2.0 netmask 255.255.255.0 ppp0
root# route add -net 192.168.3.0 netmask 255.255.255.0 ppp1
라우터 A와 B간의 연결이 끊어지기 전까진 잘 작동하고 있었다. 위의 라우팅 엔트리에서 이 연결(A와 B간의)이 끊어지면 A의 이더넷 부분 위의 호스트들은 B의 이더넷 부분 위의 호스트들과 연결될 수 없다. 모든 데이타그램들이 끊어져 있는 A의 ppp0 연결로 보내지기 때문이다. A상의 호스트들은 여전히 C의 이더넷 부분 상의 호스트들과 통신이 가능하고 C 상의 호스트들도 B 상의 호스트들과 통신이 가능하다. B와 C 사이의 연결은 살아있기 때문이다.
그러나 잠시 생각해보자. A와 C가 통신할 수 있고 C와 B가 통신할 수 있다면 왜 A 라우터는 B로 갈 데이타그램들을 C를 통해서 보내고 C에게 그들을 B로 보내도록 하지 않는가? RIP같은 동적 라우팅 프로토콜(dynamic routing protocols)은 바로 이런 문제를 해결하기 위해 만들어졌다. 라우터 A, B, C가 각각 라우팅 데몬을 돌리고 있다면 많약 네트웍 상의 연결들 중 하나가 끊겼을 경우 새로운 네트웍 상태를 반영하기 위해 라우팅 테이블들이 자동으로 수정될 것이다. 이런 네트웍을 설정하는 것은 간단해서 각 라우터에 딱 두 가지 일만 해주면 된다. 라우터 A의 경우
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# /usr/sbin/routed
`routed' 라우팅 데몬은 시작시에 가능한 모든 네트웍 포트들을 자동으로 찾고 그 호스트의 라우팅 테이블을 결정하고 갱신하기 위해 각 네트웍 장치로 메시지를 보내거나 받는다.
지금까지 동적 라우팅의 매우 간단한 설명이었고 이를 사용하는 예를 보았다. 만약 더 많은 정보를 원한다면 문서 맨 앞에 열거된 참조문서들을 볼 것을 권한다.
동적 라우팅과 관련된 중요한 점은
네트웍 서버와 서비스는 원격지의 사용자에게 여러분의 리눅스 머신을 사용하도록 해 주는 프로그램이다. 서버 프로그램은 네트웍 포트를 통해 메시지를 받는다. 네트웍 포트는 특정 호스트의 특정 서비스를 지칭하는 수단이며 서버가 요청이 들어온 telnet 연결과 ftp 연결을 구분하는 수단이다. 원격 사용자는 여러분의 머신에 네트웍 연결을 만들고 서버 프로그램인 네트웍 데몬 프로그램은 그 포트를 듣고 있다가 연결을 받아들이고 작업을 수행한다. 네트웍 데몬이 작동하는 두 가지 방식이 있는데 둘 다 실제로 흔히 사용된다. 두 가지는
네트웍 데몬 프로그램이 해당 네트웍 포트를 듣고 있다가 연결이 들어오면 그 자신이 네트웍 연결을 관리해서 서비스를 제공한다.
inetd 서버는 들어오는 네트웍 연결을 전문적으로 다루는 특별한 네트웍 데몬이다. 들어온 연결이 받아들여졌을 때 실행해야 할 프로그램을 알려주는 설정 파일을 가지고 있다. 어떤 서비스 포트도 tcp나 udp 혹은 둘 다를 사용하도록 설정할 수 있다. 포트는 곧 말할 다른 파일에 기술된다.
설정할 필요가 있는 두 개의 중요한 파일이 있다. 그것은 포트 번호에 이름을
부여하는 /etc/services파일과 inetd 네트웍 데몬의 설정 파일인
/etc/inetd.conf이다.
/etc/services/etc/services 파일은 사람에게 친숙한 이름을 기계가 친숙한 서비스
포트에 부여하는 간단한 데이타베이스다. 형식은 매우 단순하다. 한 줄에
데이타베이스 엔트리가 나오는 텍스트 파일이다. 각 엔트리는 whitespace(tab이나
space) 문자로 구분되는 세 개의 필드를 가지고 있는데 그 필드는 다음과 같다.
name port/protocol aliases # comment
설명되는 서비스를 타나내는 한 단어 길이의 이름
이 필드는 두 개의 서브필드로 나뉜다.
명명된 서비스가 제공될 포트 번호를 지시하는
숫자. 대부분의 일반적인 서비스들은 서비스 번호를 이미
부여받았다. 이는 RFC-1340에 명시되어 있다.
이 서브필드는 tcp나 udp
로 설정된다.
18/tcp와 18/udp의 엔트리들은 매우 다르며 같은
서비스를 둘 다(tcp와 udp)에서 제공하는지에 대한 기술적 이유는
없다. 보통 상식이 통하며 여러분이 둘 다에 대한 엔트리를 보는 경우는
특정 서비스가 tcp와 udp 둘 다를 통해 가능한 때
뿐이다.
이 서비스 엔트리를 참조하기 위해 사용되는 다른 이름들
`#' 문자 다음에 나오는 줄은 주석으로 여겨지며 무시된다.
/etc/services 파일의 예모든 요즘의 리눅스 배포본은 괜찮은 /etc/services 파일을 제공한다. 단지
여러분이 머신을 처음부터 다시 만드는 경우를 위해 오래된
Debian 배포본에서 제공되는
/etc/services 파일이 여기 있다.
# /etc/services:
# $Id: services,v 1.3 1996/05/06 21:42:37 tobias Exp $
#
# Network services, Internet style
#
# Note that it is presently the policy of IANA to assign a single well-known
# port number for both TCP and UDP; hence, most entries here have two entries
# even if the protocol doesn't support UDP operations.
# Updated from RFC 1340, ``Assigned Numbers'' (July 1992). Not all ports
# are included, only the more common ones.
tcpmux 1/tcp # TCP port service multiplexer
echo 7/tcp
echo 7/udp
discard 9/tcp sink null
discard 9/udp sink null
systat 11/tcp users
daytime 13/tcp
daytime 13/udp
netstat 15/tcp
qotd 17/tcp quote
msp 18/tcp # message send protocol
msp 18/udp # message send protocol
chargen 19/tcp ttytst source
chargen 19/udp ttytst source
ftp-data 20/tcp
ftp 21/tcp
ssh 22/tcp # SSH Remote Login Protocol
ssh 22/udp # SSH Remote Login Protocol
telnet 23/tcp
# 24 - private
smtp 25/tcp mail
# 26 - unassigned
time 37/tcp timserver
time 37/udp timserver
rlp 39/udp resource # resource location
nameserver 42/tcp name # IEN 116
whois 43/tcp nicname
re-mail-ck 50/tcp # Remote Mail Checking Protocol
re-mail-ck 50/udp # Remote Mail Checking Protocol
domain 53/tcp nameserver # name-domain server
domain 53/udp nameserver
mtp 57/tcp # deprecated
bootps 67/tcp # BOOTP server
bootps 67/udp
bootpc 68/tcp # BOOTP client
bootpc 68/udp
tftp 69/udp
gopher 70/tcp # Internet Gopher
gopher 70/udp
rje 77/tcp netrjs
finger 79/tcp
www 80/tcp http # WorldWideWeb HTTP
www 80/udp # HyperText Transfer Protocol
link 87/tcp ttylink
kerberos 88/tcp kerberos5 krb5 # Kerberos v5
kerberos 88/udp kerberos5 krb5 # Kerberos v5
supdup 95/tcp
# 100 - reserved
hostnames 101/tcp hostname # usually from sri-nic
iso-tsap 102/tcp tsap # part of ISODE.
csnet-ns 105/tcp cso-ns # also used by CSO name server
csnet-ns 105/udp cso-ns
rtelnet 107/tcp # Remote Telnet
rtelnet 107/udp
pop-2 109/tcp postoffice # POP version 2
pop-2 109/udp
pop-3 110/tcp # POP version 3
pop-3 110/udp
sunrpc 111/tcp portmapper # RPC 4.0 portmapper TCP
sunrpc 111/udp portmapper # RPC 4.0 portmapper UDP
auth 113/tcp authentication tap ident
sftp 115/tcp
uucp-path 117/tcp
nntp 119/tcp readnews untp # USENET News Transfer Protocol
ntp 123/tcp
ntp 123/udp # Network Time Protocol
netbios-ns 137/tcp # NETBIOS Name Service
netbios-ns 137/udp
netbios-dgm 138/tcp # NETBIOS Datagram Service
netbios-dgm 138/udp
netbios-ssn 139/tcp # NETBIOS session service
netbios-ssn 139/udp
imap2 143/tcp # Interim Mail Access Proto v2
imap2 143/udp
snmp 161/udp # Simple Net Mgmt Proto
snmp-trap 162/udp snmptrap # Traps for SNMP
cmip-man 163/tcp # ISO mgmt over IP (CMOT)
cmip-man 163/udp
cmip-agent 164/tcp
cmip-agent 164/udp
xdmcp 177/tcp # X Display Mgr. Control Proto
xdmcp 177/udp
nextstep 178/tcp NeXTStep NextStep # NeXTStep window
nextstep 178/udp NeXTStep NextStep # server
bgp 179/tcp # Border Gateway Proto.
bgp 179/udp
prospero 191/tcp # Cliff Neuman's Prospero
prospero 191/udp
irc 194/tcp # Internet Relay Chat
irc 194/udp
smux 199/tcp # SNMP Unix Multiplexer
smux 199/udp
at-rtmp 201/tcp # AppleTalk routing
at-rtmp 201/udp
at-nbp 202/tcp # AppleTalk name binding
at-nbp 202/udp
at-echo 204/tcp # AppleTalk echo
at-echo 204/udp
at-zis 206/tcp # AppleTalk zone information
at-zis 206/udp
z3950 210/tcp wais # NISO Z39.50 database
z3950 210/udp wais
ipx 213/tcp # IPX
ipx 213/udp
imap3 220/tcp # Interactive Mail Access
imap3 220/udp # Protocol v3
ulistserv 372/tcp # UNIX Listserv
ulistserv 372/udp
#
# UNIX specific services
#
exec 512/tcp
biff 512/udp comsat
login 513/tcp
who 513/udp whod
shell 514/tcp cmd # no passwords used
syslog 514/udp
printer 515/tcp spooler # line printer spooler
talk 517/udp
ntalk 518/udp
route 520/udp router routed # RIP
timed 525/udp timeserver
tempo 526/tcp newdate
courier 530/tcp rpc
conference 531/tcp chat
netnews 532/tcp readnews
netwall 533/udp # -for emergency broadcasts
uucp 540/tcp uucpd # uucp daemon
remotefs 556/tcp rfs_server rfs # Brunhoff remote filesystem
klogin 543/tcp # Kerberized `rlogin' (v5)
kshell 544/tcp krcmd # Kerberized `rsh' (v5)
kerberos-adm 749/tcp # Kerberos `kadmin' (v5)
#
webster 765/tcp # Network dictionary
webster 765/udp
#
# From ``Assigned Numbers'':
#
#> The Registered Ports are not controlled by the IANA and on most systems
#> can be used by ordinary user processes or programs executed by ordinary
#> users.
#
#> Ports are used in the TCP [45,106] to name the ends of logical
#> connections which carry long term conversations. For the purpose of
#> providing services to unknown callers, a service contact port is
#> defined. This list specifies the port used by the server process as its
#> contact port. While the IANA can not control uses of these ports it
#> does register or list uses of these ports as a convenience to the
#> community.
#
ingreslock 1524/tcp
ingreslock 1524/udp
prospero-np 1525/tcp # Prospero non-privileged
prospero-np 1525/udp
rfe 5002/tcp # Radio Free Ethernet
rfe 5002/udp # Actually uses UDP only
bbs 7000/tcp # BBS service
#
#
# Kerberos (Project Athena/MIT) services
# Note that these are for Kerberos v4 and are unofficial. Sites running
# v4 should uncomment these and comment out the v5 entries above.
#
kerberos4 750/udp kdc # Kerberos (server) udp
kerberos4 750/tcp kdc # Kerberos (server) tcp
kerberos_master 751/udp # Kerberos authentication
kerberos_master 751/tcp # Kerberos authentication
passwd_server 752/udp # Kerberos passwd server
krb_prop 754/tcp # Kerberos slave propagation
krbupdate 760/tcp kreg # Kerberos registration
kpasswd 761/tcp kpwd # Kerberos "passwd"
kpop 1109/tcp # Pop with Kerberos
knetd 2053/tcp # Kerberos de-multiplexor
zephyr-srv 2102/udp # Zephyr server
zephyr-clt 2103/udp # Zephyr serv-hm connection
zephyr-hm 2104/udp # Zephyr hostmanager
eklogin 2105/tcp # Kerberos encrypted rlogin
#
# Unofficial but necessary (for NetBSD) services
#
supfilesrv 871/tcp # SUP server
supfiledbg 1127/tcp # SUP debugging
#
# Datagram Delivery Protocol services
#
rtmp 1/ddp # Routing Table Maintenance Protocol
nbp 2/ddp # Name Binding Protocol
echo 4/ddp # AppleTalk Echo Protocol
zip 6/ddp # Zone Information Protocol
#
# Debian GNU/Linux services
rmtcfg 1236/tcp # Gracilis Packeten remote config server
xtel 1313/tcp # french minitel
cfinger 2003/tcp # GNU Finger
postgres 4321/tcp # POSTGRES
mandelspawn 9359/udp mandelbrot # network mandelbrot
# Local services
실제론 새 서비스가 생겨나면 파일도 커진다. 여러분의 현재 파일이 불완전하다고
생각되면 최신 배포본에서 /etc/services 파일을 복사할 것을 권한다.
/etc/inetd.conf/etc/inetd.conf 파일은 inetd 서버 데몬용 설정 파일이다. 그 기능은
inetd에게 특정 서비스에 대한 연결 요청을 받았을 때 무엇을 해야 하는지를
알려주는 것이다. 여러분이 연결을 받아들일 각 서비스에 대해 여러분은 inetd
에게 어떤 네트웍 서버 데몬을 어떻게 실행할지를 알려줘야 한다.
이 파일의 형식도 매우 간단하다. 제공하려는 서비스를 설명하는 라인들로 이루어진
텍스트 파일이다. `#'로 시작하는 줄의 모든 텍스트는 주석으로 간주되어
무시된다. 각 줄은 whitespace(tab이나 space) 문자로 구분되는 일곱게의 필드로
구성되며 whitespace의 개수는 관계없다. 일반적인 형식은 다음과 같다.
service socket_type proto flags user server_path server_args
/etc/services 파일에서 가져온 이
설정에 해당하는 서비스다.
현재 엔트리에 알맞는 소켓 종류를 나타나낸
필드이며 가능한 값은 stream, dgram, raw,
rdm, seqpacket 들이다. 원랜 상당히 기술적인 것이지만
편의상 거의 모든 tcp 기반 서비스는 stream을, udp
기반의 서비스들은 dgram을 사용한다. 다른 값을 쓰는 서버
데몬들은 매우 특별한 종류 뿐이다.
이 엔트리에 적합한 프로토콜. 이 값은
/etc/services 파일 안의 해당 엔트리와 일치해야
하며 전형적으로 tcp이거나 udp이다. 선의 RPC
(Remote Procedure Call) 기반의 서버들은 rpc/tcp나
rpc/udp를 사용한다.
이 필드에 오는 값은 딱 두 개 뿐이다. 이
필드는 inetd에게 네트웍 서버 프로그램이 시작된 후에
소켓을 놔 주는지를 알려주며 결과적으로 inetd가 다른
연결 요청이 들어올 때 서버를 또 실행할 지 아니면 이미 실행
중인 서버 데몬이 새 연결 요청을 다루도록 해야할지를 알려준다.
정확한 해결방법이 아니겠지만 편의상 모든 tcp 서버들은
이 필드값이 nowait가 되도록 하고 udp 서버들은
wait값을 같는다. 이에 대한 예외가 존재함을 주의해야
하며 여러분이 확실치 못할 경우 예제를 따라 하도록 해라.
이 필드는 /etc/passwd 안의 어떤
사용자 계정이 새로 시작되는 네트웍 서버의 소유자가 될 것인지를
나타낸다. 여러분이 보안 위첨에서 벗어나고자 할 경우 이는 매우
유용하다. 네트웍 서버 보안이 깨졌을 때 피해를 최소화하도록
엔트리의 사용자를 nobody로 할 수도 있다. 그러나 보통 이
필드는 root로 설정되는데 이는 많은 서버들이 정상적인
작동을 위해 루트 권한을 필요로 하기 때문이다.
이 필드는 이 엔트리에서 실행시키는 실제 서버 프로그램의 경로이다.
이 필드는 줄의 남은 부분으로 이루어지며 선택사항이다. 이 필드는 서버 데몬 프로그램이 실행될 때 넘겨줄 인자들을 넣어놓는 곳이다.
/etc/inetd.conf의 예/etc/services 파일처럼 요즘의 모든 배포본들은 그냥 쓰기에 꽤 좋은
/etc/inetd.conf 파일을 포함하고 있다. 아래는
Debian 배포본에 들어있는
/etc/inetd.conf 파일이다.
# /etc/inetd.conf: see inetd(8) for further informations.
#
# Internet server configuration database
#
#
# Modified for Debian by Peter Tobias <tobias@et-inf.fho-emden.de>
#
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
#
# Internal services
#
#echo stream tcp nowait root internal
#echo dgram udp wait root internal
discard stream tcp nowait root internal
discard dgram udp wait root internal
daytime stream tcp nowait root internal
daytime dgram udp wait root internal
#chargen stream tcp nowait root internal
#chargen dgram udp wait root internal
time stream tcp nowait root internal
time dgram udp wait root internal
#
# These are standard services.
#
telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd
ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.ftpd
#fsp dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.fspd
#
# Shell, login, exec and talk are BSD protocols.
#
shell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd
login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind
#exec stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rexecd
talk dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.talkd
ntalk dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.ntalkd
#
# Mail, news and uucp services.
#
smtp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.smtpd
#nntp stream tcp nowait news /usr/sbin/tcpd /usr/sbin/in.nntpd
#uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico
#comsat dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.comsat
#
# Pop et al
#
#pop-2 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.pop2d
#pop-3 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.pop3d
#
# `cfinger' is for the GNU finger server available for Debian. (NOTE: The
# current implementation of the `finger' daemon allows it to be run as `root'.)
#
#cfinger stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.cfingerd
#finger stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.fingerd
#netstat stream tcp nowait nobody /usr/sbin/tcpd /bin/netstat
#systat stream tcp nowait nobody /usr/sbin/tcpd /bin/ps -auwwx
#
# Tftp service is provided primarily for booting. Most sites
# run this only on machines acting as "boot servers."
#
#tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd
#tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /boot
#bootps dgram udp wait root /usr/sbin/bootpd bootpd -i -t 120
#
# Kerberos authenticated services (these probably need to be corrected)
#
#klogin stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind -k
#eklogin stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind -k -x
#kshell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd -k
#
# Services run ONLY on the Kerberos server (these probably need to be corrected)
#
#krbupdate stream tcp nowait root /usr/sbin/tcpd /usr/sbin/registerd
#kpasswd stream tcp nowait root /usr/sbin/tcpd /usr/sbin/kpasswdd
#
# RPC based services
#
#mountd/1 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.mountd
#rstatd/1-3 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rstatd
#rusersd/2-3 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rusersd
#walld/1 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rwalld
#
# End of inetd.conf.
ident stream tcp nowait nobody /usr/sbin/identd identd -i
리눅스에는 여러분이 관심있어 할 네트웍 관련 잡다한 설정 파일들이 많이 있다. 여러분은 이 파일을 수정할 필요가 없을지도 모르나 안에 들어있는 것이 무언지 알려주기 위해서 설명할 가치가 있다.
/etc/protocols/etc/protocols 파일은 프로토콜 id 번호를 프로토콜 이름과 연결짓는
데이타베이스다. 이 파일은 프로그래머들이 자신의 프로그램 안에서 프로토콜을
이름을 가지고 명시하기 위해 사용되고 또는 tcpdump같은 프로그램에서
결과에 프로토콜 번호 대신 이름을 사용하기 위해 쓰인다. 일반적인 문법은 다음과
같다.
protocolname number aliases
Debian 배포본에 들어있는
/etc/protocols 파일은 아래와 같다.
# /etc/protocols:
# $Id: protocols,v 1.1 1995/02/24 01:09:41 imurdock Exp $
#
# Internet (IP) protocols
#
# from: @(#)protocols 5.1 (Berkeley) 4/17/89
#
# Updated for NetBSD based on RFC 1340, Assigned Numbers (July 1992).
ip 0 IP # internet protocol, pseudo protocol number
icmp 1 ICMP # internet control message protocol
igmp 2 IGMP # Internet Group Management
ggp 3 GGP # gateway-gateway protocol
ipencap 4 IP-ENCAP # IP encapsulated in IP (officially ``IP'')
st 5 ST # ST datagram mode
tcp 6 TCP # transmission control protocol
egp 8 EGP # exterior gateway protocol
pup 12 PUP # PARC universal packet protocol
udp 17 UDP # user datagram protocol
hmp 20 HMP # host monitoring protocol
xns-idp 22 XNS-IDP # Xerox NS IDP
rdp 27 RDP # "reliable datagram" protocol
iso-tp4 29 ISO-TP4 # ISO Transport Protocol class 4
xtp 36 XTP # Xpress Tranfer Protocol
ddp 37 DDP # Datagram Delivery Protocol
idpr-cmtp 39 IDPR-CMTP # IDPR Control Message Transport
rspf 73 RSPF # Radio Shortest Path First.
vmtp 81 VMTP # Versatile Message Transport
ospf 89 OSPFIGP # Open Shortest Path First IGP
ipip 94 IPIP # Yet Another IP encapsulation
encap 98 ENCAP # Yet Another IP encapsulation
/etc/networks/etc/networks 파일은 /etc/hosts 파일과 비슷한 역할을 한다.
이 파일은 네트웍 주소를 네트웍 이름과 연관짓는 간단한 데이타베이스를 제공한다.
한 줄에 단 두 개의 필드만을 갖는다는 점이 /etc/hosts와 다르며 각
필드는 아래처럼 사용된다.
networkname networkaddress
다음은 한 예이다.
loopnet 127.0.0.0
localnet 192.168.0.0
amprnet 44.0.0.0
여러분이 route 명령을 내렸을 때 목적지가 네트웍이고
/etc/networks 파일 안에 그 네트웍에 해당하는 엔트리가 있다면 route
명령은 네트웍을 주소 대신 이름으로 출력할 것이다.
여러분의 머신과 네트웍을 악의에 찬 공격으로부터 안전히 보호하는 일은 매우 복잡한 기술이라는 것을 먼저 주지시키면서 이 내용을 시작코자 한다. 나는 내 자신을 이 분야에서 전문가라 생각치 않으며 내가 말할 아래의 기법들이 도움이 될 지라도 여러분이 보안에 더욱 신중하다면 이 분야를 좀 더 공부할 것을 추천한다. 이 분야에 관한 매우 좋은 참조자료들이 인터넷 상엔 매우 많으며 그 중 하나는 Security-HOWTO이다.
중요한 기본법칙은 `사용하지 않을 서버는 돌리지 말아라.' 이다.
많은 배포본들이 모든 서비스가 설정되어 자동으로 실행되도록 되어 있다. 최소한의
보안 등급을 만족시키려면 여러분은 /etc/inetd.conf 파일로 가서 사용하지
않을 서비스에 해당하는 엔트리엔 주석 처리 (줄의 맨 앞에 `#'를 붙인다)
를 해라. shell, login, exec, uucp, ftp와 finger,
netstat, systat같은 정보 제공용 서비스들이 그런 예들이다.
보안과 접근 제어 기법이 많이 있으며 그 기본적인 사항만을 설명할 것이다.
/etc/ftpusers 파일은 특정 사용자들이 ftp를 통해 여러분의 머신에
들어오는 것을 제한하도록 하는 간단한 기법이다. 이 /etc/ftpusers 파일은
새 ftp 연결이 들어온 후 ftp 데몬 프로그램 (ftpd)이 실행될 때 읽혀진다. 이
파일은 들어오지 못하도록 할 사용자들의 간단한 목록이며 아래처럼 생겼다.
# /etc/ftpusers - users not allowed to login via ftp
root
uucp
bin
mail
/etc/securetty 파일은 root가 로그온이 가능한 tty 장치들을
명시한다. /etc/securetty 파일은 로긴 프로그램 (보통 /bin/login)
에 의해 읽혀진다. 형식은 허가될 tty 장치 이름들의 목록이며 다른 장치들에선
root의 로긴이 불허된다.
# /etc/securetty - tty's on which root is allowed to login
tty1
tty2
tty3
tty4
/etc/inetd.conf 안에서 많이 봤을 tcpd 프로그램은 이
프로그램이 보호하도록 설정된 서비스로의 로긴과 접근을 제어한다.
inetd프로그램이 실행될 때 tcpd이 보호하는 서버로의 접근을 허가할지 불허할지에 대한 규칙을 담고 있는 두 개의 파일을 읽어들인다.
서비스에 해당하는 룰이 처음 나타날 때까지 파일들을 검색하고 알맞는 규칙이
없으면 접근은 누구에게나 허가된다. 파일을 검색하는 순서는 /etc/hosts.allow
, /etc/hosts.deny 순이다. 이 두 개를 차례대로 설명할 것이다. 이 기능을
완벽히 쓰기 위해선 적당한 man 페이지를 참조해야 한다
(hosts_access(5)는 좋은 시작점이다).
/etc/hosts.allow 파일은 /usr/sbin/tcpd 프로그램의 설정
파일이다. hosts.allow 파일은 여러분의 머신의 서비스에 연결이
허용되는 호스트들을 나타내는 규칙을 포함하고 있다.
이 파일의 형식은 매우 간단하다.
# /etc/hosts.allow
#
# <service list>: <host list> [: command]
service list 이 규칙이 적용되는 서버 이름을
콤마로 구분해 놓은 목록이다. 서버 이름은 ftpd,
telnetd나 fingerd 같은 것들이다.
host list 콤마로 구분된 호스트 이름들의
목록이다. 여기에 IP 주소를 쓸 수도 있다. 추가적으로 호스트
이름을 명시하거나 한 그룹의 호스트을 나타내기 위해 와일드카드
문자를 사용한 주소를 쓸 수도 있다. 예를 들어
gw.vk2ktj.ampr.org는 특정 호스트를, .uts.edu.au는
이 문자열로 끝나는 모든 호스트 이름들을, 44.는 이
숫자로 시작하는 모든 IP 주소를 나타낸다. 설정을 간편하게
하기 위한 특정 기호가 있는데, LOCAL은 `.'를 이름
안에 포함하지 않는 모든 호스트 다시말해 여러분의 호스트와
같은 도메인 상에 있는 모든 호스트를 나타내며 PARANOID는
이름과 주소가 일치하지 않는 모든 호스트 (name spoofing)를
나타낸다. 매우 유용한 마지막 기호가 있다. EXCEPT는
예외 목록을 나타낼 수 있도록 해준다. 이는 뒤의 예제에서
다시 다뤄질 것이다.
command 이 매개변수는 선택사항이다. 이 변수는
이 규칙이 적용될 때마다 실행될 명령의 완전한 경로이름이다.
예를 들어 호스트에 접속한 사람을 판별하기 위한 명령을 실행할
수도 있고 누군가 접속을 시도할 때 관리자에게 경고 등의
메시지나 메일을 보내도록 할 수도 있다. 사용 가능한 많은
확장 기능이 있으며 흔히 쓰이는 것들은 접속한 호스트의 이름이나
주소를 나타내는 %h와 불려지는 데몬 이름을 나타내는
%d 등이다.
예제
# /etc/hosts.allow
#
# Allow mail to anyone
in.smtpd: ALL
# All telnet and ftp to only hosts within my domain and my host at home.
telnetd, ftpd: LOCAL, myhost.athome.org.au
# Allow finger to anyone but keep a record of who they are.
fingerd: ALL: (finger @%h | mail -s "finger from %h" root)
/etc/hosts.deny 파일은 /usr/sbin/tcpd 프로그램의 설정
파일이다. hosts.deny 파일은 여러분의 머신의 서비스에 접속을
불허하는 호스트들을 나타내는 규칙을 가지고 있다.
간단한 예는 아래와 같다.
# /etc/hosts.deny
#
# Disallow all hosts with suspect hostnames
ALL: PARANOID
#
# Disallow all hosts.
ALL: ALL
다른 엔트리가 모든 경우에 모든 것을 불허하기 때문에 사실상 PARANOID
엔트리는 중복으로 쓰인 것이다. 이 둘중 하나는 여러분의 특별한 요구에 따라서
합리적인 기본 설정이 될 것이다.
/etc/hosts.deny 안에 ALL: ALL를 기본으로 넣어 놓고 원하는
서비스와 호스트들을 /etc/hosts.allow 파일 안에서 명시적으로 허가하는
것이 가장 안전한 설정법이다.
hosts.equiv 파일은 특정 호스트와 사용자에게 암호 없이 여러분의 머신의
계정에 접속할 권한을 주기 위해 사용된다. 이는 여러분이 모든 머신을 제어하는
안전한 환경에선 유용하지만 그렇지 않다면 보안의 헛점이 될 수 있다. 여러분의
머신은 여러분이 신뢰하는 호스트들 중 가장 안전하지 못한 것 만큼만 안전하다.
보안을 최대화하기 위해선 이 메카니즘을 사용하지 말고 사용자들에게 .rhosts
파일 또한 쓰지 말 것을 권하라.
많은 사이트들이 다른 사람들에게 특정 사용자 ID 없이 파일을 올리고 받도록 하기
위해 어노니머스(anonymous) ftp 서버를 돌리는 것에 관심이 있다. 만약
여러분이 이를 하기로 했다면 어노니머스 접근에 대해 ftp 데몬을 알맞게
설정하도록 주의해야 한다. ftpd(8)에 대한 대부분의 man 페이지들이
이에 대한 방법을 어느 정도 설명하고 있으며 항상 거기에 나온 지시사항들을
따라야 한다. 중요한 팁은 어노니머스 계정의 /etc 디렉토리 안에
/etc/passwd 파일의 복사본을 넣어놓지 말라는 것과 정말 사용해야 하는
계정을 제외한 나머지 것들을 다 빼버리라는 것이다. 그렇지 않으면 brute force
패스워드 크랙 기법에 노출될 위험이 있다.
데이타그램이 여러분의 머신이나 서버에 도달조차 하지 못하도록 하는 것은 매우 훌륭한 보안 방법이다. 이는 Firewall-HOWTO와 이 문서의 뒷부분에서 좀 더 자세히 다뤄질 것이다.
고려해야 할 다른 문제들.
널리 쓰임에도 불구하고 sendmail 데몬은 보안 위험 보고에 매우 자주 등장한다. 모든건 여러분에게 달려 있지만 나는 이 데몬을 돌리지 않기로 했다.
매우 주의깊게 이들을 살펴봐야 한다. 이 서비스들에는 가능한 모든 종류의 보안 구멍이 있다. NFS 같은 서비스의 옵션들을 찾는 것이 어렵지만 이를 설정하게 된다면 누구에게 mount 권한을 부여할 것인지 매우 신중하라.