프락시 서버는 부가의 software를 필요로 한다. 그것들을 다음의 주소에서 얻 을 수 있다:
sunsite.unc.edu/pub/linux/system/network/misc/socks-linux-src.tgz 이 디렉토리에는 "socks-conf"라 불리는 예제 config 파일도 들어있다. 이 파일을 당신 머신의 디렉토리에서 압축을 풀고, make하는 방법에 대한 지시를 따르라. 내가 그것을 make 할 때는 몇가지문제가 있었다. Makefile이 올바른지를 확인하 라. 어떤 것은 바르고, 어떤 것은 그렇지 않다.
프락시 서버가 /etc/inetd.conf에 추가되야 한다는 중요한 사실을 잊지말라. 당 신은 다음의 라인을 추가해야한다: socks stream tcp nowait nobody /usr/local/etc/sockd sockd
socks 프로그램에는 2개의 분리된 설정 파일이 필요하다. 하나는 접근가 허용 되었음을 알리기 위한것이며, 다른 것은 요청된 것을 적당한 프락시 서버로 routing하기 위한 것이다. 접근 파일은 서버에 놓여 있어야 한다. routing 파일 은 모든 유닉스 머신에 놓여있어야 한다. 도스와 매킨토시는 짐작컨대, 자신의 routing이 있을 것이다.
socks 4.2 beta에서 접근 파일은 "sockd.conf"로 불린다. 그것은 permit과 deny 두 개의 라인을 포함해야 한다. 각각의 라인은 세 개의 엔트리를 가질 것이다:
+ The Identifier (permit/deny) + The IP 주소 + The 주소 modifierIP 주소는 전형적인 dot 표기법으로 이루어진 4바이트의 주소를 지닌다. 즉, 192.168.2.0 따위의 것이다. 주소 modifier 또한 4바이트의 전형적인 IP 주소이다. 그것은 마치 netmask처럼 동작한다. 이 숫자가 32bit이 되도록 상상해보라(1s 또는 0s). 그 bit이 1이면, 그것이 체크하는 응답 bit이 IP 주소so의 응답 bit와 들어맞아야 한다.
예를 들어, line이 이렇다면: permit 192.168.2.23 255.255.255.255 그것은 예를들어 192.168.2.3과 같이 192.168.2.23내의 모든 bit와 들어맞는 IP
주소만을 허용할 것이다. 이 line의 경우: permit 192.168.2.0 255.255.255.0 192.168.2.255를 통해 그룹 192.168.2.0내의 모든 번호들을 허용할 것이다. 당신은 이 라인을 가져서는 안된다: permit 192.168.2.0 0.0.0.0 왜냐하면 이것은 아무 주소나 상관없이 허용할 것이기 때문이다.
그러므로, 우선 원하는 모든 주소를 허용하고, 그런 뒤 나머지를 불허하라. domain 192.168.2.xxx 내의 모든사람을 허용하고 싶다면: permit 192.168.2.0 255.255.255.0 deny 0.0.0.0 0.0.0.0 이렇게 하면 잘 된다. deny line의 첫 번째 "0.0.0.0" 을 주목해라. "0.0.0.0"의 modifier를 가지면, IP 주소는 문제가 되지않는다. 입력하기 쉬우므로 모두 '0' 을 치는 것이 표준이다.
각각에 하나이상의 엔트리도 허용된다. 특정한 사용자만 접근을 허가 또는 불허 할수도 있다. 이것은 ident 인증을 통해서 이루어진다. 모든 시스템이 idnet를 지원하는 것은 아니므로, 트럼펫 윈삭을 포함하여, 그것을 여기서 상세히 이야기 하지는 않겠다. socks에 딸려있는 문서에 이 주제에 대해 자세히 나와있다.
routing 파일은 기분나쁘게도 "socks.conf"라고 불린다. 내가 "기분이 나쁘다"라고 이야기 한 것은 이것이 접근 파일의 이름과 매우 비슷하여 이 두 파일을 혼동하 기 쉽기 때문이다.
routing 파일은 socks 클라이언트에게 언제 socks를 사용할것인지, 또 언제 사용하지 않을 것인지를 알려주기위해 존재한다. 예를들어, 우리의 네트웍 내에서는, 192.168.2.3은 방화벽인 192.168.2.1과 통신하기위해 socks를 사용할 필요는 없 다. 그것은 이서네트을 경유한 직접 연결을 가지고 있기 때문이다. 그것 은 127.0.0.1의 loopback를 자동으로 정의한다. 물론 자신에게 이야기하기 위해서 도 socks 가 필요없다. 여기에는 3개의 엔트리가 있다.
+ deny + direct + sockddeny는 socks에게 언제 요청을 거부할지를 알려준다. 이 엔트리 는 sockd.conf에 서와 같이 indentifier, 주소, modifier의 세 field 를 지닌다. 일반적으로, 이것들도 sockd.conf, 접근 파일에 의해 다뤄지므로, modifier field 는 0.0.0.0으로 설정된다. 만약 어느곳으로 부터의 호출도 불가능하게 하고싶다 면, 그것을 여기서 할 수 있다. direct 엔트리는 어느 주소가 socks 를 사용하 지 않을것인가를 알려준다. 이것들은 모두 프락시 서버 없이 접근 가능한 주소들이다. 이것도 identifier, 주소, modifier의 세 field 를 지닌다. 우리의 예를 들어보면 이렇다.
direct 192.168.2.0 255.255.255.0 Thus going direct for any on our 보호받는 네트웍. sockd 엔트리는 컴퓨터에게 어느것이 socks 서버 데몬을 가지고 있는지 알 려준다. 명령의 형식은 이렇다: sockd @=<서버list> <IP 주소> <modifier> @= 엔트리를 주목해라. 이것은 당신이 프락시 서버 list의 주소를 설정하도 록 해준다. 그러나 잘 되지 않을 경우, 지나치게 많은 부담을 주거나 쓸데없이 남아돌게 할 수 있 다.
IP 주소와 modifier field는 다른 예에서와 마찬가지로 작동한다. 이것으로 어 느 주소가 어느 장소로 가도록 명시해준다.
방화벽의 뒤에서 도메인 네임서버를 설정하는 것은 상대적으로 쉬운일이 다. 단순히 방화벽 머신에서 dns 만 설정해주면 된다. 그리고나서 방화벽 뒤의 각각의 머신이 이 dns를 사용하도록 설정한다.
당신의 어플리케이션이 프락시 서버와 동작하게 하기위해선, 그것들이 "sockified"될 필요가 있다. 당신은 직접 연결하기 위한, 프락시 서버 를 경유한 통신을 위한, 서로다른 두 개의 telnet이 필요할 것이다.
socks 에는 어떻게 프로그램을 sockify 하는지에 대한 지시가 딸려온다. 어디론 가 직접 가기위해서 sockify된 버전을 사용한다면, socks는 자동적으로 direct version으로 전환해 줄 것이다. 이 때문에, 우리는 보호받는 네트웍 상의 모든 프로그램의 이름을 바꾸어주고 sokify된 프로그램들로 대체하길 원한다. "finger" 는 finger.orig"가 되고, "telnet"은 "telnet.orig"이 될 것이다. 당신은 이들 각각이 include/socks.h 파일을 경유한다는 것을 알려야한다. 어떤 프 로그램은 routing과 sockifying 자체를 다루기도 한다. 넷스케이프이 그런 프로그램 중 하나이다. 당신의 프락시하의 socks field에 있는 서버의 주소를 입력함 으로써, 넷스케이프 상에서 프락시 서버을 사용할 수있다. 각각의 응용 프로그램은 그것이 프락시 서버를 어떻게 다루느냐에 상관없이, 최소한 약간의 간섭이 필 요하다.
trumpet winsock은 프락시 서버의 능력을 갖춘채로 나온다. setup 메뉴에서 서버의 IP 주소와 직접 접근이 가능한 모든 컴퓨터의 주소를 입력하라. 그러면, trumpet winsock이 모든 dutgoing 패킷를 다룰 것이다.
socks 패키지는 오직 TCP 패킷와 동작하며, UDP와는 동작하지 않는다. 이 것이 socks의 유용함에 약간의 흠집을 남긴다. talk나 archie 같은 많은 유용한 프로그램들이 UDP를 이용한다. Tom Fitzgerald < fitz@wang.com>에 의해 만들 어진 UDPrelay라는 UDP 패킷을 위한 프락시 서버로 사용되기위해 설계된 패키지도 있다. 공교롭게도, 이 글을 쓰는 순간에 그것은 리눅스와 호환이 되 지 않았다.
프락시 서버는 무엇보다도 보안을 위한 장치이다. 제한된 IP 주소를 가지고 인터넷 접근를 증가시키기 위해 프락시를 사용하려면 많은 단점들이 있을 것 이다. 프락시 서버는 보호받는 네트웍 내부에서 바깥으로의 더욱 나아진 접근를 허용할 것이지만, 외부의 접근으로부터 그 내부는 완벽하게 지켜낼 것 이다. 이것은 talk나 archie 접속과 같은 어떠한 서버라든지, 내부 컴퓨터로 의 직접 메일 보내는 것이 불가능함을 의미한다. 이런 결점들은 작아보일지 모르나, 이 렇게 생각해보라:
￥ 방화벽로 보호중인 네트웍상에 작성하던 리포트를 남겨놓았다. 당신은 집 에 있으며, 그것(방화벽)을 넘어가고 싶다고 생각한다. 그러나 할 수 없다. 컴퓨터가 방화벽의 뒤쪽에 있다는 이유로 당신은 접근할 수 없다. 우선 당 신은 방화벽에 으로그인 하려고 노력할테지만, 모든 사람이 프락시 서버 접근를 가지고 있으므로, 아무도 당신을 위해 계정을 설정해 놓지 않았을 것이다.
￥ 당신의 여자친구가 다른 대학에 다닌다. 그녀에게 전자우편을 보내고 싶다. 당신은 사적으로 하고싶은 이야기가 있으며, 메일이 당신의 머신으로 직접 보내지기를 원한다. 당신은 systems administrator 완전히 믿고 있지만, 이것은 어디까지나 사적인 메일이다.
￥ UDP 패킷을 사용할수 없는 것이 프락시 서버의 가장 큰 단점이다. 곧 UDP도 지원되리라 생각한다.
FTP는 프락시 서버에 다른 문제를 일으킨다. ls 명령을 내릴 때, ftp 서버는 client 머신의 소켓을 열고 그곳을 통해 정보를 보낸다. 프락시 서버는 이것을 허용하지 않으므로, ftp는 면밀하게 동작하지 않는다. 또 프락시 서버는 느리게 동작한다. 막대한 오버헤드 때문에, 이것을 얻는 대개 의 다른 방법들은 훨씬 빠를 것이다.
기본적으로, IP 주소를 가지고 있고 보안에 대해 걱정하지 않는다면, 방화벽 과/또는 프락시 서버 를 사용하지 말아라. IP 주소를 갖지않고, 보안에 대해 걱정하지 않지만, term이나 slirp, TIA 등을 사용하여 조사를 하고싶을지 모른 다. term은