유용한 FAQ가 있다면, ambrose@writeme.com과 dranch@trinnet.net으로 보내주기 바란다. 질문을 명확하게 표시하고 적절한 답변을 달아주기 바란다. 미리 감사드린다!
여러분의 리눅스 배포본이 IP 마스커레이드를 바로 사용할 수 없다 해도 걱정하지 마십시요. 단지 이 하우투에 나온 대로 커널을 재컴파일하기만 하면 됩니다.
주의: 이 표를 완벽히 채우는데 도움을 주고자 할 때에는 ambrose@writeme.com이나 dranch@trinnet.net으로 이메일을 주십시요.
16MB RAM을 갖는 486/66으로도 1.54Mb/s T1을 100% 처리하고도 남았었다! 마스커레이드는 386SX-16s 에서 8BM RAM을 가지고서도 잘 동작한다고 알려져 있다. 그러나, 마스커레이드 항목이 500개가 넘으면 리눅스 IP 마스커레이드도 버벅이기 시작한다는 것도 알아두어야 할 것이다.
리눅스 IP 마스커레이드를 잠시나마 멈추게 할 수 있는 유일한 응용프로그램으로는, 필자가 아는 한 GameSpy뿐이다. 그 이유는 목록을 갱신할 때, 매우 짧은 시간동안 10,000개의 빠른 접속을 필요로 하기 때문이다. 이 일이 끝날 때까지는, 마스커레이드 테이블이 "꽉" 차게 된다. 자세한 사항은 FAQ의 No-Free-Ports 섹션을 살펴보기 바란다.
말하는 김에 몇가지 더:
TCP와 UDP에는 4096개의 동시 접속 한계가 있다. 이 한계는 /usr/src/linux/net/ipv4/ip_masq.h에서 값을 건드리면 수정될 수 있다 - 위쪽 한계인 32000 정도도 괜찮다. 한계치를 수정하고 싶다면 - PORT_MASQ_BEGIN 와 PORT_MASQ_END 값을 32K보다 높고 64K보다 낮은 범위로 수정하면 된다.
리눅스 IP 마스커레이딩 메일링 리스트에 참가하는 방법에는 두가지가 있습니다. 첫번째 방법은 masq-request@indyramp.com으로 메일을 보내는 것입니다. 리눅스 IP 마스커레이딩 개발자 메일링 리스트에 참가하기 위해서는, masq-dev-request@indyramp.com으로 메일을 보내십시요. 더 자세한 사항은 아래의 기사를 참조하십시요.
일단 서버가 여러분의 요청을 받으면, 여러분이 요청한 리스트에 가입시키고 여러분에게 패스워드를 보낼 겁니다. 이 패스워드를 어딘가에 저장해 놓으십시요. 옵션을 변경하거나 리스트에서 탈퇴할 때 필요합니다.
두번째 방법은 웹 브라우져를 이용해서 가입하는 겁니다. 마스커레이드 주 리스트에 가입하려면 http://www.indyramp.com/masq-list/의 형식에 맞춰서 가입하고, 마스커레이드 개발자 리스트에 가입하려면 http://www.indyramp.com/masq-dev-list/를 이용하십시요.
일단 가입되고 나면, 가입된 리스트에서 이메일을 받을 겁니다. 또 한가지 알려둘 것은 리스트에 가입하든 가입하지 않든, 두 리스트의 archive를 볼 수 있습니다. 자세한 방법은 위에 있는 두 개의 웹 URL을 참조하십시요.
마지막으로 알려둘 것은, 마스커레이드 리스트에 글을 올리기 위해서는 처음에 가입했던 계정과 주소를 이용해야 한다는 겁니다.
메일링 리스트나 메일링 리스트 archive에 관련한 문제가 발생하면, Robert Novak에게 연락하십시요.
Proxy: 프록시 서버는 다음 환경에서 사용가능: Win95, NT, Linux, Solaris, 기타.
장점: + 한개의 IP 주소 ; 저렴함
+ 더 나은 성능(웹 등)을 위해서 선택적으로 캐쉬 사용
단점: - 프록시 서버 뒤에 있는 모든 응용프로그램들이
프록시 서비스(SOCKS)를 지원해야 하고 프록시 서버를
사용하도록 설정되어야 한다
- 웹 카운터나 웹 통계 프로그램을 혼란시킨다
프록시 서버는, IP 마스커레이드와 같이, 단 한개의 공식적인 IP 주소를
사용하고, 내부 LAN에 있는 클라이언트들(웹 브라우저 등등)에게 번역자
역할을 한다. 이 프록시 서버는 내부 네트웍으로부터 오는 TELNET, FTP,
웹과 같은 접속을 한 개의 인터페이스를 통해서 받아들인다. 그리고 나서,
프록시 서버 자체에서 접속을 요청한 것처럼 바꾸어서 외부로 보낸다.
일단 원격의 인터넷 서버가 요청한 정보를 보내오면, 프록시 서버는
TCP/IP 주소를 내부의 클라이언트의 주소로 다시 변경하고 내부에서
요청했던 호스트로 보내준다. 이러한 것을 "프록시(대리인)" 서버라고
부른다.
주의 : 내부의 머신들에서 사용하는 모든 응용프로그램은
*반드시* 프록시 서버 사용을 지원해야 한다. 예를 들면,
Netscape나 몇몇 좋은 TELNET이나 FTP 클라이언트들.
프록시 서버를 지원하지 않는 클라이언트들은 동작하지
않을 것이다.
프록시 서버의 좋은 점 또 한가지는 어떤 서버들은 캐쉬 기능도 갖추고
있다는 것이다(WWW에 사용하는 Squid). 그럼, 50개의 프록시되는
호스트들이 있고, 모두 한꺼번에 Netscape를 실행한다고 하자. 그들이
디폴트로 되어 있는 홈페이지 URL로 설정되었다면, 50개의 동일한 Netcape
웹 페이지를 원격에서 받아와서 해당하는 컴퓨터로 보내주어야 한다.
캐쉬 기능이 있는 프록시 서버라면, 프록시 서버가 원격으로부터 한번만
페이지를 로드하고, 프록시 내부의 컴퓨터들은 캐쉬로부터 그 페이지를
받아볼 것이다. 이렇게 하면, 외부로의 인터넷 접속 대역폭을 절약할 수
있을 뿐 아니라, 프록시 내부의 머신들은 페이지를 읽는 것이 아주아주
많이 빠르게 느껴질 것이다.
MASQ: IP 마스커레이드는 리눅스와 Zytel Prestige128, Cisco 770, NetGear ISDN
혹은 라우터 등의 몇몇 라우터에서 사용 가능하다.
1대다
NAT
장점: + 오직 한개의 IP 주소만 필요하다 (저렴함)
+ 응용프로그램이 특별한 것을 지원할 필요가 없다
+ 네트웍 보안을 강화하기 위해서 방화벽 소프트웨어를
사용한다.
단점: - 리눅스 호스트나 특별한 ISDN 라우터를 필요로 한다
(다른 제품들도 이 기능을 가질 수 있는데도.. )
- 외부로부터 들어오는 정보들은, 내부 LAN의 컴퓨터에서
요청한 것이 아니거나, 특정 포트 포워딩 소프트웨어가
설치되어 있지 않으면 내부 LAN에 접근할 수 없다.
많은 NAT 서버들이 이러한 기능을 제공하지 않는다.
- 특별한 프로토콜들은 방화벽 전달자(redirector) 등에
의해 개별적으로 처리되어야 한다. 리눅스는 이러한
기능(FTP, IRC, 기타등등)을 완전히 지원하지만 많은
라우터들이 지원하지 않는다 (NetGear는 지원한다).
마스커레이드나 1대다(多) NAT는, 서버가 IP 주소를 전환해서, 마치 내부
머신이 아니라 마스커레이드 서버 자체가 접속을 요청한 것처럼(예를 들면
웹 접속 등) 원격 서버를 속인다는 점에서는, 프록시 서버와 유사하다.
마스커레이드와 프록시 서버의 주된 차이점은, 마스커레이드 서버는
클라이언트 머신(내부 머신)에게 어떠한 설정의 변경도 요구하지 않는다는
것이다. 단시 내부 머신들이 리눅스 호스트를 그들의 기본 게이트웨이로
사용하도록 하기만 하면 모든 것이 잘 동작할 것이다. (리얼오디오, FTP
등이 동작하기 위해서는 특정 리눅스 모듈을 설치해야 한다!)
또한, 많은 사람들이 IP 마스커레이드를 TELNET, FTP 등에 사용하면서,
*동시에* 같은 리눅스 호스트에 웹 접속을 위한 캐쉬용 프록시를 설치해서
추가적인 성능 향상을 얻기도 한다.
NAT: NAT 서버는 Windows 95/NT, Linux, Solaris, 그리고 몇몇 고급의 ISDN
라우터(Ascend 제외)에서 사용할 수 있다
장점: + 설정하기 매우 좋다
+ 특별한 응용 소프트웨어를 필요로 하지 않는다
단점: - ISP로부터 서브넷을 할당받아야 한다 (비싸다)
Network Address Translation(네트웍 주소 전환)은, 인터넷
인터페이스에, 사용 가능한 IP 주소 모음을 가지고 있는 호스트를
지칭한다. 내부 네트웍에서 인터넷 접속을 하고자 할 때, 그 호스트는
접속을 요청한 컴퓨터의 원래 내부 IP 주소에, 인터넷 인터페이스의
공식적인 IP 주소를 할당한다. 그 후에, 모든 정보 교환은 NAT의 공식적인
IP 주소에서 NAT 안쪽의 내부 주소로 전환해서 이루어진다. 이미 할당된
공식적인 NAT의 주소가 미리 정해진 얼마간의 시간 동안 사용되지 않으면,
그 공식적인 IP 주소는 다시 사용 가능한 NAT 주소 모음으로 되돌려 진다.
NAT가 갖는 주된 문제점은, 모든 공식 IP 주소들이 사용되면, 내부의
사용자들은 사용가능한 주소가 생길 때까지 인터넷에 접속을 할 수
없다는 것이다.
그렇습니다! 그들은 사용자 인터페이스나 복잡성 등에 차이가 있습니다. 그러나, 지금까지는 대부분 IPFWADM만 지원하지만 꽤 훌륭합니다. 사용 할 수 있는 도구들을 알파벳 순으로 간단히 목록으로 만들었습니다. 다른 도구들을 알고 있거나 어떤 것이 좋고 나쁘고 까다로운지 평하고 싶다면, Ambrose나 David에게 이메일을 보내주기 바랍니다.
예, ISP로부터 PPP나 DHCP/BOOTp 서버를 통해서 할당받은 동적 IP 주소와도 동작합니다. 공식적인 인터넷 IP 주소가 있기만 하면 반드시 동작할 겁니다. 물론, 정적 IP도 동작합니다. 하지만, 여러분이 강력한 IPFWADM/IPCHAINS 정책을 사용하고자 한다거나, 포트 포워더를 사용하고자 한다면, 여러분의 정책은 IP 주소가 바뀔 때마다 다시 실행되어야 합니다. 강력한 방화벽 정책과 동적 IP 주소에 관한 추가적인 도움은 TrinityOS - Section 10의 앞부분에서 찾을 수 있습니다.
예, 리눅스가 그 네트웍 인터페이스를 지원하기만 하면, 반드시 동작할 겁니다. 동적인 IP 주소를 할당받았다면, 위의 FAQ의 "IP 마스커레이드가 동적으로 할당받은 IP 주소와도 동작합니까?" 항목 아래에 있는 URL을 보십시요.
물론 가능합니다! IP 마스커레이딩은 Diald나 PPP와는 완전히 투명한 관계에 있습니다(역자주: 서로의 세부적인 내용에 얽매이지 않음). 문제가 될만한 유일한 경우는, 여러분이 동적 IP 주소와 함께 강력한 방화벽 정책을 사용할 때입니다. 자세한 사항은 위의 FAQ의 "IP 마스커레이드가 동적으로 할당받은 IP 주소와도 동작합니까?" 항목을 보십시요.
"동작하는 응용프로그램"의 목록을 계속 만드는 것은 매우 어려운 작업입니다. 하지만, 웹 브라우징(Netscape, MSIE 등), FTP(WS_FTP같은 것들), TELNET, SSH, 리얼 오디오, POP3(메일 받기 - Pine, Eudora, Outlook 등), SMTP(메일 보내기), 기타 등등의 통상적인 인터넷 응용프로그램은 대부분 지원됩니다. 마스커레이드와 함께 동작하는 클라이언트들의 좀 더 완전한 목록은 이 하우투의 Clients 섹션에서 찾을 수 있을 겁니다.
화상회의 소프트웨어와 같이, 좀더 복잡한 프로토콜이나 특별한 접속 방식을 사용하는 응용프로그램들은 특별한 도구를 같이 사용해야 합니다.
더 자세한 사항은, Linux IP masquerading Applications 페이지를 보십시요.
여러분이 어떠한 리눅스 배포본을 사용하고 있든, 이 하우투에서 설명한 IP 마스커레이드 설정 방법은 역시 유효합니다. 어떤 배포본은 설정을 쉽게 해 주는 GUI나 특별한 설정 화일을 가지고 있을 겁니다. 우리는 이 하우투를 가능하면 일반적인 상황에 모두 적용 가능하도록 작성하기 위해서 최선을 다했습니다.
IP 마스커레이드는, 기본적으로, TCP 세션과 TCP FIN, UDP 통신등의 제한시간을 15분으로 맞추어 놓습니다. 다음의 설정을(이 하우투의 /etc/rc.d/rc.firewall 정책 화일에 이미 나와 있음) 가능하면 모든 사용자들에 대해 사용할 것을 권장합니다:
IPFWADM을 사용하는 리눅스 2.0.x:
# MASQ timeouts # # 2 hrs timeout for TCP session timeouts # 10 sec timeout for traffic after the TCP/IP "FIN" packet is received # 60 sec timeout for UDP traffic (MASQ'ed ICQ users must enable a 30sec firewall timeout in ICQ itself) # /sbin/ipfwadm -M -s 7200 10 60
IPCHAINS를 사용하는 리눅스 2.2.x:
# MASQ timeouts # # 2 hrs timeout for TCP session timeouts # 10 sec timeout for traffic after the TCP/IP "FIN" packet is received # 60 sec timeout for UDP traffic (MASQ'ed ICQ users must enable a 30sec firewall timeout in ICQ itself) # /ipchains -M -S 7200 10 60
그 이유는 여러분이 동적인 IP 주소를 가지고 있고, 인터넷 연결이 처음으로 이루어질 때는, IP 마스커레이드가 IP 주소를 알 수 없기 때문에 그렇습니다. 이를 위한 해결책이 있습니다. 여러분의 /etc/rc.d/rc.firewall 정책화일에, 다음 내용을 추가하십시요:
# Dynamic IP users: # # If you get your IP address dynamically from SLIP, PPP, or DHCP, enable this following # option. This enables dynamic-ip address hacking in IP MASQ, making the life # with Diald and similar programs much easier. # echo "1" > /proc/sys/net/ipv4/ip_dynaddr
이에는, 두가지 이유를 생각해 볼 수 있습니다. 첫번째는 매우 자주 일어나는 것이고, 두번째는 매우 드문 경우입니다.
하지만 걱정할 것은 없습니다. 매우 훌륭한 보완책은 여러분의 인터넷 접속의 MTU를 1500으로 변경하는 것입니다. 그렇게 되면 어떤 사용자들은 불평하게 될 것인데, 그건 TELNET이나 게임등 몇몇 잠재능력에 민감한 프로그램들이 문제를 일으키기 때문입니다. 하지만, 피해는 단지 조금일 뿐입니다. HTTP와 FTP 속도는 더 좋아질 것입니다!
이 문제를 고치기 위해서는, 우선 여러분의 인터넷 연결의 MTU가 얼마인지 현재 얼마인지 알아야 합니다. 확인하는 방법은, "/bin/ifconfig"라고 명령하는 것입니다. 이제 여러분의 인터넷 연결에 해당하는 라인들을 살펴보고 MTU가 얼마인지 확인합니다. 이 값은 1500이어야 합니다. 보통 Ethernet(이더넷) 연결은 기본적으로 이 값으로 되어 있을 것이고, PPP는 기본적으로 576으로 되어 있을 겁니다.
이것에는 몇가지 이유가 있을 수 있습니다:
여러분이 보통 보게 될 메시지는 아마도 다음 두가지일 겁니다:
TrinityOS - Section 10 문서에서:
아래의 정책에서, 어떤 트래픽을 거절 또는 거부하는 라인들은 "-o"
옵션을 가지고 있어서 방화벽에의 접근 기록을 다음의 위치에 있는
SYSLOG 메시지 화일에 남깁니다:
Redhat: /var/log
Slackware: /var/adm
이 방화벽 로그들을 살펴보면, 다음의 것들과 같은 것을 보게 될 겁니다:
---------------------------------------------------------------------
IPFWADM:
Feb 23 07:37:01 Roadrunner kernel: IP fw-in rej eth0 TCP 12.75.147.174:1633
100.200.0.212:23 L=44 S=0x00 I=54054 F=0x0040 T=254
IPCHAINS:
Packet log: input DENY eth0 PROTO=17 12.75.147.174:1633 100.200.0.212:23
L=44 S=0x00 I=54054 F=0x0040 T=254
---------------------------------------------------------------------
이 단 한 줄에는 아주 많은 정보가 있습니다. 이 예를 분석해 보면서 여러분이
보게되는 방화벽 접근 기록을 확인해 봅시다. 이 예는 IPFWADM을 설명하고 있지만
IPCHAINS 사용자들도 바로 무언지 알 수 있을 겁니다.
--------------
- 이 방화벽 "접근"은 "Feb 23 07:37:01"에 발생했습니다.
- 이 접근은 "RoadRunner"라는 컴퓨터에 대한 것입니다.
- 이 접근은 "IP" 혹은 TCP/IP 프로토콜을 통한 것입니다.
- 이 접근은 방화벽으로 "들어오는"("fw-in") 것입니다.
* 다른 로그들은 "나가는" 것에 대해서 "fw-out" 혹은 FORWARD하는
것에 대해서는 "fw-fwd"라고 할 것입니다.
- 이 접근은 "거부되었습니다(rejECTED)".
* 다른 로그들은 "deny" 혹은 "accept"라고 할 수도 있습니다.
- 이 방화벽 접근 "eth0" 인터페이스(인터넷 연결)에서 일어났습니다.
- 이 접근은 "TCP" 패킷이었습니다.
- 이 접근은 "12.75.147.174"fksms IP 주소로부터 온 것이고 "1633"번
포트로 돌려졌습니다.
- 이 접근은 "100.200.0.212"라는 주소에 "23"번 포트 혹은 TELNET으로
연결하기 위한 것이었습니다.
* 23번 포트가 TELNET을 위한 것인지 잘 모르겠다면,
/etc/services 화일에서 포트를 확인하십시요.
- 이 패킷은 크기가 "44" 바이트였습니다.
- 이 패킷은 "Type of Service(서비스 종류)"가 설정돼 있지 않았습니다.
--이 말을 이해하지 못하더라고 걱정하지 마십시요.. 알 필요
없습니다.
* ipchains 사용자의 경우 이 값을 4로 나누면 서비스 종류가
됩니다.
- 이 패킷은 "IP ID" 번호가 "18" 이었습니다.
--이 말을 이해하지 못하더라고 걱정하지 마십시요.. 알 필요
없습니다.
- 이 패킷은 16비트의 조각 위치를 가지고 있고 TCP/IP 패킷 플래그는
"0x0000"이었습니다.
--이 말을 이해하지 못하더라고 걱정하지 마십시요.. 알 필요
없습니다.
* "0x2..."나 "0x3..."로 시작하는 값은 "더 많은 조각" 비트가
되어서 더많은 조각난 패킷들이 도착해야지 이 "큰" 패킷이
완성될 것이라는 것을 의미합니다.
* "0x4..."나 "0x5..."로 시작하는 값은 "조각내기 금지" 비트가
설정되어 있다는 것을 의미합니다.
* 다른 값들은 조각 위치 (8로 나우었을 때) 값들이고 나중에 원래의
큰 패킷으로 조합할 때 사용됩니다.
- 이 패킷은 지속시간(TimeToLive) (TTL)이 20이었습니다.
* 인터넷상에서의 매 도약 때 마다 이 값은 1씩 감소합니다. 보통,
패킷들은 출발할 때 255의 값을 갖고 만약 이 숫자가 결국 0이
되면, 패킷은 없어진 것이라서 지워지게 될 겁니다.
예! IPPORTFW를 사용하면, 모든, 혹은 선택된 몇몇 인터넷 호스트들이 내부의 마스커레이드되는 컴퓨터들에 접속할 수 있도록 할 수 있습니다. 이 주제에 대해서는 Forwarders 섹션에서 상세히 다루고 있습니다.
내부의 마스커레이드되는 머신 중 하나가 인터넷으로 나가는 패킷을 비정상적으로 많이 만들고 있기 때문입니다. IP 마스커레이드 서버는 마스커레이드 테이블을 만들고 이 패킷들을 인터넷으로 내보내는데, 이 테이블이 너무 빨리 채워지는 겁니다. 일단 테이블이 꽉 차게 되면, 이와 같은 에러를 내게 됩니다.
이러한 상황을 만들어 내는 응용프로그램으로서 제가 알고 있는 유일한 것은 "GameSpy"라는 게임 프로그램입니다. 이유는, Gamespy라는 게임은 서버의 리스트를 만들고, 그 리스트에 있는 수천개의 모든 게임 서버에 ping을 하기 때문입니다. 이렇게 ping을 함으로써, 매우 짧은 시간동안 수만개의 빠른 접속을 요구합니다. 이들이 IP 마스커레이드의 시간제한에 걸려서 끝날 때까지, 마스커레이드 테이블을 "꽉" 차게 됩니다.
그럼 어떻게 하나요? 이상적으로 말한다면, 그런 프로그램은 쓰지 마십시요. 로그 화일에 그런 에러들이 쌓인다면, 어떤 프로그램인지 찾아내서 사용을 중지하십시요. 하지만, 여러분이 GameSpy같은 게임을 정말로 좋아한다면, 서버 목록을 갱신하는 것을 많이 하지 마십시요. 어쨌든, 그런 프로그램들을 사용하지 않는다면, 마스커레이드가 내보내던 그 에러들은 더 이상 나타나지 않을 겁니다.
"ipfwadm: setsockopt failed: Protocol not available"라는 에러 메시지를 만난다면, 새롭게 컴파일한 커널을 사용하고 있지 않은 것입니다. 새 커널을 제 위치에 옮기고, LILO를 다시 실행하고, 다시 재부팅해 보십시요.
자세한 사항은 Forwarders 섹션의 마지막 부분을 보십시요.
Microsoft의 SMB 프로토콜을 제대로 지원하기 위해서는 그를 위한 마스커레이드 모듈이 있어야 하지만, 현재로서는 세가지의 우회적인 방법이 있습니다. 자세한 사항은, this Microsoft KnowledgeBase article을 보십시요.
첫번째 우회방법은, IPPORTFW를 Forwarders 섹션에 나온 대로 설정하고, TCP 포트 137, 138, 139를 내부의 윈도우즈 머신의 IP 주소로 포워드하는 것입니다. 이렇게 하면 동작하긴 하지만, 오직 한 개의 내부 머신에 대해서만 동작할 것입니다.
두번재 방법은, 리눅스 마스커레이드 서버에 Samba를 설치하는 것입니다. Samba가 실행하면, 내부의 윈도우즈의 화일 프린트 공유를 Samba 서버에서 보이게 할 수 있습니다. 그러면, 외부의 모든 클라이언트에서 이 공유들에 접근할 수 있게 됩니다. Samba를 설정하는 방법은 리눅스 문서 프로젝트의 HOWTO에서 찾을 수 있고, TrinityOS 문서에서도 역시 찾을 수 있을 것입니다.
세번째 방법은, 두 왼도우즈 머신 사이에, 혹은 두 네트웍 사이에 VPN(가상 개인 네트웍)을 설정하는 것입니다. 이것은 PPTP나 IPSEC VPN 솔루션을 사용해서 설정할 수 있습니다. 리눅스용의 PPTP 패치도 있고, 2.0.x와 2.2.x 커널에서 사용할 수 있는 완전한 IPSEC도 구현되어 있습니다. 이 방법은 세가지 방법 중에서 가장 안정적이고 안전한 방법입니다.
이 방법들은 이 HOWTO에서 다루지는 않습니다. IPSEC에 대해서는 TrinityOS 문서에서 도움을 받을 수 있을 것이고, 그 이상의 정보는 JJohn Hardin의 PPTP 페이지를 볼 것을 권장합니다.
또한 알아 둘 것은, Microsoft의 SMB 프로토콜은 보안에 매우 취약하다는 것입니다. 이 때문에, 인터넷을 통해서 암호화 없이 Microsoft 화일 프린트 공유나 왼도우즈 도메인 로긴을 사용하는 것은 매우 좋지 않습니다.
주된 원인으로 생각할 수 있는 것은, 대부분의 리눅스 배포본들의 IDENT나 "인증" 서버는 IP 마스커레이드되는 연결을 처리하지 못 한다는 겁니다. 하지만 걱정할 것은 없습니다. 제대로 동작하는 IDENT들이 있으니까요.
이 소프트웨어를 설치하는 것은 이 HOWTO의 내용을 벗어나는 것입니다. 각각의 도구들은 각각 문서들을 가지고 있습니다. 여기에 몇개의 URL들을 적습니다:
어떤 인터넷 IRC 서버들은 여전히 같은 호스트에서 여러개의 접속을 하는 것을 허용하지 않고 있습니다. 인증 정보를 통해서 사용자들이 서로 다르다는 것을 알 수 있더라도 말입니다. 그 때는 그 서버의 관리자에게 항의하십시요. :)
이것은 mIRC의 설정 문제입니다. 고치기 위해서는, 우선 mIRC를 IRC 서버로부터 접속을 끊습니다. 그리고, mIRC에서 화일 --> 설정으로 가서 "IRC servers tab"을 클릭합니다. 포트가 6667로 설정되어 있는지 확인합니다. 다른 포트를 사용해야 한다면, 이 아래에 있는 내용을 보십시요. 다음으로, 화일 --> 설정 --> 지역 정보로 가서 지역 호스트(자신의 호스트)에 해당하는 부분과 IP 주소를 지웁니다. "LOCAL HOST"와 "IP address"(IP address는 체크되었지만 사용불가로 될 수 있습니다)의 체크박스를 선택합니다. 다음으로, "Lookup Method(검색방법)"을 "normal(보통)"으로 설정합니다. 만약에 "servers"가 선택되어 있으면 동작하지 않을 겁니다. 자 끝났습니다. IRC 서버에 다시 접속해 보십시요.
IRC 서버의 포트를 6667이 아닌 것을 사용해야 한다면, (예를 들어 6969) IRC 마스커레이드 모듈을 로드하는 /etc/rc.c/rc.firewall 화일을 편집해야 합니다. 이 화일에서 "modprobe ip_masq_irc"라는 줄이 있는 곳을 편집해서 "ports=6667,6969"를 구가합니다. 다른 포트들도 콤마로 구분해서 추가할 수 있습니다.
마지막으로, 마스커레이드되는 머신들의 IRC 클라이언트들을 종료하고 IRC 마스커레이드 모듈을 다시 로드합니다:
/sbin/rmmod ip_masq_irc /etc/rc.d/rc.firewall
그렇기도 하고 아니기도 합니다. "IP Alias"라는 커널의 기능을 통해서, 사용자는 eth0:1, eth0:2 등과 같이 여러개의 인터페이스를 설정할 수 있습니다. 하지만, IP 마스커레이드에 alias된 인터페이스를 사용하는 것은 추천하지 않습니다. 왜냐구요? 한 개의 네트웍 카드를 통해서는 안전한 방화벽을 구성하는 것이 대단히 어렵습니다. 또한, 패킷들이 들어오면 또 동시에 내보내지기 때문에 상당량의 에러들이 날 것입니다. 이런 이유도 있고 또 요즘은 네트웍 카드가 저렴하기 때문에, 저는 여러분에게 네트웍 카드를 더 구입할 것을 강력히 권장합니다.
여러분이 또 알아둬야 할 것은, IP 마스커레이딩은 eth0, eth1 등과 같은 물리적인 인터페이스에서만 제대로 동작한다는 겁니다. "eth0:1, eth1:1 등과 같이" alias 된 인터페이스에서 마스커레이딩은 제대로 동작하지 않을 겁니다. 말하자면, 다음과 같은 경우는 동작하지 않을 겁니다:
하지만 여전히 alias 된 인터페이스를 사용하고 싶다면, 커널에서 "IP Alias" 기능을 켜야 합니다. 그리고 커널을 다시 컴파일하고 재부팅해야 합니다. 새로운 커널로 부팅하고 나면, 리눅스가 새로운 인터페이스(예를 들면 /dev/eth0:1 등)를 사용하도록 설정해 줘야 합니다. 그리고 나면, 앞서 말한 것과 같은 제약은 있지만 그것들을 보통의 이더넷 인터페이스처럼 사용할 수 있습니다.
"netstat" 프로그램에는 문제가 있습니다. 리눅스 부트된 직후에, "netstat -M"라고 명령하면 잘 동작하지만, 마스커레이드되는 컴퓨터가 ping이나 traceroute 같은 ICMP 통신을 수행하고 나서는 다음과 같은 것을 보게 될 겁니다:
masq_info.c: Internal Error `ip_masquerade unknown type'.
이를 위한 다른 방법은 "/sbin/ipfwadm -M -l"라는 명령을 사용하는 겁니다. 또한 열거된 ICMP 마스커레이드 항목들이 끝나고 나면, "netstat"가 다시 잘 동작하는 걸 보게 될 겁니다.
가능합니다. 하지만 이 문서의 범주를 벗어나는 것이므로, 자세한 정보는 John Hardin의 PPTP Masq를 보시기 바랍니다.
우선, Steve Grevemeyer's MASQ Applications page를 살펴보십시요. 거기에 해결책이 없다면, 위의 LooseUDP 섹션에 있는 Glenn Lamb의 LooseUDP 패치로 리눅스 커널을 패치해 보십시요. 더 자세한 정보는 Dan Kegel의 NAT Page를 살펴보십시요.
여러분이 기술적인 능력이 있다면, "tcpdump" 프로그램을 사용해서 여러분의 네트웍을 sniff 해 보십시요. 그 XYZ 게임이 사용하고 있는 프로토콜과 포트 번호를 알아내는 겁니다. 이 정보들을 알아내면, IP Masq email list에 가입하고 여러분의 결과를 이 메일로 보내고 도움을 요청하십시요.
제가 생각하기에 여러분은 IPAUTOFW을 사용하고 있거나 커널에 포함시켰을 겁니다. 맞나요?? 이건 IPAUTOFW의 잘 알려진 문제점입니다. 리눅스 커널에 IPAUTOFW 기능을 포함시키지 말고, 대신 IPPORTFW 옵션을 사용하십시요. 이 문제들은 Forwarders 섹션에서 자세히 다루고 있습니다.
이것이 마스커레이딩에 관련된 사항은 아지만, 많은 사람들에 관계된 것이기 때문에 여기에 언급합니다.
SMTP: 여러분은 아마도 리눅스 박스를 SMTP 중계기(relay)로 사용하려고 하고 다음과 같은 에러가 날 겁니다:
"error from mail server: we do not relay"
POP-3: 어떤 사용자들은 내부의 마스커레이드되는 컴퓨터의 POP-3 클라이언트들이 외부의 SMTP 서버에 접속하도록 설정합니다. 이건 괜찮지만, 많은 SMTP 서버들은 포트 113으로 여러분의 연결을 인증(IDENT)하고자 할 것입니다. 문제가 발생하는 것은, 대부분 여러분의 기본 마스커레이드 정책이 DENY인 것과 관련돼 있습니다. 이건 바람직하지 않습니다. 이것을 REJECT로 설정하고 rc.firewall 정책을 다시 실행하십시요.
여러분이 다음과 같은 문제를 가지고 있다고 합시다:
내부 LAN -----> 공식 IP 192.168.1.x --> 123.123.123.11 192.168.2.x --> 123.123.123.12
여러분은 우선, IPFWADM과 IPCHAINS는 라우팅 시스템이 패킷을 어디로 보낼 것인가를 결정한 *후에* 실행된다는 사실을 이해해야 합니다. 이 사실은 모든 IPFWADM/IPCHAINS/IPMASQ 문서에 커다른 붉은 글씨로 도장을 찍어놔야 마땅합니다. 우선 라우팅이 제대로 되도록 하고 나서 IPFWADM/IPCHAINS나 마스커레이딩을 추가해야 하는 겁니다.
위의 경우에서는, 우선 라우팅 시스템이 192.168.1.x로부터의 패킷을 123.123.123.11로, 192.168.2.x로부터의 패킷을 123.123.123.12로 보내도록 설정해야 합니다. 이 작업이 어려운 작업이고, 그 위에 마스커레이드를 설정하는 것은 쉽습니다.
이 작업을 위해서 IPROUTE2를 사용할 수 있습니다.
Primary FTP site is:
Mirrors are:
ftp://linux.wauug.org/pub/net ftp://ftp.nc.ras.ru/pub/mirrors/ftp.inr.ac.ru/ip-routing/ ftp://ftp.gts.cz/MIRRORS/ftp.inr.ac.ru/ ftp://ftp.funet.fi/pub/mirrors/ftp.inr.ac.ru/ip-routing/ (STM1 to USA) ftp://sunsite.icm.edu.pl/pub/Linux/iproute/ ftp://ftp.sunet.se/pub/Linux/ip-routing/ ftp://ftp.nvg.ntnu.no/pub/linux/ip-routing/ ftp://ftp.crc.ca/pub/systems/linux/ip-routing/ ftp://ftp.paname.org (France) ftp://donlug.ua/pub/mirrors/ip-route/ ftp://omni.rk.tusur.ru/mirrors/ftp.inr.ac.ru/ip-routing/
RPMs are available at ftp://omni.rk.tusur.ru/Tango/ and at ftp://ftp4.dgtu.donetsk.ua/pub/RedHat/Contrib-Donbass/KAD/
NOTE: The following instructions are given below ONLY because currently there is very little documentation to the IPROUTE2 tool available. Check out http://www.compendium.com.ar/policy-routing.txt for the beginnings of a IPROUTE2 howto.
The "iprule" and "iproute" commands are the same as "ip rule" and "ip route" commands (I prefer the former since it is easier to search for.) All the commands below are completely untested, if they do not work, please contact the author of IPROUTE2.. not David Ranch, Ambrose Au, or anyone on the Masq email list as it has NOTHING to do with IP Masquerading.
The first few commands only need to be done once at boot, say in /etc/rc.d/rc.local file.
# Allow internal LANs to route to each other, no masq.
/sbin/iprule add from 192.168.0.0/16 to 192.168.0.0/16 table main pref 100
# All other traffic from 192.168.1.x is external, handle by table 101
/sbin/iprule add from 192.168.1.0/24 to 0/0 table 101 pref 102
# All other traffic from 192.168.2.x is external, handle by table 102
/sbin/iprule add from 192.168.2.0/24 to 0/0 table 102 pref 102
These commands need to be issued when eth0 is configured, perhaps in
/etc/sysconfig/network-scripts/ifup-post (for Redhat systems). Be sure to
do them by hand first to make sure they work.
# Table 101 forces all assigned packets out via 123.123.123.11
/sbin/iproute add table 101 via 62123.123.123.11
# Table 102 forces all assigned packets out via 123.123.123.12
/sbin/iproute add table 102 via 62123.123.123.12
At this stage, you should find that packets from 192.168.1.x to the
outside world are being routed via 123.123.123.11, packets from
192.168.2.x are routed via 123.123.123.12.
Once routing is correct, now you can add any IPFWADM or IPCHAINS rules.
The following examples are for IPCHAINS:
/sbin/ipchains -A forward -i ppp+ -j MASQ
If everything hangs together, the masq code will see packets being
routed out on 123.123.123.11 and 123.123.123.12 and will use those addresses
as the masq source address.
IPCHAINS supports the following features that IPFWADM doesn't:
There are several things you should check assuming your Linux IP Masq box already have proper connection to the Internet and your LAN:
/usr/src/linux/Documentation/Changes and make sure you have the minimal requirement for the network tools installed.
There are several things you should check assuming your Linux IP Masq box already have proper connection to the Internet and your LAN:
/usr/src/linux/Documentation/Changes and make sure you have the minimal requirement for the network tools installed.
EQL has nothing to do with IP Masq though they are commonly teamed up on Linux boxes. Because of this, I recommend to check out the NEW version of Robert Novak's EQL HOWTO for all your EQL needs.
Giving up a free, reliable, high performance solution that works on minimal hardware and pay a fortune for something that needs more hardware, lower performance and less reliable? (IMHO. And yes, I have real life experience with these ;-)
Okay, it's your call. If you want a Windows NAT and/or proxy solution, here is a decent listing. I have no preference of these tools since I haven't used them before.
Lastly, do a web search on "MS Proxy Server", "Wingate", "WinProxy", or goto www.winfiles.com. And definitely DON'T tell anyone that we sent you.
Join the Linux IP Masquerading DEVELOPERS list and ask the developers there what you can help with. For more details on joining the lists, check out the Masq-List FAQ section.
Please DON'T ask NON-IP-Masquerade development related questions there!!!!
You can find more information on IP Masquerade at the Linux IP Masquerade Resource that both David Ranch and Ambrose Au maintain.
You can also find more information at Dranch's Linux page where the TrinityOS and other Linux documents are kept.
You may also find more information at The Semi-Original Linux IP Masquerading Web Site maintained by Indyramp Consulting, who also provides the IP Masq mailing lists.
Lastly, you can look for specific questions in the IP MASQ and IP MASQ DEV email archives or ask a specific question on these lists. Check out the Masq-List FAQ item for more details.
Make sure the language you want to translate to is not already covered by someone else. But, most of the translated HOWTOs are now OLD and need to be updated. A list of available HOWTO translations are available at the Linux IP Masquerade Resource.
If a copy of a current IP MASQ HOWTO isn't in your proposed language, please download the newest copy of the IP-MASQ HOWTO SGML code from the Linux IP Masquerade Resource. From there, begin your work while maintaining good SGML coding. For more help on SGML, check out www.sgmltools.org
Yes, this HOWTO is still being maintained. In the past, we've been guilty of being too busy working on two jobs and don't have much time to work on this, my apology. As of v1.50, David Ranch has begun to revamp the document and get it current again.
If you think of a topic that could be included in the HOWTO, please send email to ambrose@writeme.com and dranch@trinnet.net. It will be even better if you can provide that information. We will then include the information into the HOWTO once it is both found appropriate and tested. Many thanks for your contributions!
We have a lot of new ideas and plans for improving the HOWTO, such as case studies that will cover different network setup involving IP Masquerade, more on security via strong IPFWADM/IPCHAINS firewall rulesets, IPCHAINS usage, more FAQ entries, etc. If you think you can help, please do! Thanks.