Chapter 5
|
D.M.Z
CONTENT
PRE
NEXT
5.1 Setting up the proc Filesystem
5.2 Installing the Binaries
5.3 Another Example
5.4 Setting the Hostname
5.5 Assigning IP Addresses
5.6 Writing hosts and networks Files
5.7 Interface Configuration for IP
5.8 All About ifconfig
5.9 Checking with netstat
5.10 Checking the ARP Tables
5.11 The Future
이 chapter에서, 당신의 머신에 TCP/IP 네트워킹을 설정하는데 필요한 단계를 모두 살펴볼 것이다. IP 주소를 지정하는데서 시작하여, TCP/IP 네트웍 인터페이스를 찬찬히 살피며, 네트웍을 설치할 때 생기는 문제점들을 사냥할 때 간편한 몇가지 툴을 소개할 것이다.
이 장에서 다루는 것들중 대부분이, 보통 한번만 하면 되는 것들이다. 그 후, 새 시스템을 네트웍에 추가하거나,시스템을 전반적으로 재설정할 때엔 대부분의 설정파일을 건드려야 한다. TCP/IP를 설정하는 몇몇 커맨드는 시스템 부팅시에 매번 실행되어야만 하는데, 이는 시스템 /etc/rc 스크립트에서 이루어진다.
통상적으로, 이 프로시저의 네트웍 특정 부분이 포함되어 있는 곳은 rc.net 또는 rc.inet 스크립트이며, 때때로 rc.inet1과 rc.inet2라는 이름의 두 스크립트를 볼 수도 있는데, 첫번째에선 네트워킹의 커널부분을 초기화하고, 다음번 것에선 기본적인 네트웍 서비스와 어플리케이션을 동작시킨다. 다음부턴 계속 후자의 개념의 설명에 주력할 것이다.
어플리케이션은 이후의 chapter에서 다루도록 하고, 아래에서는 rc.inet1이 수행하는 동작에 대해 논의할 것이다. 이 chapter를 다 읽고나면 당신의 컴퓨터에 TCP/IP 네트워킹을 적절히 설명하는 일련의 커맨드를 숙지할 수 있을 것이다. 이제, 샘플 커맨드를 당신이 원하는대로 바꾸고, rc.inet1이 시스템 시작시에 실행되므로 시스템을 리부팅 시키자. 당신이 즐기는 리눅스 배포판에 딸려오는 네트워킹 rc 스크립트는 좋은 예제가 될 것이다.
5.1 Setting up the proc Filesystem
Net-2 릴리즈의 몇몇 설정 툴은 커널과 교신하는데 proc 파일 시스템에 의존한다. 이 파일 시스템은 파일시스템과 동일한 메카니즘을 통해 커널의 run-time 정보에 접근하게 하는 것이며, mount하면 다른 어떤 파일시스템과 동일하게 list하고 내용을 볼 수 있다. 보편적인 아이템은, 시스템 load 평균치를 나타내는 loadavg 파일과, 현재의 핵심 메모리와 스왑(swap) 사용치를 보여주는 meminfo를 가지고 있다.
이를 위해서, 네트워킹 코드는 net 디렉토리를 추가로 생성하는데, 그것은 커널의 ARP 테이블, TCP 커넥션의 상태, 그라ㅣ고 라우팅 테이블 같은 것을 보여주는 몇개의 파일을 포함하는데, 대부분의 관리용 툴은 이들 파일에서 정보를 얻는다.
proc 파일 시스템 (또는 procfs로 알려져 있다)는 보통 시스템 부팅시에 /proc에 mount된다. 최선의 방법은 다음의 라인을 /etc/fstab에 추가하는 것이다.
# procfs mount point:
none /proc proc defaults
그리고 /etc/rc 스크립트에서 "mount /proc"을 실행하라.
오늘날에는, procfs가 커널에 디폴트로 설정되어지나, 만약 커널 내부에 procfs가 없다면 다음의 메시지를 볼 것이다. : "mount: fs type procfs not supported by kernel". 그러면 procfs 지원을 물어올 때 "yes"를 선택하고 커널을 재 컴파일 해야 한다.
만약 패키지화된 리눅스 배포판 중의 하나를 사용하고 있다면, 그것은 아마도 주요 네트워킹 어플리케이션과 유틸리티가 관련된 샘플 파일과 더불어 포함되어 있을 것이다. 당신이 새 유틸리티를 구해서 설치해야만 할 경우는 새 커널 릴리즈를 설치할 때 뿐이다. 때때로, 그것들이 커널 네트워킹 레이어의 변화를 수반하므로, 기번 설정 툴을 업데이트할 필요성이 있는데, 이는 적어도 재 컴파일을 필요로 하며, 때때로는 바이너리 셋의 최근판을 얻어야 하기도 한다. 이는 흔히 net-XXX.tar.gz(XXX는 버전 번호이다.)라는 이름으로 패키징되어 커널에 따라 배포된다. Linux 1.0에 맞는 것은 0.32b이고, 이글을 적을 당시의 최신판 (1.1.12와 그 후 버전)은 0.32d를 요구한다.
만약, 표준 TCP/IP 네트웍 어플리케이션을 손수 컴파일 하여 설치하고 싶다면, Linux FTP 서버들에서 그 소스를 구할 수 있다. 이들은 다소 정도가 크게 패치된 Net-BSD 또는 그외의 소스의 프로그램 버전이다. 그 외의 어플리케이션, 즉 Xmosaic, xarchie 또는 Gopher와 IRC 클라이언트와 같은 것들은 별도로 구해야 하며, 대부분이 지시사항을 따르면 돈 안들이고 컴파일 할 수 있다.
Net-3의 공식 FTP 사이트는 sunacm.swan.ac.uk이고, sunsite.unc.edu의 system/Network/sunacm에서 미러링하고 있다. Net-2e의 최신 패치 킷은 ftp.aris.com에서 구할 수 있고, Mathias Urliche의 BSD 유래 네트워킹 코드는 ftp.ira.uka.de의 /pub/system/linux/netbsd내에서 얻을 수 있다.
5.3 Another Example
이 책의 나머지를 위해, Groucho Marx University보다는 덜 복잡하고, 당신이 실제로 직면할 일과 가까운 새로운 예제를 소개하고자 한다. Virtual Brewery라는 이름이 가리키듯, 가상의 맥주를 양조하는 작은 회사를 가정하라. virtual brewer는 그들의 사업을 보다 효과적으로 운영하기 위해 찬란하고도 빛나는 Linux 1.0을 돌리는 PC일 그들의 컴퓨터를 네트웍으로 묶길 원할 것이다.
같은 층의 바로 복도건너에는 brewery와 가까이 일하는 Virtual Winery가 있으며, 그들은 자체적으로 이더넷을 운영하고 있다. 아주 자연스럽게, 이 두회사는 사용가능하기만 한다면, 그들의 네트웍을 링크시키길 원할테고, 그 첫번째 단계로 그들은 두 서브넷간에 데이터그램을 포워딩하는 게이트웨이를 설정하고, 다음으로 외부세계와 mail, news를 교환하고자 UUCP 링크를 만들게 되며, 장기적으로는 인터넷에 때때로 접속하는 SLIP 커넥션을 설정하기도 할 것이다.
전부가 아니더라도, 대부분의 네트웍 어플리케이션은 어떤 적절한 값으로 설정된 로컬 호스트네임에 의존한다. 이는 보통 부팅하는 동안 hostname 컨맨드를 실행시켜서 설정하는데, 호스트명을 name으로 설정할려면, 다음과 같이 하라.
# hostname name
이는 도메인네임 없이 인증받지 않은 호스트네임을 사용하는 일상적인 예이다. 예를 들어, Virtual Brewery의 호스트는 vale.vbrew.com, valrger.vbrew.com 등으로 불리워질 수 있는데, 이는 공식적인 FQDN이다. 그들의 로컬 호스트네임은 FQDN의 첫번째 요소, 즉 vale과 같은 것이다. 그러나, 로컬 호스트네임이 호스트의 IP 주소를 찾는데 종종 사용되므로, resolver 라이브러리가 호스트의 IP 주소를 찾아낼 수 있는지 확인해야 한다. 이는 즉, /etc/hosts에 이름을 집어넣어야 한다는 뜻이다.(아래를 참고하라)
어떤 이들은 domainname 커맨드를 사용하여 커널이 갖고있는 도메인네임이 FQDN의 나머지부분으로 설정되도록 만들길 제안한다. 이러한 방법으론, hostname과 domainname의 output을 조합하여 FQDN을 만들 수 있으나, 이는 반정도 맞다고 할 수 있겠다. domainname은 일반적으로 호스트의 NIS 도메인을 지정할 때 사용되며, 이는 호스트가 속한 DNS 도메인과는 완전히 별개의 것이다. NIS에 관해선 chapter 10에서 다룰 것이다.
5.5 Assigning IP Addresses
standalone으로 동작하는 당신의 호스트에 네트워킹 소프트웨어를 설정하고자 한다면 (예를 들어, INN netnews 소프트웨어를 운영가능케 하고자 할 때), 이 절을 건너뛰어도 상관 없다. 이유는 단지 loopback 인터페이스에 부여되는 단 하나의 IP 만을 필요로할 것이기 대문이며, 그 값은 언제나 127.0.0.1이다.
이더넷과 같은 실제 네트웍에서는 상황이 좀 더 복잡하다. 만약, 실재하는 네트웍에 당신의 호스트를 연결하고자 한다면, 관리자에게 이 네트웍 상의 IP 주소를 달라고 요청해야 한다. 모든 네트웍을 당신이 세팅해야 한다면, 아래에 적힌대로 IP 주소를 직접 지정해야 한다.
로콜 네트웍 내의 호스트들을 동일한 논리 IP 네트웍의 주소를 공유하므로, IP 네트웍 주소를 지정해야 한다. 만약, 몇개의 물리적 네트웍이라면, 각기 다른 IP 네트웍 번호를 지정하거나 서브넷팅을 사용해 IP 영역을 몇개의 서브 네트웍으로 나눌 수 있다.
당신의 네트웍이 인터넷에 연결되어 있지 않다면, 어떠한 (적절한) 네트웍 주소를 선택하든 상관 없다. calss A, B 또는 C 중의 하나를 선택해야만 한다. 그렇지 않으면 제대로 동작하지 않을 것이다. 그러나, 가까운 미래에 인터넷에 연결하고자 한다면, 지금 공식적인 IP 주소를 얻는 편이 좋다. 가장 좋은 방법은 네트웍 서비스 제공자에게 도움을 요청하는 것이다. 언젠가 인터넷에 연결할 수도 있을 경우에 네트웍 번호를 얻고자 한다면, hostmaster@internic.net에 Network Address Application Form을 요청하라.
여러개의 이더넷(또는 드라이버가 나와 있는 다른 네트웍)을 작동하려면 당신의 네트웍을 몇개의 서브넷으로 나누어야 한다. 서브네팅은 하나 이상의 broadcast network을 요구한다(물론 point-to-point 링크는 계산하지 않는다). 예를 들어, 하나의 이더넷과, 하나 또는 그 이상의 외부로의 SLIP 링크를 지닌다면, 네트웍을 서브넷으로 분할할 필요가 없으며, 그 이유는 chapter 7에서 설명할 것이다.
예로써, brewery의 네트웍 관리자는 NIC에 class B 네트웍을 요청하여 191.72.0.0을 얻는다. 두 이더넷을 수용하기 위해, 그녀는 8bit의 호스트 부분을 추가적인 서브넷 비트로 사용하기로 결정하면, 나머지 8bit가 254개의 호스트를 각 서브넷마다 허용하는 호스트 부분으로 남겨진다. 그리고 그녀는 brewery에 1을, winery에 2를 지정하여 각 네트웍 주소는 191.72.1.0 과 191.72.2.0이 되고, 서브넷 매스크는 255.255.255.0가 된다.
그림 5.1: Virtual Brewery와 Virtual Winery - 두개의 서브넷
이 예제에서 좀 더 단순하도록 Class B 네트웍을 사용했다는데 주의하자. class C 네트웍이 좀 더 현실적이다. 새로운 네트워킹 코드는 서브네팅이 byte 범위에 제한되지 않으므로 class C 네트웍도 몇개의 서브넷으로 나뉠 수 있다. 예를 들어, 당신은 호스트 부분의 2bit을 넷 매스크로 사용할 수도 있는데, 이는 각각 64개의 호스트를 가질 수 있는 4개의 서브넷을 만들 수 있게 한다.
Writing hosts and networks Files
당신의 네트웍을 서브네팅한 후, 당신은 /etc/hosts 파일을 사용하여 간단한 hostname resolution을 준비해야 한다. 만약 당신이 DNS나 NIS를 address resolution에 사용하고자 하지 않는다면 모든 호스트를 hosts 파일에 집어넣어야 한다.
평상시에 DNS나 NIS를 돌리길 원할지라도, /etc/hosts에 서브넷상의 모든 호스트네임을 넣어 주는 것이 좋은데, 부팅시와 같이 어떤 네트웍 인터페이스도 동작중이지 않을 때와 같은 경우에도 name resolution을 사용하고자 하기 때문이다. 그러나, 이는 편의성의 문제에 그치는 것이 아니라 rc.inet 스크립트에 심볼릭 호스트네임을 사용할 수도 있게 한다. 그리하여, IP 주소를 변경할 때. 보다 많은 개수의 rc 파일을 일일히 편집하지 않고, 단지 hosts 파일을 업데이트 시켜 모든 머신에 복사하고 리부팅하면 되는 것이다. 보통, 당신은 hosts 파일에 모든 로컬 호스트네임과 주소, 그리고 게이트웨이와 NIS 서버가 사용 중이라면 그것들도 추가된다.
최초 테스팅 중엔, 당신의 resolver가 hosts파일의 정보만을 사용하는지 확인해야 한다. 당신의 DNS 또는 NIS 소프트웨어는 이상한 결과를 초래할 수도 있는 샘플파일을 포함하는 경우도 있다. 모든 어플리케이션이 호스트의 IP 주소를 찾을 때, /etc/hosts 파일만을 독점적으로 사용하도록 하려면, /etc/hosts.conf파일을 편집해야 한다. order 키워드로 시작하는 라인 앞에 해쉬 기호를 추가하여 코멘트 아웃 시키고, 다음의 라인을 넣으라.
order hosts
resolver 라이브러리 설정은 chapter6에서 다룬다.
hosts 파일은, IP 주소, 호스트네임, 그리고 호스트네임에 대한 선택적인 앨리어스를 포함하는, 한 라인당 하나의 엔트리를 가진다. 각 필드는 스페이스나 탭으로 분할되며 주소필드는 첫번째 칸에서 시작되어야 한다. 해쉬 기호(#)뒤의 어떤 것도 주석문으로 처리되어 무시된다.
호스트네임은 FQDN이거나, 로컬 도메인에 연계된 형태로 쓸 수 있다. vale의 경우, 보통 당신은 FQDN, 즉 vale.vbrew.com과 vale을 hosts 파일에 넣을 것이다. 그리하여 그것은 공식적인 명칭과 로컬 호스트네임으로 동시에 알려진다.
다음은 Virtual Brewery의 hosts파일이 어떻게 나타날 수 있는지의 예이다. 두개의 특수 명칭이 포함되는데, vlager-if1과 vlager-if2는 vlager에서 사용하는 두개의 인터페이스에 주소를 부여한다.
#
# Hosts file for Virtual Brewery/Virtual Winery
#
# IP local fully qualified domain name
#
127.0.0.1 localhost
#
191.72.1.1 vlager vlager.vbrew.com
191.72.1.1 vlager-if1
191.72.1.2 vatout vstout.vbrew.com
191.72.1.3 vale vale.vbrew.com
#
191.72.2.1 vlager-if2
191.72.2.2 vbeaujolais vbeaujolais.vbrew.com
191.72.2.3 vbardolino vbardolino.vbrew.com
191.72.2.4 vchianti vchianti.vbrew.com
호스트의 IP 주소처럼, 네트웍 번호에도 때때로 심볼릭 네임을 사용하고 싶을수도 있다. 게다가, hosts 파일과 유사한 /etc/networks 파일은 네트웍 네임을 네트웍 번호로 매칭하거나 그 반대로 할 수 있다. Virtual Brewery에서 당신은 다음과 같이 networks 파일을 넣을 수 있다.
# /etc/networks for the Virtual Brewery
brew-net 191.72.1.0
wine-net 191.72.2.0
5.7 Interface Configuration for IP
지난 장에서 설명한 것 같이 하드웨어를 설치했다면, 이제 이 디바이스를 커널 네트워킹 소프트웨어에 알려주어야 한다. 네트웍 인터페이스를 설정하고 라우팅 테이블을 초기화 하는데엔 두개의 커맨드가 쓰이는데, 이들은 시스템 부팅시마다 rc.inet1 스크립트애서 보통 수행된다. 이를 위한 기초적인 툴은 ifconfig("if"는 인터페이스의 약어)과 route이다.
ifconfig은 인터페이스가 커널 네트워킹 레이어에 접근할 수 있게 한다. 이것을 위해서는 IP와 그 외 파라미터를 지정하고, 인터페이스를 활성화시켜야 하는데, 이를 "taking up"이라고도 부른다. 활성화된다는 것은 커널이 그 인터페이스를 통해 IP 데이터그램을 주고 받는다는 것을 의미하며, 그것을 호출하기 위한 가장 단순한 방법은,
ifconfig interface ip-address
라고 하는 것으로, 이는 ip-address를 interface로 지정하고 활성화 하며, 모든 그 외의 파라미터는 디폴트 값으로 설정된다. 예를 들어, 디폴트 서브넷 매스크는 IP 주소의 네트웍 클래스에서 얻어지며, class B 네트웍의 경우 255.255.0.0 같은 것이 주어진다. ifconfig의 보다 세부적인 설명은 이 chapter의 마지막에 있다.
route는 커널 라우팅 테이블에 루트(route)를 추가하거나 제거할 수 있게 한다. 그것은 다음과 같이 호출할 수 있다.
route [add|del] target
add와 del인자는 target에 루트를 추가하건지 제거할 것인지를 결정한다.
최초로 활성화되는 인터페이스는 loopback 인터페이스이다.
# ifconfig lo 127.0.0.1
때때로, IP 주소 대신에 사용되는 dummy 호스트네임, localhost를 볼 수 있다. ifconfig은 127.0.0.1에 대한 호스트네임으로 선언된 이름을 hosts파일에서 검색할 것이다.
# Sample /etc/hosts entry for localhost
localhost 127.0.0.1
한 인터페이스의 설정상태를 보고자 한다면, 인터페이스 명칭을 인자로 주고 ifconfig을 실행하라.
$ ifconfig lo
lo Link encap Local Loopback
inet addr 127.0.0.1 Bcast [NONE SET] Mask 255.0.0.0
UP BROADCAST LOOPBACK RUNNING MTU 2000 Metric 1
RX packets 0 errors 0 dropped 0 overrun 0
TX packets 0 errors 0 dropped 0 overrun 0
보는 바와 같이, loopback 인터페이스의 넷 매스크는 255.0.0.0으로 지정되는데, 이유는 127.0.0.1이 class A이기 때문이다. 알다시피, broadcast 주소 셋이 loopback을 위해선 거의 유용성이 없기에, 이 인터페이스는 그것을 지니고 있지 않다. 하지만, 호스트에 rwhod 데몬을 돌린다면 rwho를 완전하게 동작시키기 위해 loopback 디바이스의 broadcast 주소를 설정해야 한다. broadcast의 셋팅은 아래의 "All about ifconfig" 절에서 설명한다.
이제 당신은, 당신의 작은-"네트웍"을 가지고 놀 수 있다. 아직 빼먹은 일이 있다면, IP에게 이 인터페이스를 목적지 127.0.0.1로의 루트(route)로 사용할 수 있도록 하는 라우팅 테이블의 한 엔트리를 추가하는 것이다. 이는 다음과 같이 타이핑하면 된다.
# route add 127.0.0.1
위에서, 당신은 IP 주소 대신에 localhost를 사용할 수 있다.
다음으로는, ping과 같은 것으로 모든 것이 잘 동작하는지 검사해야 한다. ping은 네트워킹에서의 수중음파 탐지기이고, 주어진 주소가 실제로 도달 가능한 지 확인하고, 데이터 그램을 보내고 다시 되돌아오는데 발생하는 지연시간을 측정하는데 사용된다. 이러한 것에 소요되는 시간을 일컬어 round-trip time이라 한다.
# ping localhost
PING localhost (12.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=32 time=1 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=32 time=0 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=32 time=0 ms
^C
--- localhost ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0/0/1 ms
여기서 보는 바와 같이 ping을 발동하면, 그것은 사용자가 중단할 때 까지 계속 패킷을 뱉어낼 것이다. ^C 마크가 있는 곳은 우리가 Ctrl-C를 누른 위치이다.
위의 예제에서 127.0.0.1로의 패킷은 완전한 형태로 배달되며, 즉시 reply가 돌아온다. 이는 당신의 첫번째 인터페이스가 성공적으로 세팅되었음을 나타낸다.
ping의 output이 위와 같지 않다면, 문제가 있는 것이다. 어떤 파일이 완전히 설치되지 않았는지 에러를 체크하라. ifconfig과 route 바이너리가 사용 중인 커널 릴리즈에 호환되는지, 그리고 무엇보다도 커널이 네트워킹이 가능하도록 컴파일 되었는지 (이는 /proc/net 디렉토리의 유무로 알 수 있다)를 체크하라. 만약, "Network unreachable"이란 에러메시지가 뜬다면, route 커맨드를 아마도 잘못 사용했을 것이다. ifconfig에 준 것과 같은 주소를 사용했는지 확인하라.
위에서 기술한 방법으로도 standalone 호스트에서 네트워킹을 사용하는데 충분하다. 위의 라인을 rc.inet1에 추가하고, 두 rc.inet 스크립트가 모두 /etc/rc에서 실행되는지 확인한 뒤, 머신을 리부팅하고 여러 어플리케이션을 사용해보라. 예를 들어, "telnet localhost"는 당신의 호스트로의 telnet 커넥션을 수립하고 login 프롬프트를 내어 놓는다.
그러나, loopback 인터페이스는 네트워킹에 관련된 책의 예제나, 개발중의 testbed로써 유용할 뿐 아니라, 몇몇 어플리케이션이 정상적으로 동작하게끔 할 때도 사용된다. 그리하여, 당신은 머신이 네트웍에 물려있든지 말든지간에 그것을 설정해 주어야 한다.
이더넷 인터페이스를 설정하는 것은, 세브네팅을 사용할 때 약간의 파라미터가 좀 더 필요하다는 점을 제외하면 loopback 인터페이스를 설정하는 것과 별반 다를 바 없다.
Virtual Brewery에서 우리는 원래 class B 네트웍이었던 것을 class C 네트웍으로 IP 네트웍을 서브넷화 했다. 이를 인터페이스에 인식시키려면, 다음과 같이 ifconfig을 실행하라.
# ifconfig eth0 vstout netmask 255.255.255.0
이는 eth0인터페이스에 vsout (191.72.1.2)의 주소를 할당한다. 위에서 넷 매스크를 빼버련다면, ifconfig은 IP 네트웍 클래스에서 넷 매스크를 추론해 내는데, 그 값은 255.255.0.0이 되어버린다. 이제, 간단히 체크해 보자.
# ifconfig eth0
eth0 Link encap 10Mps Ethernet HWaddr 00:00:C0:90:B3:42
inet addr 191.72.1.2 Bcast 191.72.1.255 Mask 255.255.255.0
UP BROADCAST RUNNING MTU 1500 Metric 1
RX packets 0 errors 0 dropped 0 overrun 0
TX packets 0 errors 0 dropped 0 overrun 0
ifconfig이 broadcast 주소 (위에서 Bcast필드)를 통상 값, 네트웍 번호에 호스트 bit을 모두 1로 지정한 값으로 설정하는 것을 볼 수 있다. 그리고 maximum transfer unit (이 인터페이스를 위해 커널이 생성하는 이더넷 프레임의 최대 크기)엔 1500byte의 최대 값이 설정된다. 이 값은 특별한 옵션을 지정함으로써 override할 수 있으며, 이에 관해선 나중에 설명한다.
loopback의 경우와 비슷하게, 이제 당신은 eth0를 통하여 도달할 수 있는 네트웍에 관해 커널에 정보를 제공하는 라우팅 엔트리를 설치해야 한다. Virtual Brewery의 경우, 다음과 같이 route를 실행하라.
# route add -net 191.72.1.0
먼저, 어떻게 route가 라우트할 인터페이스를 찾아낼 것인지를 명백히 알려주지 않기 때문에, 마치 마술처럼 보이기도 하지만, 그 트릭은 다소 간단한 것이다. 즉, 커널은 지금까지 설정한 모든 인터페이스를 체크하여, 목적지 주소 (이경우 191.72.1.0)를 인터페이스 주소 (즉, 인터페이스와 넷 매스크의 bitwise AND)의 네트웍 부분과 비교한다. 상응하는 인터페이스는 eth0뿐이다.
그럼, -net은 무엇인가? 이것은 route가 네트웍으로, 그리고 싱글 호스트로의 루트를 조정할 수 있기 때문이다(localhost에서 이미 본 바 있다). 주소를 dotted quad notation으로 주었을 때, 그것은 호스트 부분의 bit을 봐서 네트웍인지 호스트네임인지를 추측하려 한다. 만약 주소의 호스트 부분이 0 값이면, route는 그것이 네트웍을 지칭한다고 가정하고, 그렇지 않다면 호스트의 주소라고 간주한다. 그리하여, route는 191.72.1.0가 네트웍 번호가 아닌 호스트 주소라고 생각하느데, 그 이유는 그것이 우리가 서브네팅을 사용하고 있는지에 관해 모르기 때문이다. 그래서 -net 플래그를 줌으로써 그것이 네트웍을 가리킨다는 것을 말해 주어야 한다.
물론, 위의 route 커맨드를 쳐 넣는 것은 귀찮고, 실수할 수도 있다. 보다 편리한 방법은 위에서 /etc/networks에 정의한 네트웍 네임을 사용하는 것이다. 이는 커맨드를 보다 읽기 쉽게 한다. 즉, -net 옵션은 이제 생략되며, 이유는 route가 191.72.1.0이 네트웍을 가리킨다는 것을 알고 있기 때문이다.
# route add brew-net
이제 기본적인 설정 단계는 끝났다. 그러면 당신의 이더넷 인터페이스가 정말로 잘 돌아가고 있는지 확인하고 싶을텐데, 당신의 이더넷 상의 한 호스트, 예로써 vlager를 선택하고 다음을 쳐 넣으라.
# ping vlager
PING vlager: 64 byte packets
64 bytes from 191.72.1.1: icmp_seq=0, time=11. ms
64 bytes from 191.72.1.1: icmp_seq=1, time=7. ms
64 bytes from 191.72.1.1: icmp_seq=2, time=12. ms
64 bytes from 191.72.1.1: icmp_seq=3, time=3. ms
^C
----vstout, vbrew.com PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 3/8/12
위와 같은 결과를 얻지 못한다면, 틀림없이 무언가가 잘못 되어 있는 것이다. 만약, 일상적이지 않은 패킷 유실율 (packet loss rate)은, 그것은 종결자 (terminator)가 좋지않거나 유실된것 같은 하드웨어적인 문제가 있다는 암시이다. 만약 당신이 패킷을 전혀 받지 못한다면 netstat으로 인터페이스 설정을 체크해야 한다. ifconfig이 표시하는 패킷 통계치는, 어떤 패킷이 그 인터페이스를 통해 외부로 보내지는 지를 말해준다. 리모트 호스트에 접근할 수 있다면, 그 머신에서의 인터페이스 통계도 역시 체크해야 한다. 이러한 방법으로, 패킷이 어디서 drop되는지를 정확히 알 수 있다. 게다가, 두 호스트가 올바른 라우팅 엔트리를 갖고있는지 아닌지를 살펴보기 위해 route로 라우팅 정보를 표시하는 것도 잊지 말아야 한다. route는 인자 없이 실행되면, 완전한 커널 라우팅 테이블을 출력한다. (-n 옵션은 단지 호스트네임을 사용하는 대신 dotted quad notation으로 표현된 주소를 출력하게 만드는 것 뿐이다.)
# route -n
Kernel routing table
Destination Gateway Genmake Flags Metric Ref Use Iface
127.0.0.1 * 255.255.255.255 UH 1 0 112 lo
191.72.1.0 * 255.255.255.0 U 1 0 10 eth0
이 필드의 세부적인 의미는 아래의 Checking with netstat 섹션에서 설명한다. Flag 컬럼엔 각 인터페이스에 지정된 플래그의 목록이 들어있다. U는 동작중인 인터페이스에 언제나 설정되며, H는 목적지 주소가 호스트를 지칭함을 나타낸다. 만약, H 플래그가 네트웍 루트(route)로 만들려는 루트에 지정된다면, route 커맨드에서 -net 옵션을 지정해 줘야 한다. 당신이 지정한 루트가 제대로 사용 중인지 검사하려면, 뒤에서 두번째인 Use 필드의 수가 ping을 돌리기 전보다 돌린 후에 증가했는지 체크하라.
5.7.3 Routing through a Gateway
앞에선, 싱글 이더넷 상의 호스트를 세팅하는 경우만을 다루었다. 그러나, 게이트웨이를 통해 또 다른 네트웍에 연결된 네트웍을 흔히 볼 수 있을 것이다. 이러한 게이트웨이는 단순히 둘 또는 그 이상의 이더넷을 단순히 링크시킬 뿐 아니라, 인터넷 같은 외부세계로도 링크시킨다. 게이트웨이 서비스를 이용하려면 추가적인 라우팅 정보를 네트워킹 레이어에 주어야 한다.
예를 들어, Virtyal Brewery 와 Virtual Winery의 이더넷은 게이트웨이, 즉 vlager를 통해 링크되어 있다. vlager가 이미 설정이 끝난 상태라 가정하면, 우리는 단지 vstout의 라우팅 테이블에 vlager를 통해 Winery 네트웍상의 모든 호스트에 도달할 수 있다는 것을 커널에 알려줘야 한다. 적절한 route의 실행법은 다음과 같다. gw 키워드는 다음의 인자가 게이트웨이임을 지칭한다.
# route add wine-net gw vlager
물론, 당신이 교신하고자하는 Winery의 네트웍상의 어떤 호스트도 Brewery의 네트웍을 위한 동일한 라우팅 엔트리를 갖고 있어야 한다. 그렇지 않다면 vstout에서 vbardolino로 데이터를 보낼 수는 있으나, vbardolino에서 돌아오는 대답은 큰 bit bucket으로 들어가게 된다(drop된다는 의미로 보여짐: bit bucket의 정확한 의미를 잘 모름-역자주).
이 예제는 단지 고립된 두 이더넷 간에 패킷을 교환하는 게이트웨이에 대해서만 기술한다. 이제, vlager가 (추가적인 SLIP 링크를 통해) 인터넷에도 연결되어 있다고 가정해보자. 그러면 우리는 Brewery 외의 다른 네트웍으로의 데이터그램이 vlager에 넘겨지길 원할테고, 이는 것을 vstout에 대한 게이트웨이로 만듦으로써 가능하다.
# route add default gw vlager
네트웍네임 default는 0.0.0.0의 약칭으로, 기본 루트를 가리킨다. 이 이름을 /etc/networks에 추가할 필요는 없으며, 그 이유는 route에 내장되어 있기 때문이다.
하나 이상의 게이트웨이를 거치는 호스트에 ping을 사용할 때 높은 패킷 유실률이 발생한다면, 이는 네트웍이 아주 혼잡하다는 것을 의미한다. 패킷 유실은 기술적인 결함의 이유뿐 아니라, 포워딩 호스트의 일시적인 초과 로드(load)로, incoming 데이터그램을 지연시키거나 심지어 drop시키는데서도 발생한다.
두 이더넷 간에 패킷을 교환하도록 머신을 설정하는 것은 꽤 직선적이다. 각 네트웍에 하나씩 연결된 두개의 디더넷 보드를 장비한 vlager로 돌아가 보자. 당신이 해야할 것은 두 인터페이스를 별도로 설정하는 것으로, 그들에 연관된 IP 주소를 주면 그것으로 끝이다.
다음의 방법으로 hosts 파일에 두 인터페이스에 관한 정보를 추가하는 것은 꽤 유용하다. 그래서 그들에 간편한 이름도 지어 놓았다.
191.72.1.1 vlager vlager.vbrew.com
191.72.1.1 vlager-if1
191.72.2.1 vlager-if2
그러면 두 인터페이스를 셋업하는 커맨드의 순서는:
# ifconfig eth0 vlager-if1 # ifconfig eth1 vlager-if2 # route add brew-net # route add wine-net
두 머신을 연결하기 위해 PLIP 링크를 사용할 때는, 모든 것이 이더넷을 사용할 때완 약간 다르다. 전자는 소위 point-to-point 링크라는 점으로, broadcast 네트웍과는 달리, 단 두 호스트("points")만이 링크에 참여한다.
예로써, Virtual Brewery의 몇몇 직원의 랩탑 컴퓨터가 PLIP을 통해 vlager에 연결되어 있다고 가정하다. 랩탑 자체는 vlite라고 불리며, 하나의 패러랠 포트만을 갖고 있다.부팅시에 이 포트는 plip1으로 등록되며, 이 링크를 활성화시키기 위해선 다음의 커맨드로 plip1 인터페이스를 설정해 주어야 한다.
# ifconfig plip1 vlite pointopoint vlager
# route add default gw vlager
첫번째 커맨드는, 이것은 point-to-point 링크이며 리모트 쪽의 이름은 vlager라고 커널에 말함으로써 인터페이스를 설정한다. 두번째는 vlager를 게이트웨이로 사용하는 기본 루트를 설치한다. 링크를 활성화시키기 위해서는 vlager에서도 비슷한 ifconfig 커맨드가 필요하다(route 실행은 필요치 않다).
# ifconfig plip1 vlager pointopoint vlite
재미있는 것은, vlager상의 plip1 인터페이스는 별개의 IP 주소를 가질 필요가 없고, 역시나 191.72.1.1이 주어져 있다.
이제, 랩탑에서 Brewery 네트웍으로의 라우팅은 설정했으나, 아직 Brewery의 호스트에서 vlite로 라우트 하는 방법이 남아있다. 한가지 방법은, 성가시지만 모든 호스트의 라우팅 테이블에 vlager를 vlite의 게이트웨이로 명하는 특정 루트를 추가하는 것이다.
# route add vlite gw vlager
일시적인 루트(route)일 때, 더 나은 선택은 동적 라우팅을 쓰는 것이다. 그렇게 하는 방법은 라우팅 정보를 동적으로 할당하기위해 라우팅 데몬인 gated를 네트웍상의 각 호스트에 사용하는 것이다. 그러나 가장 쉬운 방법은 proxy ARP를 사용하는 것이다. proxy ARP를 쓰면, vlager는 vlite에 대한 ARp 쿼리에 자신의 이더넷 주소를 보냄으로써 답할 것이다. 이것의 효과로, vlite에 대한 모든 패킷이 vlager로 날아가, 그것은 다시 이를 랩탑에 포워드 시키게 된다. 다음의 Checking the ARP Tables 섹션에서 proxy ARP에 관해 다시금 설명할 것이다.
미래의 Net-3 릴리즈엔, 프린터 포트를 사용하기 위해 IRQ를 설정할 수 있는 소위, plipconfig이라는 툴이 포함될 것이다. 그러나 이후, 좀 더 일반적인 ifconfig커맨드는 이것마저도 대체할 것이다.
5.7.6 The Slip and PPP Interface
SLIP과 PPP가 비록 PLIP처럼 단순한 point-to-point 링크라고는 하지만, 그에관해선 이야기 할 것이 더 많다. 보통, SLIP 커넥션을 수립하는데는 모뎀을 통해 리모트 사이트에 dial up하고 시리얼 라인을 SLIP 모드로 세팅하는 과정이 따른다. PPP 역시 비슷하게 사용된다. SLIP 이나 PPP 링크를 셋업하는데 필요한 툴은 chapter 7과 8에서 기술될 것이다.
Dummy 인터페이스는 좀 색다른 면이 있지만 유용한 것이다. 이는, standalone 호스트와, dial up 링크를 통해 IP 네트웍에 연결되어 있는 머신상에서 진가를 발휘한다. 사실, 후자는 대부분의 시간이 standalone 호스트이기도 하지만 말이다.
standalone 호스트의 딜레마는, 활성화된 네트웍 디바이스가, 보통 127.0.0.1의 주소가 할당된 loopback 디바이스 밖에 없다는 것이다. 그러나 어떤 상황에선 로컬 호스트의 '공식적인' IP 주소로 데이터를 보내야만 할 때도 있다. 예를 들어, 지금의 랩탑 vlite는 어떠한 네트웍에도 연결되지 않았다고 가정해 보자. vlite상의 어플리케이션은 같은 호스트상의 또다른 어플리케이션에 데이터를 보내고자 할 때, /etc/hosts내의 vlite를 검색하여 191.72.1.65의 주소를 찾아내게되고, 이 주소에 데이터를 보내려 한다. 활성화된 인터페이스가 현재 loopback 인터페이스 뿐이기 때문에 커널은 이 주소가 바로 자신을 가리키는 지를 알지 못한다! 결과적으로 커널은 데이터그램을 파기하고, 어플리케이션에 에러를 되돌린다.
바로 여기에 dummy 디바이스가 들어서는 것이다. 그것은 단순히 자신을 loopback 인터페이스의 분신처럼 줌으로써 그러한 딜레마를 해결한다. vlite의 경우, dummy 디바이스에 191.72.1.65의 주소를 주고, 그것을 가리키는 호스트 루트를 추가하면 된다. 그러면, 191.72.1.65를 향한 모든 데이터그램은 로컬에 전해진다. 적절한 사용법은,
# ifconfig dummy vlite
# route add vlite
ifconfig에는 위어서 기술한 것 보다 훨씬 많은 파라미터가 있다. 보통 사용법은 다음과 같다.
ifconfig interface [[-net|-host] address [parameter]]
interface는 인터페이스 명칭이고, address는 인터페이스에 지정된 IP 주소이다. 이것은 dotted quad notation 형의 IP 주소이거나, /etc/hosts와 /etc/networks에서 ifconfig이 찾아낼 수 있는 네임이다. -net과 -host 옵션은 ifconfig이 그 주소를 네트웍 번호, 혹은 호스트 주소로 다루도록 강제한다.
만약, ifconfig에 인터페이스 명칭만을 주고 실행한다면, 그 인터페이스의 설정상태를 표시할 것이다. 파라미터 없이 실행될 때는 지금까지 설정한 모든 인터페이스를 당신에게 보여줄 것이며, -a 옵션을 준다면 활성화되지 않은 것들도 모두 보여준다. 이더넷 인터페이스 eth0의 용례는 다음과 같다.
# ifconfig eth0
eth0 Link encap 10Mbps Ethernet HWaddr 00:00:C0:90:B3:42
inet addr 191.72.1.2 Bcast 191.72.1.255 Mask 255.255.255.0
UP BROADCAST RUNNING MTU 1500 Metric 0
RX packets 3136 errors 217 dropped 7 overrun 26
TX packets 1752 errors 25 dropped 0 overrun 0
MTU와 Metric 필드는 인터페이스의 현재 MTU와 메트릭 값을 보여준다. 메트릭 값은 전통적으로 몇몇 운영체제 상에서 루트(route)의 비용효율을 산출하기 위해 사용되나, 리눅스에선 아직 이 값을 사용하진 않는다. 하지만 호환성을 위해 정의는 하고 있다.
RX와 TX 라인은 에러없이 수신되거나 전송되는 패킷이 얼마나 되는지, 어러는 얼마나 되는지, 저메모리의 이유로 drop되는 패킷은 얼마인지, 그리고 overrun으로 인해 유실되는 패킷은 얼마나 되는지를 보여준다. 수신자 overrun은 보통 커널이 거는 interupt보다 패킷이 더 빨리 도달할 때 일어난다. ifconfig이 출력하는 플래그 값은 커맨드 라인에서 주었던 이름과 다소 동일하다. 아래에서 이들에 관해 설명한다.
다음은 ifconfig이 인식할 수 있는 파라미터들의 목록이며, 이에 상응하는 플래그명은 괄호내에 주어진다. 옵션은 기능을 켜 놓기도 하지만, 앞에 대쉬를 붙여 쓰면 끄는 역할을 하기도 한다.
| up | 이는 인터페이스에 "up" 표시를 한다. 즉, IP 레이어에서 접근 가능하도록 한다.
이 옵션은 address가 커맨드라인에 주어졌을 때 적용된다. 이는 또한 down
옵션을 써 일시적으로 down시켜놓은 인터페이스를 재사용가능하게 하는데도 사용한다. (이 옵션은 UP RUNNING 플래그에 상응한다.) |
|
| down | 이는 인터페이스에 "down" 표시를 한다. 즉, IP 레이어에서 접근할 수 없게 만든다. 이는 어떤 IP traffic도 그 인터페이스를 통과할 수 없도록 한다. 그러나 이것이 이 인터페이스를 사용하는 모든 라우팅 엔트리를 자동적으로 지워버리진 않는다는데 주의하라. 만약, 영구적으로 이 인터페이스를 down시키려한다면, 이들 라우팅 엔트리를 지우고, 가능하다면 다른 루트를 지정해 주어야 한다. | |
| netmask mask | ||
| 이는 인터페이스가 사용하는 서브넷 매스크를 지정한다. mask는 0x 뒤에 32비트의 16진수로 적거나, 10진수의 dotted quad로 주어야 한다. | ||
| pointopoint address | ||
| 이 옵션은 단 두 호스트만이 관여하는 point-to-point IP 링크에 사용된다. 이 옵션은
가령, SLIP이나 PPP 인터페이스를 설정하는데 필요하다.
(만약 point-to-point 주소가 지정되면, ifconfig은 POINTOPOINT 플래그를 표시한다.) | ||
| broadcast address | ||
| 흔히 broadcast 주소는 네트웍 번호의 호스트 파트의 bit을 1로 세팅하여 만들어 진다.
몇몇 IP implementation은 다른 체계를 사용하는데, 이 옵션은 이러한 특이환경에 맞출수 있도록 한다.
(만약 broadcast 주소가 지정되면, ifconfig은 BROADCAST 플래그를 표시한다.) | ||
| metric number | ||
| 이 옵션은 그 인터페이스용으로 생성된 라우팅 테이블 엔트리에 메트릭 값을 지정하는데 사용된다. 이러한 메트릭 값은 Routin Information Protocol (RIP)이 네트웍을 위해 라우팅 테이블을 만드는데 사용된다. ifconfig이 사용하는 기본 메트릭 값은 0이다. 만약, 당신이 RIP 데몬을 돌리지 않는다면 이 옵션은 전혀 필요가 없다. 만약, 돌리더라도 메트릭 값을 변경할 필요는 거의 없을 것이다. | ||
| mtu byte | 이것은 Maximum Transmissioin Unit, 즉 인터페이스가 한번의 트랜잭션에서 다룰수 있는 옥텟의 최대치를 설정한다. 이더넷에서의 MTU 디폴트 값은 1500이고, SLIP 인터페이스의 경우 296이다. | |
| arp | 이 옵션은 이더넷이나 패킷라디오 같은 broadcast 네트웍 특유의 것이다. 그것은 네트웍에
물려있는 호스트의 물리적인 주소를 탐지하는 ARP (Address Resolution Protocol)을 사용가능하도록 만든다.
broadcast 네트웍의 경우, 이것은 디폴트로 켜져 있다.
(만약 ARP가 꺼져있다면, ifconfig은 NOARP를 표시한다.) |
|
| -arp | 이 인터페이스 상에서 ARP의 사용을 꺼버린다. | |
| promisc | 인터페이스를 promiscuous (난잡한) 모드로 돌린다. broadcast 네트웍 상에서, 이것은 인터페이스가 모든 패킷을,
비록 그것이 다른 호스트로 가는 것일지라도, 전부 수신하게 한다. 이는 패킷 필터 같은 것을 써서
네트웍 traffic을 분석하도록 하며, Ethernet snooping이라고도 불린다. 보통, 해결하기 힘든 문제를 날려버리는데 좋은 기법이다.
반면에, 이것은 attacker들이 당신의 네트웍 traffic에서 패스워드를 걸러내어 추악한 짓을 하는데 쓰일 수도 있다. 이러한 방식의 공격을 방어하려면, 누구도 당신의 이더넷 내에 그들의 컴퓨터를 연결하지 못하게 해야한다. 또다른 선택은 Kerberos나 SRA login suite와 같은, 보안 인증 (secure authentication) 프로토콜을 사용하는 것이다. (이 옵션은 PROMISC 플래그에 상응한다.) | |
| -promisc | promisc 모드를 끈다. | |
| allmulti | multicast 주소는, 동일한 서브넷에 있을 필요가 없는 호스트의 그룹에 대한 일종의 broadcast이다.
multicast 주소는 커널에서 아직 지원되지 않는다.
(이 옵션은 ALLMULTI 플래그와 동일하다.) | |
| -allmulti | multicast 주소를 끈다. | |
다음으로, 당신의 네트웍의 설정과 동작을 점검하는 유용한 툴에 시선을 돌려보자. 그것은 netstat이라 불리며, 사실상 몇가지 툴의 모음을 뭉떵그려 놓은 것이다. 다음의 절에서 그것의 기능을 각각 논해보고자 한다.
5.9.1 Displying the Routing Table
-r 플래그를 주고 netstat을 실행시킨다면, 그것은 route로 하였던 것같은 방법으로 커널 라우팅 테이블을 표시한다. vstout상에서 그것이 내놓는 결과는 다음과 같다.
# netstat -nr
Kernel routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
127.0.0.1 * 255.255.255.255 UH 1 0 50 lo
191.72.1.0 * 255.255.255.0 U 1 0 478 eth0
191.72.2.0 * 255.255.255.0 UGN 1 0 250 eth0
-n 옵션은 netstat이 심볼릭 호스트나 네트웍네임 대신 dotted quad IP 번호로 주소를 찍어내게 만든다. 이는 네트웍을 통해 (즉, DNS나 NIS서버에) 주소를 검색하는 것을 피하고자 할 때 특히 유용하다.
netstat이 출력한 것에서 두번째 컬럼은 라우팅 엔트리가 가리키는 게이트웨이를 보여준다. 세번째 컬럼은 그 루트의 "generality"를 보여준다. 어울리는 루트를 찾고자 IP 주소를 주었을 때, 커널은 그것을 루트의 타겟과 비교하기에 앞서, 모든 라우팅 테이블에 대해 주소와 genmask의 bitwise AND를 수행한다.
네번째 컬럼은 루트에 관한 여려가지 플래그를 표시한다.
| G | 이 루트는 게이트웨이를 사용한다. |
|---|---|
| U | 사용되는 인터페이스가 up 상태이다. |
| H | 단지 싱글 호스트만이, 그 루트를 통해 도달가능하다. 예를 들어 이는 loopback 엔트리 127.0.0.1의 경우라 하겠다. |
| D | ICMP redirect 메세지에 의해 생성된 테이블 엔트리에 부여된다.(section 2.5를 보라 |
| M | ICMP redirect 메시지에의해 수정된 테이블 엔트리에 설정된다. |
netstat의 결과물에서 Ref 컬럼은 이 루트의 참조 개수를 보여준다. 즉, 얼마나 많은 다른 루트가(즉, 게이트웨이를 통해) 이 루트의 존재여부에 의존하는가 이다. 마지막 두 컬럼은 이 라우팅 엔트리가 몇번이나 사용되었는지, 그리고 전송을 위해 데이터 그램이 통과하는 인터페이스를 보여준다.
5.9.2 Displaying Interface Statistics
-i 플래그를 주면, netstat은 현재 설정된 네트웍 인터페이스의 통계를 표시한다. 만약 추가적으로 -a옵션을 더 주면, 현재 설정된 것 뿐아니라 커널상에 존재하는 모든 인터페이스를 출력한다. vstout 상에서, netstat의 출력물은 다음과 같다.
$ netstat -i Kernel Interface table Iface Mtu Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags lo 0 0 3185 0 0 0 3185 0 0 0 BLRU eth0 1500 0 972633 17 20 120 628711 217 0 0 BRU
MTU와 Met 필드는 인터페이스의 현재 MTU와 메트릭 값을 보여준다. RX, TX 컬럼은 얼마나 많은 패킷이 에러없이(RX-OK/TX-OK), 또는 파손되어(RX-ERR/TX-ERR) 수신 또는 전송되는지, 또한 얼마나 많이 유실되는지(RX-DRP/TX-DRP), 그리고 얼마나 많이 overrun으로 인해 유실되는지(RX-OVR/TX-OVR)를 보여준다.
마지막 컬럼은 이 인터페이스에 설정된 플래그를 보여준다. 이것들은 ifconfig으로 인터페이스 설정을 표시할 때의 긴 플래그 명을 한 글자로 나타낸 것이다.
| B | broadcast 주소가 지정되었다. |
|---|---|
| L | 이 인터페이스는 loopback 디바이스이다. |
| M | trailer가 기피된다. |
| O | 이 인터페이스를 위한 ARP가 껴져있다. |
| P | 이것은 point-to-point 커넥션이다. |
| R | 인터페이스가 동작중이다. |
| U | 인터페이스가 up 상태이다. |
netstat은 active 또는 passive 소켓을 표시하기 위한 옵션 세트를 지원한다. -f,-u,-w, 그리고 -x 옵션은 active TCP, UDP, RAW, 또는 UNIX 소켓 커넥션을 보여준다. -a 플래그를 추가로 주면, 커넥션을 기다리는 (listening) 소켓도 표시해준다. 이는 현재 당신의 시스템 상에 돌아가고있는 모든 서버의 리스트을 보여준다.
vlager에서 netstat -ta를 실행시킨 결과.
$ netstat -ta
Active Internet connections
Proto Recv-Q Send-Q Local Address Foreign Address (State)
tcp 0 0 *:domain *:* LISTEN
tcp 0 0 *:time *:* LISTEN
tcp 0 0 *:smtp *:* LISTEN
tcp 0 0 vlager:smtp vbardolino:1040 ESTABLISHED
tcp 0 0 *:telnet *:* LISTEN
tcp 0 0 localhost:1046 vbardolino:telnet ESTABLISHED
tcp 0 0 *:chargen *:* LISTEN
tcp 0 0 *:daytime *:* LISTEN
tcp 0 0 *:discard *:* LISTEN
tcp 0 0 *:echo *:* LISTEN
tcp 0 0 *:shell *:* LISTEN
tcp 0 0 *:login *:* LISTEN
이는 대부분의 서버가 단순히 들어올 커넥션을 listen한다는 것을 보여준다.
그러나 4번째줄은 vstout에서 오는 SMTP 커넥션을 보여주고, 6번째 줄은
vbardolino으로 가는 telnet 커넥션이 있다는 것을 말해준다.
-a 플래그만을 사용하면 모든 소켓이 표시될 것이다.
이따금씩, 가령 중복된 인터넷 주소로인하여 네트웍이 일시적으로 중지하는 문제가 유발된다고 추정하는 경우, 커널의 ARP 테이블을 들여다 보거나 대체하는 것이 유용할 때가 있다. arp 툴은 이러한 목적으로 만들어 졌으며, 그것의 커맨드라인 옵션은,
arp [-v] [-t hwtype] -a [hostname]
arp [-v] [-t hwtype] -a hostname hwaddr
arp [-v] -d hostname [hostname...]
모든 hostname인자는 심볼릭 호스트네임이거나 dotted quad notation으로 표현된
IP 주소여야 한다.
첫번째 실행문은 지정된 IP 주소나 호스트, 또는 hostname을 주지 않으면 알고 있는 모든 호스트의 ARP 엔트리를 표시한다. 예를들어 vlager상에서 arp를 실행시키면,
# arp -a
IP address HW type HW address
191.72.1.3 10Mbps Ethernet 00:00:C0:5A:42:C1
191.72.1.2 10Mbps Ethernet 00:00:C0:90:B3:42
191.72.2.4 10Mbps Ethernet 00:00:C0:04:69:AA
이는 vlager,vstout 그리고 vale의 이더넷 주소를 보여준다.
-t 옵션을 써서 특정 하드웨어만 표시되게 할 수도 있다. 이는 각기 ether, ax25 또는 100Mbps 이더넷을 가리키는 pronet, AMPR AX.25, 그리고 IEEE 802.5 tocken ring 장비일 수도 있다.
-s 옵션은 hostname의 이더넷 주소를 영구적으로 ARP 테이블에 추가하는데 사용된다. hwaddr 인자는 하드웨어 주소를 지정하는 것이고, 이는 콜론으로 나누어지는 6개의 16진 바이트인 이더넷 주소라고 디폴트로 가정된다. 물론 당신은 -t 옵션으로 다른 하드웨어 타입의 하드웨어 주소를 지정할 수도 있다.
한가지 문제점은, 어떠한 이유에서, 예를들면 그것의 ARP 드라이버에 버그가 많거나 자신을 그 호스트로 잘못 인식하는 또다른 호스트가 존재하는 경우, 원격 호스트로의 쿼리가 fail할 때 ARP 테이블에 수동으로 IP 주소를 추가해야하는 경우가 있다는 것이다. ARP 테이블내의 hard-wiring IP 주소는 역시나 당신의 이더넷상의 호스트가 다른 것인양 행세하는 것을 막을 수 있다.
arp에 -d 스위치를 주면 주어진 호스트와 연관된 모든 ARP 엔트리를 지운다. 이는 인터페이스가 쿼리한 IP 주소의 이더넷 주소를 얻기위해 재시도하도록 강제하는데 사용될 수 있는데, 이는 잘못 설정된 시스템이 틀린 ARP 정보를 broadcast 했을 때 유용하다. (물론, 그 전에 그 호스트를 재설정 하는 것은 당연한 일이다.)
-s 옵션은 역시나 proxy ARP를 실행하는데 사용할 수 있다. 이는 gate와 fnord라는 호스트가 있다고 가정할 때, 두 주소가 모두 gate를 가리키도록 함으로써 gate가 fnore의 게이트웨이 구실을 하게하는 특수한 기법이다. 그것은 gate 자신의 이더넷 인터페이스를 가리키고있는 fnord에대한 ARP 엔트리를 사용함으로써 그렇게 할 수 있다. 이제 한 호스트가 fnord를 찾는 ARP query를 보낼때, gate는 자신의 이더넷 주소가 포함된 reply를 리턴할 것이다. 그러면 쿼리한 호스트는 이제 gate로 모든 데이터그램을 보낼 것이며, gate는 fnord로 그것을 포워드한다.
DOS 머신에서, 라우팅을 잘 이해하지 못하는 TCP implementation으로 fnord에 억세스하고자 한다고할 때, 이러한 류의 왜곡이 필요할 수도 있다. proxy ARP를 사용할 때, fnord가 로컬 서브넷 상에 있으므로 게이트웨이를 통하여 라우트하는 방법을 몰라도 되는 것처럼 왜곡된다.
또한, proxy ARP는 당신의 호스트중 하나가, 이를테면 다이얼업 링크를 통한 일시적인 게이트웨이로 동작할 때 응용하면 매우 유용하다. 지난번 예제에서, 우리는 이미 PLIP링크를 통해 가끔씩 vlager 와 연결된 랩탑 vlite를 본 적이 있다. 물론, 이는 proxy ARP를 제공하고자 하는 호스트가 당신의 게이트웨이와 같은 IP 서브넷에 있다는 가정하에서이다. 이를테면 vstout은 Brewery 서브넷 (191.72.1.0)상의 어떤 호스트의 proxy ARP가 될 수는 있지만, Winery 서브넷 (191.72.2.0)상의 호스트엔 그럴 수 없다는 것이다.
fnord를 위한 proxy ARP를 제공하는 적절한 실행문은 다음과 같다. 물론 이더넷 주소는 gate의 것이다.
# arp -s fnord 00:00:c0:a1:42:e0 pub
proxy ARP 엔트리는 다시 다음과 같이해서 제거될 수 있다.
# arp -d fnord
리눅스 네트워킹은 현재 개발중이다.커널 레이어의 주된 변화는, 런타임에 네트웍 디바이스를 설정할 수 있도록 하는 아주 유연성있는 설정 체계를 가져다 줄 것이다. 예를들어, ifconfig 커맨드엔 IRQ라인과 DMA 채널을 설정하는 인자가 추가될 것이다.
가까운 시기에 변화될 점은 특정 루트에 Maximum Transmission Unit을 지정하는 route 커맨드에 mtu 플래그의 추가이다. 이러한 route-specific MTU는 인터페이스에 지정된 MTU를 오버라이드한다. 보통 이 옵션은 목적지 호스트와의 링크에 아주 낮은 MTU를 필요로하는 게이트웨이를 경유하는 루트에 사용된다. 일례로, vlager에 SLIP링크를 통해 연결된 wanderer라는 호스트가 있다고 가정해보자. vstout에서 wanderer로 데이터를 보낼 때 wanderer의 네트워킹 레이어는, 패킷이 이더넷을 통해 보내지므로, 1500바이트에 이르는 패킷을 사용한다. 반면에, SLIP 링크는 296의 MTU를 사용하여 작동하므로, vlager의 네트웍 레이어는 IP 패킷을 296 바이트로 더 잘게 나누어야 할 것이다. 그 대신에, 만약 당신이 vstout상의 루트가 처음부터 296에 맞는 MTU를 사용하도록 설정했다면, 상대적으로 번거로운 분할작업을 피할 수 있다.
# route add wanderer gw vlager mtu 296
mtu 옵션은 역시나 'Subnet Are Local' Policy (SNARL)의 효과를 선택적으로 꺼둘 수 있게 한다.
이 policy는 커널 설정 옵션이며 3장에서 기술한 바 있다.
1. Introduction to Networking
2. Issues of TCP/IP Networking
3. Configuring the Networking Hardware
4. Setting up the Serial Hardware
5. Configuring TCP/IP Networking
6. Name Service and Resolver Configuration
7. Serial Line IP
8. The Point-to-Point Protocol
9. Various Network Applications
10. The Network Information System
11. The Network File System
12. Managing Taylor UUCP
13. Electronic Mail
14. Getting smail Up and Running
15. Sendmail+IDA
16. Netnews
17. C News
18. A Description of NNTP
19. Newsreader Configuration
A. A Null Printer Cable for PLIP
B. Sample smail Configuration Files
C. The GNU General Public License