Linux tcp wrapper, resolv.conf 와 telnet, ftp간의 관계
페이지 정보
본문
Linux를 이용하는 이용자들이 이런 이야기를 할 때가 있습니다.
"이상하게 telnet 이나 ftp를 이용할 때 login prompt가 나올 때까지 걸리는 시간이 매우 길다. 30초에서 60초 가량.
그런데, login 후부터 느리지는 않다. web 접속 및 전송속도는 양호하다".
본인도 2000년 5월에 이러한 문의를 접하고 문제점이 무엇일까 원인을 찾아보려고 노력을 했었습니다.
그리고, 결국 원인을 찾아 대처를 했었습니다.
그런데 관련 문서를 만들지 않고 있었는데 오늘 다시 동일한 문의가 있어서 이제는 미루지 말고 만들때가 되었구나라고 판단이 되어 이 글을 씁니다.
2. 힌트
위 문제의 원인은 tcp wrapper, resolv.conf, 그리고 국내 몇몇 ISP들이 DNS 서버를 올바르게 운영하지 못하는 것들이 복합되어서 나타나는 것입니다.
그것에 대해서는 다시 언급하겠습니다.
만약 제기된 문제점을 해결하려면 tcp wrapper를 이용하지 않거나, resolv.conf를 교묘하게 처리하거나, 아니면 국내 몇몇 ISP들이 DNS 서버를 올바르게 운영해주면 됩니다.
그러나, 국내 몇몇 ISP들이 DNS 서버를 올바르게 운영해 주길 바라는 것은 (지난 몇년간의 경험을 바탕으로 판단하건데) Non-sense입니다.
따라서 서버를 운영하는 자신이 tcp wrapper와 resolv.conf를 조작해야만 합니다.
3. NT, Windows 2000 서버는 tcp wrapper를 이용하지 않으므로 관계없음.
tcp wrapper를 이용하는 서버만 해당.
* 국내에서 많이 이용하는 Redhat Linux를 기준으로 설명하겠습니다.
Redhat Linux를 기본으로 설치하면 telnet, ftp, pop3 등은 tcp wrapper (/usr/sbin/tcpd)의 영향을 받게 됩니다.
/etc/inetd.conf를 뒤져보면 아래와 같은 것을 볼 수 있습니다.
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d
만약 tcpd의 영향을 받지 않으려면 다음과 같이 수정을 하면 됩니다.
ftp stream tcp nowait root /usr/sbin/in.ftpd
telnet stream tcp nowait root /usr/sbin/in.telnetd
pop-3 stream tcp nowait root /usr/sbin/ipop3d
그러나, tcpd를 삭제해 버리면 접근제한(access control)을 할 수 없게 되는 단점이 있으므로 권장하고 싶은 사항은 아닙니다.
그러므로, tcp wrapper가 어떻게 동작하는지를 이해하여 문제를 해결해 나갈 필요가 있습니다.
참고로 NT, Windows 2000 서버는 tcp wrapper를 이용하지 않으므로 여기에서 말하는 문제는 없습니다.
4. TCP wrapper의 역할
서버address 3.3.3.3
/usr/sbin/tcpd in.telnetd
/etc/resolv.conf
nameserver 127.0.0.1
PC-address 2.2.2.2
2.2.2.2에 대한 reverse zone을 갖고 있다고 지정된
DNS서버 1.1.1.1
만약 PC가 서버에 telnet으로 접근을 하게 되면 서버의 tcpd는 PC의 address 2.2.2.2에 대해서 reverse lookup을 합니다
(본인도 tcp wrapper에 대해 상세하게 모르지만 reverse lookup을 하는 것만은 확실합니다).
참고: www.inempire.com ---> 210.124.122.135 : forward lookup
210.124.122.135 ---> www.inempire.com : reverse lookup
서버안에서 발생하는 모든 DNS lookup은 /etc/resolv.conf에 지정된 nameserver로 전달됩니다. 이 예에서는 서버 자신입니다.
서버의 DNS 설정을 살펴보면 자신이 2.2.2.2에 대한 reverse lookup을 담당하는 서버가 아님을 알게 됩니다.
따라서, PC address에 대해 reverse lookup query 과정을 실시하게 됩니다.
(이 과정은 일반적인 forward lookup 과정과 100% 동일합니다). DNS cache에 어떤 정보가 남아 있는지에 따라 조금씩 다르지만 최종적으로 2.2.2.2에 대한 reverse lookup을 담당하는 DNS server까지 도달하게 됩니다.
그런데 만약 최종 DNS server 1.1.1.1이 자신은 2.2.2.2에 대한 reverse zone file을 갖고 있다고 선언되어 있지 않다면 어떻게 될까요?
그 경우 최종 DNS server 1.1.1.1은 서버 3.3.3.3 과 마찬가지로 2.2.2.2에 대한 reverse query를 하게 됩니다.
그 query는 서버 1.1.1.1로 다시 돌아오게 되므로 결국 looping이 발생하게 됩니다.
이 경우 서버 3.3.3.3은 계속 reverse query가 끝나기를 기다리고 있습니다.
그러나 무한정 계속 기다릴 수는 없어 일정시간(timeout)이 지나면 reverse lookup을 포기하게 됩니다.
(질문: 이 timeout은 tcp wrapper에서 지정된 timeout일까요?
아니면 reverse lookup의 timeout일까요?)
그리고 PC 2.2.2.2에게 login prompt를 전달하게 됩니다.
따라서, reverse lookup에 문제가 있는 경우 PC 2.2.2.2는 서버 3.3.3.3으로 부터 login prompt를 받을 때까지 30~60초가량 기다려야만 하는 것입니다.
5. 국내 몇몇 ISP들의 DNS Server 운영 문제점
가. 위 4.에서 발생된 문제는 해당 IP address를 관리하는 ISP가 자신의 DNS Server에 reverse zone을 선언해 놓지 않았기 때문입니다.
모든 PTR record를 선언해 놓는 것이 어렵기 때문에 그것까지는 필요없다고 하더라도 반드시 reverse zone은 선언해 놓아야 합니다.
나. reverse zone은 선언해 놓았더라도 reverse lookup이 자주 실패하는 상태로 DNS server를 운영하는 경우도 문제입니다.
이런 경우 어떤 때는 접속이 빠르다가 바쁜 오후 혹은 저녁에 login prompt를 전달받기까지 걸리는 시간이 들쭉날쭉하게 됩니다.
DNS server를 잘 구성해 운영해 주길 희망합니다.
6. 목마른 사람이 우물을 판다
위 5.에서의 언급한 사항을 잘하고 있는 국내 ISP는 많지 않습니다.
따라서, 내가 문제를 스스로 해결할 수 밖에 없습니다.
문제를 해결하는 방법은 크게 2가지가 있습니다. 첫번째는 tcp wrapper의 기능을 off시키는 것이고, 두번째는 reverse lookup 과정을 조작하는 것입니다.
첫번째는 access control이 필요한 경우 할 수 없으므로 두번째에 대해서 서술하겠습니다.
2가지 방법(아래 7. 과 8.)이 있습니다.
7. reverse lookup을 자기(서버 3.3.3.3)가 모두 직접 처리하게 함
서버 3.3.3.3이 자신이 모든 IP address에 대해 reverse lookup에 대한 master라고 선언하여 reverse query가 다른 서버로 전달되지 않게 하는 방법입니다.
이것의 장점은 신속하게 reverse query에 대한 reply를 받게 되므로 PC에게 빨리 login prompt를 전달해 줄 수 있습니다.
단점은 traceroute, tracert, 혹은 기타 필요에 의해서 reverse lookup이 필요한 경우 hostname을 알 수 없다는 것입니다.
방법은 간단합니다. 그러나 조금은 무식합니다. 그러나 확실합니다.
* 아래 문법이 조금 틀릴 수 있으니 주의하세요.
o named.conf에 모든 IP address에 대해 자기가 master라고 선언
zone \"1.in-addr.arpa\" {type master; file \"zone.1.in-addr.arpa\";}
zone \"2.in-addr.arpa\" {type master; file \"zone.2.in-addr.arpa\";}
zone \"3.in-addr.arpa\" {type master; file \"zone.3.in-addr.arpa\";}
......생략........
zone \"223.in-addr.arpa\" {type master; file \"zone.223.in-addr.arpa\";}
o 해당 reverse zone file을 생성해 줌
$ more zone.1.in-addr.arpa
@ IN SOA ns.haha.com root.ns.haha.com (
2 ; serial number
10800 ; refresh
3600 ; retry
86400 ; expire
21600 ) ; minimum TTL
@ NS ns.haha.com.
@ NS ns2.haha.com.
1.1.1 PTR dummy.haha.com.
$ ln -s zone.1.in-addr.arpa zone.2.in-addr.arpa
$ ln -s zone.1.in-addr.arpa zone.3.in-addr.arpa
$ ln -s zone.1.in-addr.arpa zone.4.in-addr.arpa
....... 생략 ......
$ ln -s zone.1.in-addr.arpa zone.223.in-addr.arpa
* PTR record는 1개 밖에 선언하지 않았습니다.
아무 의미없는 것입니다. 마음대로 하세요.
8. 위 가.의 서버를 /etc/resolv.conf에 등록하기만 하면 됨
$more resolv.conf
nameserver 3.3.3.3
출처 : http://blog.naver.com/seek7282/20003158555
"이상하게 telnet 이나 ftp를 이용할 때 login prompt가 나올 때까지 걸리는 시간이 매우 길다. 30초에서 60초 가량.
그런데, login 후부터 느리지는 않다. web 접속 및 전송속도는 양호하다".
본인도 2000년 5월에 이러한 문의를 접하고 문제점이 무엇일까 원인을 찾아보려고 노력을 했었습니다.
그리고, 결국 원인을 찾아 대처를 했었습니다.
그런데 관련 문서를 만들지 않고 있었는데 오늘 다시 동일한 문의가 있어서 이제는 미루지 말고 만들때가 되었구나라고 판단이 되어 이 글을 씁니다.
2. 힌트
위 문제의 원인은 tcp wrapper, resolv.conf, 그리고 국내 몇몇 ISP들이 DNS 서버를 올바르게 운영하지 못하는 것들이 복합되어서 나타나는 것입니다.
그것에 대해서는 다시 언급하겠습니다.
만약 제기된 문제점을 해결하려면 tcp wrapper를 이용하지 않거나, resolv.conf를 교묘하게 처리하거나, 아니면 국내 몇몇 ISP들이 DNS 서버를 올바르게 운영해주면 됩니다.
그러나, 국내 몇몇 ISP들이 DNS 서버를 올바르게 운영해 주길 바라는 것은 (지난 몇년간의 경험을 바탕으로 판단하건데) Non-sense입니다.
따라서 서버를 운영하는 자신이 tcp wrapper와 resolv.conf를 조작해야만 합니다.
3. NT, Windows 2000 서버는 tcp wrapper를 이용하지 않으므로 관계없음.
tcp wrapper를 이용하는 서버만 해당.
* 국내에서 많이 이용하는 Redhat Linux를 기준으로 설명하겠습니다.
Redhat Linux를 기본으로 설치하면 telnet, ftp, pop3 등은 tcp wrapper (/usr/sbin/tcpd)의 영향을 받게 됩니다.
/etc/inetd.conf를 뒤져보면 아래와 같은 것을 볼 수 있습니다.
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d
만약 tcpd의 영향을 받지 않으려면 다음과 같이 수정을 하면 됩니다.
ftp stream tcp nowait root /usr/sbin/in.ftpd
telnet stream tcp nowait root /usr/sbin/in.telnetd
pop-3 stream tcp nowait root /usr/sbin/ipop3d
그러나, tcpd를 삭제해 버리면 접근제한(access control)을 할 수 없게 되는 단점이 있으므로 권장하고 싶은 사항은 아닙니다.
그러므로, tcp wrapper가 어떻게 동작하는지를 이해하여 문제를 해결해 나갈 필요가 있습니다.
참고로 NT, Windows 2000 서버는 tcp wrapper를 이용하지 않으므로 여기에서 말하는 문제는 없습니다.
4. TCP wrapper의 역할
서버address 3.3.3.3
/usr/sbin/tcpd in.telnetd
/etc/resolv.conf
nameserver 127.0.0.1
PC-address 2.2.2.2
2.2.2.2에 대한 reverse zone을 갖고 있다고 지정된
DNS서버 1.1.1.1
만약 PC가 서버에 telnet으로 접근을 하게 되면 서버의 tcpd는 PC의 address 2.2.2.2에 대해서 reverse lookup을 합니다
(본인도 tcp wrapper에 대해 상세하게 모르지만 reverse lookup을 하는 것만은 확실합니다).
참고: www.inempire.com ---> 210.124.122.135 : forward lookup
210.124.122.135 ---> www.inempire.com : reverse lookup
서버안에서 발생하는 모든 DNS lookup은 /etc/resolv.conf에 지정된 nameserver로 전달됩니다. 이 예에서는 서버 자신입니다.
서버의 DNS 설정을 살펴보면 자신이 2.2.2.2에 대한 reverse lookup을 담당하는 서버가 아님을 알게 됩니다.
따라서, PC address에 대해 reverse lookup query 과정을 실시하게 됩니다.
(이 과정은 일반적인 forward lookup 과정과 100% 동일합니다). DNS cache에 어떤 정보가 남아 있는지에 따라 조금씩 다르지만 최종적으로 2.2.2.2에 대한 reverse lookup을 담당하는 DNS server까지 도달하게 됩니다.
그런데 만약 최종 DNS server 1.1.1.1이 자신은 2.2.2.2에 대한 reverse zone file을 갖고 있다고 선언되어 있지 않다면 어떻게 될까요?
그 경우 최종 DNS server 1.1.1.1은 서버 3.3.3.3 과 마찬가지로 2.2.2.2에 대한 reverse query를 하게 됩니다.
그 query는 서버 1.1.1.1로 다시 돌아오게 되므로 결국 looping이 발생하게 됩니다.
이 경우 서버 3.3.3.3은 계속 reverse query가 끝나기를 기다리고 있습니다.
그러나 무한정 계속 기다릴 수는 없어 일정시간(timeout)이 지나면 reverse lookup을 포기하게 됩니다.
(질문: 이 timeout은 tcp wrapper에서 지정된 timeout일까요?
아니면 reverse lookup의 timeout일까요?)
그리고 PC 2.2.2.2에게 login prompt를 전달하게 됩니다.
따라서, reverse lookup에 문제가 있는 경우 PC 2.2.2.2는 서버 3.3.3.3으로 부터 login prompt를 받을 때까지 30~60초가량 기다려야만 하는 것입니다.
5. 국내 몇몇 ISP들의 DNS Server 운영 문제점
가. 위 4.에서 발생된 문제는 해당 IP address를 관리하는 ISP가 자신의 DNS Server에 reverse zone을 선언해 놓지 않았기 때문입니다.
모든 PTR record를 선언해 놓는 것이 어렵기 때문에 그것까지는 필요없다고 하더라도 반드시 reverse zone은 선언해 놓아야 합니다.
나. reverse zone은 선언해 놓았더라도 reverse lookup이 자주 실패하는 상태로 DNS server를 운영하는 경우도 문제입니다.
이런 경우 어떤 때는 접속이 빠르다가 바쁜 오후 혹은 저녁에 login prompt를 전달받기까지 걸리는 시간이 들쭉날쭉하게 됩니다.
DNS server를 잘 구성해 운영해 주길 희망합니다.
6. 목마른 사람이 우물을 판다
위 5.에서의 언급한 사항을 잘하고 있는 국내 ISP는 많지 않습니다.
따라서, 내가 문제를 스스로 해결할 수 밖에 없습니다.
문제를 해결하는 방법은 크게 2가지가 있습니다. 첫번째는 tcp wrapper의 기능을 off시키는 것이고, 두번째는 reverse lookup 과정을 조작하는 것입니다.
첫번째는 access control이 필요한 경우 할 수 없으므로 두번째에 대해서 서술하겠습니다.
2가지 방법(아래 7. 과 8.)이 있습니다.
7. reverse lookup을 자기(서버 3.3.3.3)가 모두 직접 처리하게 함
서버 3.3.3.3이 자신이 모든 IP address에 대해 reverse lookup에 대한 master라고 선언하여 reverse query가 다른 서버로 전달되지 않게 하는 방법입니다.
이것의 장점은 신속하게 reverse query에 대한 reply를 받게 되므로 PC에게 빨리 login prompt를 전달해 줄 수 있습니다.
단점은 traceroute, tracert, 혹은 기타 필요에 의해서 reverse lookup이 필요한 경우 hostname을 알 수 없다는 것입니다.
방법은 간단합니다. 그러나 조금은 무식합니다. 그러나 확실합니다.
* 아래 문법이 조금 틀릴 수 있으니 주의하세요.
o named.conf에 모든 IP address에 대해 자기가 master라고 선언
zone \"1.in-addr.arpa\" {type master; file \"zone.1.in-addr.arpa\";}
zone \"2.in-addr.arpa\" {type master; file \"zone.2.in-addr.arpa\";}
zone \"3.in-addr.arpa\" {type master; file \"zone.3.in-addr.arpa\";}
......생략........
zone \"223.in-addr.arpa\" {type master; file \"zone.223.in-addr.arpa\";}
o 해당 reverse zone file을 생성해 줌
$ more zone.1.in-addr.arpa
@ IN SOA ns.haha.com root.ns.haha.com (
2 ; serial number
10800 ; refresh
3600 ; retry
86400 ; expire
21600 ) ; minimum TTL
@ NS ns.haha.com.
@ NS ns2.haha.com.
1.1.1 PTR dummy.haha.com.
$ ln -s zone.1.in-addr.arpa zone.2.in-addr.arpa
$ ln -s zone.1.in-addr.arpa zone.3.in-addr.arpa
$ ln -s zone.1.in-addr.arpa zone.4.in-addr.arpa
....... 생략 ......
$ ln -s zone.1.in-addr.arpa zone.223.in-addr.arpa
* PTR record는 1개 밖에 선언하지 않았습니다.
아무 의미없는 것입니다. 마음대로 하세요.
8. 위 가.의 서버를 /etc/resolv.conf에 등록하기만 하면 됨
$more resolv.conf
nameserver 3.3.3.3
출처 : http://blog.naver.com/seek7282/20003158555
댓글목록
등록된 댓글이 없습니다.