이글은 커널모드 PPPoE에서 한국통신의 유동IP를 사용하는 경우에 대해서 설명합니다. 유저모드 PPPoE에서 유동IP를
사용하는 부분은 다른 문서를 참조하기 바랍니다. 이글은 한국통신의 xDSL을 사용을 가정했기 때문에 PPTP를 사용하는
하나로통신
같은 경우는 해당되지 않습니다.(이글에서 사용하는 mpd라는 프로그램이 PPTP를 지원하지만 시험해보지는 못했습니다.)
고정IP를 사용하는 경우에는 유저모드/커널모드 PPPoE의 설정이 필요가 없습니다. FreeBSD에서는 마치 전용선에 물려
있는것처럼 설정하면 되고 다른 모든 복잡한 부분은 xDSL모뎀에서 처리합니다.
유저모드 PPPoE문서
http://www.kr.freebsd.org/doc/howto-hanaro_ADSL/
http://www.kr.freebsd.org/doc/howto-kt_ADSL
(주의:
본글에서 설명하는 하나의 xDSL 라인을 이용하여 여러 시스템이 사용하는 방법은 국내의 ISP에서 금지하고 있는 방법일 수
있습니다. ISP에서는 별도의 부가비용을 청구하거나 서비스의 중단등의 조치를 취할 수 도 있습니다. 이 방법을 사용하다가 발생할
수 있는 정식적/물질적인 모든 문제는 이를 사용하는 사용자에게 전적으로 달려 있습니다.)
커널모드 PPP는 FreeBSD의 공식 문서에도 제대로 설명되어 있지 않아서 많은 분들이 그 실체와 장점을
모르고 있습니다.국내의 xDSL에서 사용하는 PPPoE는 대부분의 사용자들이 유저모드 PPPoE Client인 ppp(8)를
사용하고 있습니다. 유저모드 PPPoE는 개발의 편리함과 디버깅의 장점이 있으나 커널과 사용자 영역간의 데이터
전송(copyin(9), copyout(9))으로 인해서 많은 부하를 가지고 있습니다. 개인 사용자가 단순한 PPPoE
Client로 사용하기에는 아직 xDSL의 속도가 빠르지 않기 때문에 별 문제가 없지만, 방화벽과 NAT를 결합하여
PPPoE Client를 gateway로 사용할 경우 효율적인 처리에 어려움이 있을 수 있습니다. 이 글은 커널모드상에서
동작하는
PPPoE를 구성하여 구형의 느린 시스템으로도 방화벽의 stateful inspection과 NAT를 결합한 상태에서도 최적의
성능을 낼 수 있는 방법을 설명합니다.
<그림 1>은 커널모드
PPPoE설정에 사용할 netowrk구성도 입니다.
[FreeBSD mpd]
[전화국의 DSLSM]<--------------->|xDSL모뎀 |<----------------->|
NIC NIC
|<------------->[HUB]<------------------>
전화선
UTP |fxp0 fxp1 |
UTP
192.168.1.X
유동 IP 192.168.1.1
이 글은 FreeBSD 4.7과
FreeBSD 5.0상에서 mpd 3.12로 시험하였습니다.
커널모드 PPPoE의 제어를
담당하는 프로그램은 mpd에서 담당합니다. mpd는 시스템에 기본으로 설치되지 않기 때문에 ports에서 설치하도록 합니다.
되도록 ports를 최신의 것으로 갱신한다음 설치하도록 합니다. ports의 갱신은 cvsup(1)과
/usr/share/exmaples/cvsup을 참조하기 바랍니다.
유저모드 ppp(8)와 달리 mpd는 기본 프로그램이 아니기 때문에 Inernet이 되는 시스템에서 mpd프로그램을
다운로드하여 /usr/ports/distfiles로 복사 후 설치하거나 또는 pkg_add(1)를 이용해서 binary를
설치해야
합니다. 두 방법 모두 network이 되지 않으면 소용이 없기 때문에 network이되는 다른 시스템을 이용해야 합니다. 다른
방법으로는 유저모드 ppp(8)로 먼저 설정 후 다시 mpd를 설치하면 됩니다.
%su -
#cd /usr/ports/net/mpd
#make && make install && make clean
설치가 끝나면 mpd는 /usr/local/sbin에 설치되고 mpd의 설정 파일은
/usr/local/etc/mpd에 sample 설정파일과 함께 설치됩니다. mpd의 도움말은
/usr/local/share/doc/mpd에 postscript와 html로 설치되므로 필요할 경우 참조하면 되겠습니다.
mpd는 PPPoE뿐 아니라 많은
다른 방식도 지원하기 때문에 설정이 복잡한 편입니다. 그중 가장 특이할만한 것은 Multi-link PPP의 지원으로 여러개의
물리적인 PPP 라인이 있을 경우 이를 하나의 bundle이라는 개념으로서 관리를 하며 사용자는 동시에 여러개의 PPP라인을
마치
하나의 속도가 빠른 PPP접속으로 취급할 수 있습니다. 그러나 현재 국내의 ISP에서 Multi-link PPP를 지원하지는
않는
것으로 알고 있습니다. (Multi-link PPP는 유저모드 PPPoE Client인 ppp(8)에서도 지원됩니다.)
mpd의 설정은 최소한 mpd.conf,mpd.links, mpd.secret의 세개의 파일을 수정해야
합니다.(mpd는 PPPoE와 함께 PPTP도 지원합니다. 하나로통신의 xDSL을 사용하는 분은 설치된
mpd.conf.sample의 PPTP부분을 참조하기 바랍니다.)
한국통신 xDSL사용시 다음이면
충분하며, 별도의 세밀한 설정이 필요한분은 /usr/local/share/doc/mpd에 설치된 문서를 참조하기 바랍니다.
#
# Default
configuration
#
default:
load
PPPoE0
---- (1)
---- (2)
#
#
Bundle/PPPoE client example (see also mpd.links.sample entry "PPPoE")
#
# Bundle
ASDL
Link0
PPPoE0:
---- (3)
new -i ng0 PPPoE0
PPPoE0
---- (4)
set iface addrs 1.1.1.1
2.2.2.2
---- (5)
set iface route
default
---- (6)
set iface disable
on-demand
---- (7)
set iface idle
0
---- (8)
set bundle disable
bw-manage
---- (9)
set bundle disable
multilink
---- (10)
set bundle authname "신청한
ID"
---- (11)
set link no acfcomp
protocomp
---- (12)
set link disable pap
chap
---- (13)
set link accept pap
chap
---- (14)
set link mtu
1492
---- (15)
set ipcp yes
vjcomp
---- (16)
set ipcp ranges 0.0.0.0/0
0.0.0.0/0
---- (17)
#set iface up-script
/usr/local/etc/mpd/mpd.linkup
---- (18)
#set iface down-script
/usr/local/etc/mpd/mpd.linkdown
---- (19)
open
iface
---- (20)
각 설정의 #으로 시작하는 라인은 주석으로
설정에는 아무 관련이 없습니다.
(1)은 PPPoE0 라는 설정을 mpd.conf에서 찾아서 load하라는 것입니다.
(2)의 빈줄은 load PPPoE0 명령이 멈출 부분을 지정하는 것입니다. 만일 이 부분이 없다면 계속해서 다음 라인을
실행하려고 할것입니다.
(3)은 load PPPoE0에서 지정한 설정 PPPoE0의 시작을 나타냅니다. mpd.conf파일에는 여러개의 설정이 동시에
있을 수 있고 특별히 지정하지 않으면 default: 설정을 실행하게 됩니다.(ppp.conf와 동일한 방식입니다.)
(4)의 -i ng0는 사용할 netgraph interface를 지정합니다. 특별히 지정하지 않으면 mpd가 실행시 마다
새로운 netgraph node를 생성하므로 특별한 이유가 없다면 항상 지정하도록 합니다. ng0다음의 PPPoE0
PPPoE0는
각각 bundle 이름이 PPPoE0, link이름이 PPPoE0 임을 나타냅니다. 하나의 bundle은 보통 여러개의
link로
이루어 집니다. 우리의 경우 xDSL라인이 하나이기 때문에 하나의 link로 bundle이 구성됩니다.
(5)는 가상의 IP로서 접속이 이루어지면 할당받은 IP주소로 대치됩니다.
(6)은 접속이 이루어 지면 할당받은 주소를 default gateway로 설정하도록 하는 것입니다. 동작중 다시유동
IP가 변경되면 이에 따라서 default gateway도 자동으로 변경됩니다.
(7),(8)은 접속이 항상 유지 되도록 하기 위해서 있습니다. 국내에서는 xDSL사용시 접속시간과 패킷의 양에 관계없이 요금이
일정하기 때문에 항상 접속되어 있도록 하는것이 유리합니다.
(9)는 트래픽량에 따라서 동적으로 접속을 제한하는 기능을 사용하지 않도록 설정했습니다.
(10)은 Multi-link PPP의 지원을 위한것이지만 국내서는 Multi-link PPP의 지원이 되지 않으므로 off로
설정합니다.
(11)은 xDSL신청시 기재한 사용자 ID입니다.
(12)는 xDSL에서는 Address, Control, Protocol field를 압축하지 않도록 합니다.
(13),(14)는 인증방식을 지정합니다. 한국통신의 경우 PAP를 사용합니다.
(15)는 xDSL라인이 사용할 MTU를 지정합니다. ethernet이면서도 MTU가 1500으로 설정하지 않는 이유는 우리가
실제로는 PPP를 사용하기 때문입니다.
(16)은 유동IP를 받기위한 protocol IPCP에서 vjcomp(Van Jacobson TCP header
compression)를 사용하도록 지정합니다. vjcomp는 PPP에서 TCP header의 데이터 양을 줄여 성능을
향상시킵니다.
(17)은 부여받을 IP의 범위를 지정하는 것입니다. 0.0.0.0/0은 어떤 것이나 가능함을 말합니다. 고정IP를 사용하는
경우는 이부분을 서비스신청시 부여받은 것으로 설정하라고 하지만 이렇게 하면 국내에서는 동작하지 않습니다. 한국통신의 고정IP
서비스를 이용하는 분은 PPPoE는 다 잊어버리고 전용선처럼 설정하면 됩니다.
(18), (19)는 interface가 up 또는 down되었을 때 실행할 script를 지정합니다. 보통의 경우에는 필요가
없지만 방화벽/NAT와의 연동으로 interface의 주소가 변경될 경우 새로운 주소를 방화벽과 NAT룰에 설정할 때 지정하도록
합니다.
(20)은 interface를 설정하고 부여받은 IP를 이용해서 route를 설정하도록 합니다. 유저모드 ppp(8)와 달리
mpd에서는 "enable dns"에 해당하는 부분이 없습니다. 그러므로 사용자는 자신이 사용할 DNS를
/etc/resolv.conf에 다음과 같이 직접
지정해야 합니다.
search yourdomain.co.kr
nameserver 168.126.63.1
#nameserver 2차 name server IP
#nameserver 3차 name server IP
mpd.conf에서 지정한
설정에서
사용할 link를 설정합니다.
#
# mpd.links
#
PPPoE0:
---- (1)
set link type
pppoe
---- (2)
set pppoe iface
fxp0 ----
(3)
(1)은 2.3.1의 mpd.conf의 (3)에서 지정한 link의 이름입니다.
(2)는 해당 link가 PPPoE를 사용한다는 것을 알립니다.
(3)은 xDSL의 모뎀에 UTP Cable로 연결된 FreeBSD시스템의 NIC 디바이스 이름을 지정합니다.(그림 1 참조)
fxp외의 다른 디바이스라면 이 부분을 rl0, xl0 등으로 변경하십시요.
mpd.conf의 (11)에서
지정한 설정에서 사용할 link의 ID와 비밀번호를 지정합니다.
#
# mpd.secret
#
신청한ID
"비밀번호" ----- (1)
(1)은 2.3.1의 mpd.conf의 (11)에서 지정한 ID입니다.
ID와 비밀번호는 최소 하나 이상의 탭문자로 구분되어야 합니다.
mpd는 유저모드 ppp(8)와
동일한 설정을 사용합니다. 다음을 /etc/syslog.conf에 추가하고 syslogd를 restart합니다.
!mpd
*.*
/var/log/mpd.log
/var/log/mpd.log는 touch를 이용해서 생성하고 필요할 경우 /etc/newsyslog.conf에서
/var/log/mpd.log의 rotation이 일어나도록 설정 합니다.
xDSL과 연결된 fxp0는
IP를
할당하지 않도록 하고 Switching Hub와 연결된 fxp1에는 192.168.1.1과 같이 gateway로 사용할 IP를
할당합니다. 이미 fxp0에 IP가 할당되었다면 이를 제거 합니다.
#ifconfig fxp0 inet delete X.X.X.X
#ifconfig fxp1 inet 192.168.1.1
netmask 255.255.255.0 up
그리고 ifconfig -a를 이용해서 xDSL과 Hub로 부터의 Carrier 신호가 오는지 확인합니다.
#ifconfig -a
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6
fe80::290:27ff:fe35:6c4c%fxp0 prefixlen 64 scopeid 0x1
ether 00:90:27:35:6c:4c
media: Ethernet autoselect
(100baseTX <full-duplex>)
status: active
fxp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.1.1 netmask
0xffffff00 broadcast 192.168.1.255
inet6
fe80::2d0:b7ff:fe2c:a06c%fxp1 prefixlen 64 scopeid 0x2
ether 00:d0:b7:2c:a0:6c
media: Ethernet autoselect
(100baseTX <full-duplex>)
status: active
fxp0는 IPv4주소가 지정되지 않았고, fxp0, fxp1의 status가 "active"인 것을 확인합니다.
mpd에는 현재 PPPoE에서 netgraph ethernet 커널 모듈을 제대로 올리지 못하는 버그가
있습니다. 이의 해결하기 위해서 실행하기전 먼저 해당 모듈을 로드하도록 합니다. 모든 설정이 끝나면 mpd를 실행하고
제대로 연결이 되는지 확인합니다.
#kldload ng_ether
#/usr/local/sbin/mpd
mpd가 실행되면 foregound로 실행되므로 모든 메세지가 stdout으로 출력됩니다. 만일
ng_ether 커널모듈을 로드하지 않으면 "can't create pppoe peer to fxp0:,orphans: No
such file or directory"라는 메세지가 stdout으로 출력됩니다.
정상적인 연결이 되지 않으면 ^C 로 실행을 중지한 후 설정파일등을 검사하고 다시 실행해서 정상적인 연결이 되는것을
확인합니다. 정상적으로 접속이 된다면 다음과 같은 메세지가 /var/log/mpd.log에 생성됩니다.
Feb 26 18:07:02 monster mpd: mpd: pid 539, version 3.12
(root@monster.kt-is.co.kr 07:52 26-Feb-2003)
Feb 26 18:07:02 monster mpd: [PPPoE0] ppp node is "mpd539-PPPoE0"
Feb 26 18:07:02 monster mpd: [PPPoE0] using interface ng0
Feb 26 18:07:02 monster mpd: [PPPoE0] IPCP: peer address cannot be zero
Feb 26 18:07:02 monster mpd: [PPPoE0] IFACE: Open event
Feb 26 18:07:02 monster mpd: [PPPoE0] IPCP: Open event
Feb 26 18:07:02 monster mpd: [PPPoE0] IPCP: state change Initial -->
Starting
Feb 26 18:07:02 monster mpd: [PPPoE0] IPCP: LayerStart
Feb 26 18:07:02 monster mpd: [PPPoE0] bundle: OPEN event in state CLOSED
Feb 26 18:07:02 monster mpd: [PPPoE0] opening link "PPPoE0"...
Feb 26 18:07:02 monster mpd: [PPPoE0] link: OPEN event
Feb 26 18:07:02 monster mpd: [PPPoE0] LCP: Open event
Feb 26 18:07:02 monster mpd: [PPPoE0] LCP: state change Initial -->
Starting
Feb 26 18:07:02 monster mpd: [PPPoE0] LCP: LayerStart
Feb 26 18:07:02 monster mpd: [PPPoE0] device: OPEN event in state DOWN
Feb 26 18:07:02 monster mpd: [PPPoE0] exec: /sbin/ifconfig fxp0 up
Feb 26 18:07:03 monster mpd: [PPPoE0] device is now in state OPENING
Feb 26 18:07:03 monster mpd: [PPPoE0] rec'd command 9 from "[13]:"
Feb 26 18:07:03 monster mpd: [PPPoE0] rec'd command 11 from "[13]:"
Feb 26 18:07:03 monster mpd: [PPPoE0] connection successful
Feb 26 18:07:03 monster mpd: [PPPoE0] device: UP event in state OPENING
Feb 26 18:07:03 monster mpd: [PPPoE0] device is now in state UP
Feb 26 18:07:03 monster mpd: [PPPoE0] link: UP event
Feb 26 18:07:03 monster mpd: [PPPoE0] link: origination is local
Feb 26 18:07:03 monster mpd: [PPPoE0] LCP: Up event
Feb 26 18:07:03 monster mpd: [PPPoE0] LCP: state change Starting -->
Req-Sent
Feb 26 18:07:03 monster mpd: [PPPoE0] LCP: phase shift DEAD -->
ESTABLISH
Feb 26 18:07:03 monster mpd: [PPPoE0] LCP: SendConfigReq #1
Feb 26 18:07:03 monster mpd: MRU 1492
Feb 26 18:07:03 monster mpd: MAGICNUM 9b96017c
Feb 26 18:07:03 monster mpd: [PPPoE0] LCP: rec'd Configure Request #82
link 0 (Req-Sent)
Feb 26 18:07:03 monster mpd: MAGICNUM 4df3f406
Feb 26 18:07:03 monster mpd: MRU 1500
Feb 26 18:07:03 monster mpd: AUTHPROTO PAP
Feb 26 18:07:03 monster mpd: [PPPoE0] LCP: SendConfigAck #82
Feb 26 18:07:03 monster mpd: MAGICNUM 4df3f406
Feb 26 18:07:03 monster mpd: MRU 1500
Feb 26 18:07:03 monster mpd: AUTHPROTO PAP
Feb 26 18:07:03 monster mpd: [PPPoE0] LCP: state change Req-Sent -->
Ack-Sent
Feb 26 18:07:03 monster mpd: [PPPoE0] LCP: rec'd Configure Ack #1 link
0 (Ack-Sent)
Feb 26 18:07:03 monster mpd: MRU 1492
Feb 26 18:07:03 monster mpd: MAGICNUM 9b96017c
Feb 26 18:07:03 monster mpd: [PPPoE0] LCP: state change Ack-Sent -->
Opened
Feb 26 18:07:03 monster mpd: [PPPoE0] LCP: phase shift ESTABLISH -->
AUTHENTICATE
Feb 26 18:07:03 monster mpd: [PPPoE0] LCP: auth: peer wants PAP, I want
nothing
Feb 26 18:07:03 monster mpd: [PPPoE0] PAP: using authname "신청한 ID"
Feb 26 18:07:03 monster mpd: [PPPoE0] PAP: sending REQUEST
Feb 26 18:07:03 monster mpd: [PPPoE0] LCP: LayerUp
Feb 26 18:07:03 monster mpd: [PPPoE0] PAP: rec'd ACK #1
Feb 26 18:07:03 monster mpd: [PPPoE0] LCP: authorization successful
Feb 26 18:07:03 monster mpd: [PPPoE0] LCP: phase shift AUTHENTICATE
--> NETWORK
Feb 26 18:07:03 monster mpd: [PPPoE0] setting interface ng0 MTU to 1492
bytes
Feb 26 18:07:03 monster mpd: [PPPoE0] up: 1 link, total bandwidth 64000
bps
Feb 26 18:07:03 monster mpd: [PPPoE0] IPCP: Up event
Feb 26 18:07:03 monster mpd: [PPPoE0] IPCP: state change Starting
--> Req-Sent
Feb 26 18:07:03 monster mpd: [PPPoE0] IPCP: SendConfigReq #1
Feb 26 18:07:03 monster mpd: IPADDR 0.0.0.0
Feb 26 18:07:03 monster mpd: COMPPROTO VJCOMP, 16 comp. channels,
no comp-cid
Feb 26 18:07:03 monster mpd: [PPPoE0] IPCP: rec'd Configure Request
#123 link 0 (Req-Sent)
Feb 26 18:07:03 monster mpd: IPADDR 211.196.201.39
Feb 26 18:07:03 monster mpd: 211.196.201.39 is OK
Feb 26 18:07:03 monster mpd: [PPPoE0] IPCP: SendConfigAck #123
Feb 26 18:07:03 monster mpd: IPADDR 211.196.201.39
Feb 26 18:07:03 monster mpd: [PPPoE0] IPCP: state change Req-Sent
--> Ack-Sent
Feb 26 18:07:03 monster mpd: [PPPoE0] IPCP: rec'd Configure Reject #1
link 0 (Ack-Sent)
Feb 26 18:07:03 monster mpd: COMPPROTO VJCOMP, 16 comp. channels,
no comp-cid
Feb 26 18:07:03 monster mpd: [PPPoE0] IPCP: SendConfigReq #2
Feb 26 18:07:03 monster mpd: IPADDR 0.0.0.0
Feb 26 18:07:03 monster mpd: [PPPoE0] IPCP: rec'd Configure Nak #2 link
0 (Ack-Sent)
Feb 26 18:07:03 monster mpd: IPADDR 218.145.203.71
Feb 26 18:07:03 monster mpd: 218.145.203.71 is OK
Feb 26 18:07:03 monster mpd: [PPPoE0] IPCP: SendConfigReq #3
Feb 26 18:07:03 monster mpd: IPADDR 218.145.203.71
Feb 26 18:07:03 monster mpd: [PPPoE0] IPCP: rec'd Configure Ack #3 link
0 (Ack-Sent)
Feb 26 18:07:03 monster mpd: IPADDR 218.145.203.71
Feb 26 18:07:03 monster mpd: [PPPoE0] IPCP: state change Ack-Sent
--> Opened
Feb 26 18:07:03 monster mpd: [PPPoE0] IPCP: LayerUp
Feb 26 18:07:03 monster mpd: 218.145.203.71 ->
211.196.201.39
Feb 26 18:07:03 monster mpd: [PPPoE0] IFACE: Up event
Feb 26 18:07:03 monster mpd: [PPPoE0] setting interface ng0 MTU to 1492
bytes
Feb 26 18:07:03 monster mpd: [PPPoE0] exec: /sbin/ifconfig ng0
218.145.203.71 211.196.201.39 netmask 0xffffffff -link0
Feb 26 18:07:03 monster mpd: [PPPoE0] exec: /sbin/route add 0.0.0.0
211.196.201.39
Feb 26 18:07:03 monster mpd: [PPPoE0] IFACE: Up event
제일 마지막의 "IFACE: Up
event"를 주의해서 보시기 바랍니다. 이제 ifconfig를 실행해 보면 netgraph interface ng0가
생성되었습니다.
#ifconfig -a
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6
fe80::290:27ff:fe35:6c4c%fxp0 prefixlen 64 scopeid 0x1
ether 00:90:27:35:6c:4c
media: Ethernet autoselect
(100baseTX <full-duplex>)
status: active
fxp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.1.1 netmask
0xffffff00 broadcast 192.168.1.255
inet6
fe80::2d0:b7ff:fe2c:a06c%fxp1 prefixlen 64 scopeid 0x2
ether 00:d0:b7:2c:a0:6c
media: Ethernet autoselect
(100baseTX <full-duplex>)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen
64 scopeid 0x3
inet 127.0.0.1 netmask
0xff000000
ng0:
flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu
1492
inet 218.145.203.71 -->
211.196.201.39 netmask 0xffffffff
inet6
fe80::290:27ff:fe35:6c4c%ng0 prefixlen 64 scopeid 0x4
속도가 빠른 ftp site등에서 용량이 큰 파일을 받으면서 top(1)을 이용해서 시스템의 부하를
확인합니다. ppp(8)를 사용할때와 mpd를 사용시의 부하를 비교해 보면 커널모드 PPPoE의 장점을 실감할 수 있습니다.
mpd는 유저모드
ppp(8)와 달리 rc.conf에서 지정할 수 있는 방법이 없습니다.
필요할 경우 이를 지원하도록 script를 작성하면 되겠지만 현재로서는 /etc/rc.local 또는
/usr/local/etc/rc.d/mpd.sh에 지정하는 것이 가장 편리합니다. /etc/rc.conf에는 다음과 같이
지정합니다.
...
defaultrouter="NO"
ifconfig_fxp0=up
ifconfig_fxp1="inet 192.168.1.1 netmask 255.255.255.0"
ppp_enable="NO"
...
rc.local에는 다음과 같이 설정합니다.
#!/bin/sh
#
# kernel mode PPPoE setup
#
if [ -x /usr/local/sbin/mpd -a -f /usr/local/etc/mpd/mpd.conf ]; then
/sbin/kldload ng_ether
echo -n " mpd";
/usr/local/sbin/mpd -b
fi
mpd의 모든 설정이 완료되면
리부트
하고 mpd가 정상적으로 동작하고 있는지 확인합니다. 아울러 시스템의 network 또한 동작하는지 확인합니다. PPPoE
Client를 gateway로 지정해서 방화벽과 NAT를 사용하려면 다음절의 방화벽과 NAT와의 연동을 참조하세요.
FreeBSD에서는
ipfilter와
ipfw 그리고 제가 OpenBSD에서 포팅한 pf의 세개의 방화벽이
지원됩니다. 모두 장점과 단점이 있고, 커널모드 PPPoE와 함께 사용할 수 있기 때문에 사용하는 분의 취향에 따라서 선택하시면
됩니다.(FreeBSD pf는 FreeBSD 4.x에서 사용할
수 없습니다.) 본절에서는 pf와 ipfilter를 위주로 해서 설명하도록 하겠습니다. ipfw의 경우도 이와
유사합니다. ipfilter와 ipfw의 사용법은 Handbook이나 man페이지 에서 참조바랍니다. pf의 사용법은 다음을 참조바랍니다.
커널모드 PPPoE를 사용하는
FreeBSD시스템을 gateway로 사용하기 위해서는 rc.conf에 다음을 설정해야 합니다.
...
gateway_enable="YES"
...
또는 sysctl을 이용해서 OID를 설정하도록 합니다.
#sysctl net.inet.ip.forwarding=1
pf 에서는 다음의 방화벽 룰을
사용할 것입니다. 룰을 간단히 하기 위해서 방화벽에서는 내부단에서는 서비스를 하지 않는 것을 가정하였고, 모든 룰에는
stateful inspection 을 하도록 설정했습니다. 설정파일은 /etc/pf.conf에 지정하도록 합니다. 방화벽
룰셋에서 사용하는 interface는 ng0인것에 유의하시기 바랍니다. xDSL과 연결된 fxp0를 사용하거나 유저모드
ppp(8)처럼 tun0등을 사용하지 않도록 주의하십시요. 유동 IP를 사용할 경우 interface에 할당된 IP가 변경되므로
inbound packet의 source IP가 현재 자신의 IP로 지정되어 올경우 이를 막기위해서는 IP변동시 마다 새로
방화벽룰을 적용해야 합니다. 3.5 시작 script에의 적용을 참조하십시요.
(주의: 본절의 방화벽 룰은 단순한 PPPoE 시험용이므로
이를 실제 자신이 사용하는 network환경에 적용하려면 많은 부분을 수정해야 합니다. 이글은 방화벽 룰의 설정방법이 아니라
PPPoE gateway와의 연동에 중점을 두고 있기 때문에 가장 단순한 룰을 선택했습니다.)
3.2.1 pf 룰셋
#
ExtIF="ng0"
IntIF="fxp1"
INTERNAL="192.168.1.0/24"
table <badbost> const {0.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, \
224.0.0.0/4, 240.0.0.0/4, 10.0.0.0/8, \
172.16.0.0/12, 192.168.0.0/16, 255.255.255.255, \
127.0.0.1/8}
# hosts that can use this system as a gateway
table <allowhost>
const {192.168.1.1, 192.168.1.2, 192.168.1.6, \
192.168.1.21, 192.168.1.7, 192.168.1.12}
set loginterface $ExtIF
scrub in all
scrub out all random-id max-mss
1440
# NAT
nat on $ExtIF inet from $INTERNAL
to any ($ExtIF)
block
out log on
$ExtIF all
block
in log on
$ExtIF all
block return-rst out log on $ExtIF proto tcp all
block return-rst in log on $ExtIF proto tcp all
block return-icmp out log on $ExtIF proto udp all
block return-icmp in log on $ExtIF proto udp all
# allow lo0 interface packet
pass in quick on lo0 all
pass out quick on lo0 all
# allow internal network traffic
pass in on $IntIF from any to <allowhost>
pass out on $IntIF from <allowhost> to any
block in quick log on
$ExtIF from <badhost> to any
#
# block nmap's fingerprinting attempt(FIN, URG, PSH)
block in quick on $ExtIF inet proto tcp from any to any flags FUP/FUP
#
# block MSN(messenger.hotmail.com)
block out log quick proto tcp from any to 207.46.104.20
block out log quick proto tcp from any to any port 1863
# create states
pass out log on $ExtIF inet proto tcp all flags S/SA keep state
pass out log on $ExtIF inet proto {udp, icmp} all keep state
3.2.2 ipfilter 룰셋
ipfilter에서는 다음의 룰을 사용할
것입니다. 내부단에 대한 filtering을 하지 않는다는것과 MSN을 block하지 않는것 외에는 기능적으로 pf의 룰과
비슷합니다. 설정파일의 위치는 /etc/ipf.rules입니다.
#
# Block and log everything by default
#
block
out log on ng0 all
block
in log on ng0 all
block return-rst in log on ng0 proto tcp all
block return-icmp in log on ng0 proto udp all
# pass lo0 interface traffic
#
pass in quick on lo0
pass out quick on lo0
#
# pass fxp1 interface(internal traffic)
pass out quick on fxp1
pass in quick on fxp1
#
# block spoofed address
block in log quick on ng0 from 192.168.0.0/16 to any
block in log quick on ng0 from 172.16.0.0/12 to any
block in log quick on ng0 from 10.0.0.0/8 to any
block in log quick on ng0 from 127.0.0.0/8 to any
block in log quick on ng0 from 0.0.0.0/8 to any
block in log quick on ng0 from 169.254.0.0/16 to any
block in log quick on ng0 from 192.0.2.0/24 to any
block in log quick on ng0 from 204.152.64.0/23 to any
block in log quick on ng0 from 224.0.0.0/3 to any
block in log quick on ng0 from any to 255.255.255.255
#
# allow incoming WWW/FTP/Mail/DNS Services
#
# create states for local hosts
pass out quick on ng0 proto tcp from any to any flags S keep state
pass out quick on ng0 proto udp from any to any keep state
pass out quick on ng0 proto icmp from any to any keep state
만일 내부단에서 서비스를 한다면 해당 서비스에 해당하는 부분을 추가하면 되겠습니다. 예를들어 웹서비스를
한다면 다음과 같은 부분을 추가합니다.
pass in on ng0 proto tcp from any to any port = 80 flags S/SA keep state
NAT는 Switching Hub에
연결된 192.168.1.X를 사용하는 내부단의 모든 시스템에 대해서 수행하도록 합니다. pf와 ipfilter는 유져영역에서
NAT를 수행하는 natd(8)와 달리 커널영역에서 모든 일을 수행합니다. pf는 NAT기능이 하나로 통합되어 있기 때문에
ipfilter와 natd같은 별도의 설정파일이 필요하지 않습니다. ipfilter의 NAT조작은 ipnat(8)에 의해서
수행되고 NAT 설정파일은 /etc/ipnat.rules입니다.
#
# Simple NAT rules for ipfilter
#
map ng0
192.168.1.0/24 -> 0/32
위는 ng0에 대해서 NAT를 수행하며 192.168.1.X의 모든 IP주소를 ng0에 할당된 주소로 변환하도록
합니다. map이 일어나는 interface가 ng0임을 유의하기 바랍니다. pf는 이미 방화벽룰에서 NAT를 지정했습니다.
rc.conf에서 gateway="YES"로 지정한 후 리부트 하지 않았다면 sysctl을 이용해서 OID net.inet.ip.forwarding을 지정했는지 확인합니다. 그리고 ipfilter를 커널모듈로 로드하도록 설정했다면 ipfilter를 먼저 로드하도록 합니다.
pf를 사용할 경우:
#sysctl
net.inet.ip.forwarding=1
#kldload pflog
#kldload pfsync
#ifconfig pflog0 up
#ifconfig pfsync0 up
#/sbin/pflogd
#kldload pf
#pfctl -Fa -e -f /etc/pf.conf
ipfilter를 사용할 경우:
#sysctl
net.inet.ip.forwarding=1
#kldload ipl
#ipf -Fa -FS -f /etc/ipf.rules
#ipnat -CF -f
/etc/ipnat.rules
잘못된 명령이나 입력실수가 있다면
오류가 난 라인번호가 출력되니 필요할 경우 수정하면 됩니다. network이 동작하는지 ping을 이용해서
www.kr.freebsd.org로 ICMP echo request를 전송해 봅니다.
#ping www.kr.freebsd.org
PING daemon.kr.freebsd.org (211.176.62.31): 56 data bytes
64 bytes from 211.176.62.31: icmp_seq=0 ttl=55 time=25.515 ms
64 bytes from 211.176.62.31: icmp_seq=1 ttl=55 time=24.914 ms
64 bytes from 211.176.62.31: icmp_seq=2 ttl=55 time=25.789 ms
64 bytes from 211.176.62.31: icmp_seq=3 ttl=55 time=26.602 ms
64 bytes from 211.176.62.31: icmp_seq=4 ttl=55 time=25.496 ms
^C
--- daemon.kr.freebsd.org ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 24.914/25.663/26.602/0.549 ms
다음으로 방화벽룰에서 지정한 ICMP에대한 state가 만들어 졌는지 pf에서는 "pfctl -ss"로
ipfilter에서는 "ipfstat -t"등으로 확인합니다. ipfilter에서는 NAT가 정상적으로 수행되었는지 확인하기
위해서는 "ipnat -l"을 이용해야 합니다. pf에서는 "pfctl -ss"에서 같이 표시됩니다.
여기 까지 모든것이 제대로 되었다면 커널모드 PPPoE와 방화벽, NAT와의 연동은 성공적입니다.
커널모드 PPPoE 프로그램인
mpd는 현재 rc script에서 공식적으로 지원되지 않습니다. 이 때문에 rc.conf에서 어떤식으로 설정할지는 전적으로
사용자에게 달려있습니다. ipfilter나 ipfw의 경우는 rc script에서 지원하지만 이 경우에도 문제는 있습니다.
mpd를 /etc/rc.local이나 /usr/local/etc/rc.d/mpd.sh등으로 만들어서 실행하기 전 까지는
mpd에서
사용하는 netgraph interface인 ng0가 생성되어 있지 않다는 것입니다. 따라서 rc.conf에서 pf, ipfw나
ipfilter를 사용하려고 하면 ng0가 아직 생성되지 않은 상태이기 때문에 경고메세지가 출력됩니다.
rc script를 대대적으로 수정하지 않고서 이 문제를 원천적으로 해결하기는 어려울 것으로 생각됩니다. 현재로서는
/etc/rc.local이나 /usr/local/etc/rc.d/mpd.sh등에서 mpd 실행 후 방화벽과 NAT룰을 설정하는
것이 최선책으로 보입니다. 또 하나의 문제점은 mpd가 언제 접속이 이루어지는지 하는 문제입니다. mpd를 실행한다고 해서 즉시
접속이 이루어 지는것은 아니고 몇 초 또는 수십초의 시간이 필요합니다. 또한 유동 IP를 사용하기 때문에 언제든지 현재 사용중인
방화벽의
IP가 변경될 수 있습니다. ppp(8)와 마찬가지로 mpd에서도 연결이 된 경우에 실행할 script를 지정할 수 있도록 하고
있습니다. 이를 위해서 mpd.conf에서 주석처리된 부분을 제거하고 mpd.linkup script를 지정하도록 합니다.
...
set ipcp yes
vjcomp
---- (16)
set ipcp ranges 0.0.0.0/0
0.0.0.0/0
---- (17)
set iface up-script
/usr/local/etc/mpd/mpd.linkup
---- (18)
#set iface down-script
/usr/local/etc/mpd/mpd.linkdown ---- (19)
open
iface
---- (20)
mpd.linkup파일은
/usr/local/etc/mpd에 새로 만듭니다. mpd는 interface가 up되면 up-script에서 지정된
mpd.linkup을 다음과 같은식으로 호출합니다.
mpd.linkup interface inet local-ip remote-ip authname
interface는 ng0, ng1등으로 지정됩니다. local-ip는 새로이 할당된 local IP주소이고,
remote-ip는 새로이 할당된 PPP 연결의 상대방 주소입니다. script가 호출될 때 새로이 할당된 local-ip가
argument로 전송되기 때문에 cpp(1)를 이용해서 방화벽 룰에 지정된 variable에 대한 substition도
가능합니다. 우리의 경우 다음과 같은 정도만 있어도 충분합니다.
#!/bin/sh
#
# mpd startup scrip for pf
/sbin/pfctl -Fa -e -f /etc/pf.conf
# mpd startup script for
ipfw
#/bin/sh /etc/ipfw.conf
#kill -HUP
`/usr/bin/sed 1q /var/run/natd.pid`
# mpd startup script for
ipfilter
#/sbin/ipf -Fa -f /etc/ipf.rules
#/sbin/ipnat -CF -f /etc/ipnat.rules
pf가 아닌 ipfw, ipfilter를 사용한다면 해당 부분의 주석을 제거하도록 합니다. rc.local에는 ipfilter또는 ipfw와 연동이 필요하기 때문에 커널에서 방화벽을 지원하지 않도록 했다면 방화벽 커널모듈을 먼저 로드하도록 합니다. pf라면 다음과 같이 할 수 있습니다.
#
# rc.local
#
# kernel mode PPPoE setup
#
# First, load pf kernel module
#
if [ -f
/boot/kernel/pf.ko]; then
/sbin/kldload pflog
/sbin/kldload pfsync
/sbin/ifconfig pflog0 up
/sbin/ifconfig pfsync0 up
/sbin/pflogd
/sbin/kldload pf
echo
'pf module loaded.'
fi
#
# Then, invoke mpd
#
if [ -x /usr/local/sbin/mpd -a -f /usr/local/etc/mpd/mpd.conf ]; then
/sbin/kldload ng_ether
echo -n " mpd";
/usr/local/sbin/mpd -b
fi
ipfilter라면 다음과 같이 할 수 있습니다.
#
# rc.local
#
# kernel mode PPPoE setup
#
# First, load ipfilter if required
#
if ! /sbin/sysctl net.inet.ipf.fr_pass > /dev/null 2>&1; then
if /sbin/kldload ipl; then
echo 'IP-filter module loaded.'
/sbin/ipmon -Ds
else
echo 'Warning: IP-filter module failed to load.'
fi
else
/sbin/ipmon -Ds
fi
#
# Then, invoke mpd
#
if [ -x /usr/local/sbin/mpd -a -f /usr/local/etc/mpd/mpd.conf ]; then
/sbin/kldload ng_ether
echo -n " mpd";
/usr/local/sbin/mpd -b
fi
필요하다면 ipfilter에서 생성한 방화벽과 NAT state를 ipfs를 이용해서 복구하고 저장하는 부분을 추가할 수 도
있습니다. 자세한 방법은 /etc/rc.network을 참조바랍니다.
ipfw를 사용한다면 /etc/rc.local에 다음과 같이 추가 합니다.
#
# rc.local
#
# kernel mode PPPoE setup
#
# First, load ipfw if required
#
if ! /sbin/ipfw -q flush > /dev/null 2>&1; then
if /sbin/kldload ipfw; then
echo 'ipfw module loaded.'
/bin/sh /etc/ipfw.conf
/sbin/natd -f /etc/natd.conf
else
echo 'Warning: ipfw module failed to load.'
fi
fi
#
# Then, invoke mpd
#
if [ -x /usr/local/sbin/mpd -a -f /usr/local/etc/mpd/mpd.conf ]; then
/sbin/kldload ng_ether
echo -n " mpd";
/usr/local/sbin/mpd -b
fi
ipfw(8)에서 사용하는 방화벽룰은 /etc/ipfw.conf에 natd(8)의 룰은 /etc/natd.conf에
있다고 가정하였습니다. ipfilter와 마찬가지로 /etc/rc.network을 참조하여 좀 더 복잡하고 자신이 사용하는
시스템에 맞게 설정할 수 도 있을 것 입니다.
마지막으로 /etc/rc.conf에는 /etc/rc.local에 있는 설정을 이용할 것이기 때문에 ipfiler나
ipfw가 실행되지 않도록 다음과 같이 설정하도록 합니다.
...
defaultrouter="NO"
ifconfig_fxp0=up
ifconfig_fxp1="inet 192.168.1.1 netmask 255.255.255.0"
gateway_enable="YES"
ipfilter_enable="NO"
ipnat_enable="NO"
ipmon_enable="NO"
ipfs_enable="NO"
firewall_enable="NO"
natd_enable="NO"
ppp_enable="NO"
...
모든 설정이 완료되면 시스템을 리부트한 후 필요한 커널모듈이 모두 로드되었는지 network은 정상적으로 되는지
확인합니다.
PPPoE
gateway를 담당하는 FreeBSD에서는 아무런 문제가 없이 network이 동작하는것 처럼 보이는데 IP
192.168.1.X를 사용하는 시스템에서는 접속하는 사이트에 따라서 문제가 발생하는 경우가 있습니다. 이는 Path MTU
문제에 기인하는 것입니다. 두개의 시스템이 서로 다른 여러개의 network을 통하여 연결될 때 두 시스템 사이의 Path
MTU는 서로간의 데이터 link중 가장 작은 MTU에 의해서 결정됩니다. 이 Path MTU 는 고정된 값이 아니고
routing에 의해서 결정되는 path에 달려있습니다. 또한 inbound와 outbound 패킷이 서로 다른 route를
가질
수 있기 때문에 두 시스템간의 Path MTU는 방향에 따라서 다를 수도 있습니다.
Path MTU Discovery는 시스템에서 Path MTU를 결정하기 위해서 사용하는 방법으로 RFC
1191에 명시되어 있습니다. 현재 FreeBSD를 포함한 대부분의 시스템들은 Path MTU Discovery를 수행합니다.
그러나 Path MTU Discovery는 서비스 시스템의 설정과 ISP의 router의 설정에 따라서 동작하지 않을 수
있습니다. Path MTU Discovery는 MSS보다 큰 패킷이 전송되면 IP header의 DF bit가 설정된 ICMP
unreachable(ICMP fragment required)을 전송자에게 보내게 되고 전송자는 이경우 패킷을 보다
작은 크기로 나누어서(fragmentation) 다시 전송하게 됩니다.
만일 ISP의 router가 잘못 설정되거나 또는 방화벽 뒷단에서 안전한 관리를 한다는 목적으로 ICMP를 모두
막아버릴 경우 전송자가 "ICMP unreachable"라는 ICMP 패킷을 받지 못하게 됩니다. 잘못된 설정을 하고 있는
관리자는 이 문제를 알기가 어렵고 PPPoE 사용자의 경우도 접속은 되지만 실제 데이터가 오다가 멈추기 때문에 원인을 알기가
어렵습니다. 이런 문제의 원인은 잘못된 방화벽 설정 또는 router문제인데, ISP의 경우는 모든 protocol을 지원해야
하는 입장이기 때문에 router에서 특정 protocol 을 막는 경우는 찾기 힘듭니다.
현재로는 ICMP protocol은 보안상 위험하고 ping외에는 쓰이지 않는다는 잘못된 지식으로 방화벽에서 모든
ICMP 패킷을 막아버린 보안관리자들의 잘못된 설정이 가장 큰 원인으로 보입니다.
실제로 방화벽이 설치되어 있을것
같은 국정원 홈페이지에 대해서 시험해 보니 PPPoE상에서
MSS문제를 가지고 있었습니다. 국정원 홈페이지에 대한 tcpdump결과는 다음과 같습니다. MSS가 1460로 요청되어 접속이
되지 않습니다.(국정원의 시스템은 fragmentation이 필요하다는 ICMP fragmentation required를 받지
못했습니다.)
#tcpdump -n -i ng0 'tcp[13] & 2 != 0'
tcpdump: listening on ng0
21:58:15.646122 61.82.76.235.49560 > 168.126.27.90.80: S
186429103:186429103(0) win 65535 <mss
1460,nop,wscale1,nop,nop,timestamp 4208156 0> (DF)
21:58:15.671026 168.126.27.90.80 > 61.82.76.235.49560: S
467678666:467678666(0) ack 186429104 win 10136
<nop,nop,timestamp 432712352 4208156,nop,wscale 0,mss 1460> (DF)
이의 해결책으로는 PPPoE Client를 gateway로 사용하는 시스템의 MSS를 강제적으로 더 작게 줄여주는
방법이 있습니다. 그러나 이는 gateway 뒷단의 시스템마다 설정을 다시 해야하고 Windows 시스템들은 종류에 따라서 설정
위치가 다르기 때문에 변경하기가 어려운 문제가 있습니다. FreeBSD의 FAQ에는 설
정하는
방법이 나와 있지만 더 좋은 방법은 PPPoE gateway에서 모든 처리를 자동적으로 하는 것입니다.
최근의 유저모드 ppp(8)에는 "enable tcpmssfixup" 명령이 기본적으로 동작하기 때문에
유저모드 ppp(8)를 사용한다면 이 부분은 해당되지 않지만 유저모드에서 예전 FreeBSD를 사용할 경우에는 ports의
tcpmssd(/usr/ports/net/tcpmssd)를 설치하면 MSS 문제를 해결할 수 있습니다. 현재 mpd의 가장 큰
약점은 이 mssfixup이 제대로 동작하지 않는다는 것입니다.(부분적으로는 동작하는지 모르겠지만 저의 경우는 제대로 동작하지
않았습니다.)
mpd를 이용한 커널모드 PPPoE에서는 내부단의 각 시스템에서 MTU를 강제적으로 제한하거나 pf를 사용한다면
scrub rule에서 mss를 지정해야 합니다. 최근의 ipfilter의 경우에는 mssclamp라는 키워드를 지원하므로 이를
이용해야 합니다. 보다 자세한 Path MTU Discovery에 관한 문제는 다음의 URL또는 W.
Richard Stevens의 TCP/IP Illustrated,Volume I을 참조하기 바랍니다.
최근의 ipfilter에 추가된
mssclamp를 /etc/ipnat.rules에 다음과 같이 지정합니다. pf는 scrub rule에서지정할 수 있습니다.
#
# Simple NAT rules
#
map ng0 192.168.1.0/24
-> 0/32 mssclamp 1440
mssclamp에 사용할 값 1440은 mpd.conf에서 지정한 MTU - 52(1492 - 52)의 값입니다.만일 제대로
동작하지 않는 다면 더 작은 값으로 변경하도록 해 봅니다. 변경이 되면 새로운 NAT룰을 로드합니다.
#ipnat -CF -f /etc/ipnat.rules
성공적으로 NAT룰이 설정되면 PPPoE Client를 gateway로 사용하는 시스템에서 정상적인 접속이 되는지 확인합니다.
국정원 홈페이지에 대한 tcpdump결과는 다음과 같습니다. MSS가 이제는 1440로 요청되어 접속이 제대로 이루어 짐을 알
수 있습니다.
#tcpdump -n -i ng0 'tcp[13] & 2 != 0'
tcpdump: listening on ng0
22:02:09.696309 61.82.76.235.49561 > 168.126.27.90.80: S
3336787163:3336787163(0) win 65535 <mss 1440,nop,wscale
1,nop,nop,timestamp 4231560 0> (DF)
22:02:09.721561 168.126.27.90.80 > 61.82.76.235.49561: S
524121234:524121234(0) ack 3336787164 win 9996 <nop,nop,timestamp
432735758 4231560,nop,wscale 0,mss
1440> (DF)
22:02:10.150193 61.82.76.235.49562 > 168.126.27.90.80: S
2059662856:2059662856(0) win 65535 <mss 1440,nop,wscale
1,nop,nop,timestamp 4231606 0> (DF)
22:02:10.213039 168.126.27.90.80 > 61.82.76.235.49562: S
524251102:524251102(0) ack 2059662857 win 9996 <nop,nop,timestamp
432735804 4231606,nop,wscale 0,mss
1440> (DF)
22:02:10.393746 61.82.76.235.49563 > 168.126.27.90.80: S
2639386047:2639386047(0) win 65535 <mss 1440,nop,wscale
1,nop,nop,timestamp 4231630 0> (DF)
22:02:10.418834 168.126.27.90.80 > 61.82.76.235.49563: S
524475714:524475714(0) ack 2639386048 win 9996 <nop,nop,timestamp
432735828 4231630,nop,wscale 0,mss
1440> (DF)
FreeBSD 5.0에서는 pf와
ALTQ를 사용할 수 있습니다. ADSL은 알려진대로 up-link와 down-link사이의 속도 차이가 많이 납니다. 한국통신
ADSL의 경우 up-link는 64,000bps로 고정되어 있습니다. 대부분의 작업에서 ADSL의 속도는 만족할 만 하지만
upload중 여러개의 download를 시도하면 upload traffic으로 인해서 download 속도가 급격히 감소하는
문제가 발생합니다. 혼자 ADSL 라인을 사용중이라면 별 문제가 아니겠지만 여러대의 시스템이 ADSL로 연결된
시스템을
gateway로사용할 경우 문제가 됩니다. pf에서는 TCP ACK packet에 높은 priority를 주어서
upload중에도
download 속도가 저하되는 것을 막을 수 있습니다. 자세한 설정 방법은 여기를 참조바랍니다.
pf에서는 mutiple
router간의 load balacing을 지원합니다. 만일 여러개의 ADSL라인을 가지고 있을 경우 이를
FreeBSD에서 효과적으로 이용하기에는 불가능했었습니다.(전통적으로 *BSD는 multiple default route를
지원하지 않았습니다.) pf에서는 소스의 address를 random, source-hash, round-robin 식으로
지정하여 효율적인 부하 분산이 가능합니다. 실제 사용법은 여기를
참조하세요.
특정 프로램을 이용하면 상대방의
시스템이 NAT를 사용하고 있는지 공인 IP를 사용하고 있는지 알 수 있습니다. 이 방법은 ISP에서 사용할 수 도 있고
악의적인
사용자가 접속자의 보다 자세한 정보를 알기 위해서 사용할 수도 있습니다. pf에서는 NAT를 탐지를 무력화 시키는
random-id option을 지원합니다.
고가의 상용방화벽에서만 볼 수 있는
기능으로 pf에서 뒷단의 다른 시스템을 대신하여 TCP Threeway Handshaking을 수행한 후 다시 접속을
replay하는 TCP SYN Proxy를 지원합니다. 이 기능은 pf 1.5.1부터 지원됩니다.
mpd는 지속적으로 개선되고 있지만
아직도 많은 부분이 부족한 상태입니다. 특히 HOWTO 형식의 문서부재로 많은 사용자들이 실체도 모르고 있는것은 안타까운
일입니다. mpd를 이용한 커널모드 PPPoE의 성능은 대단한 매력이지만 베이스 시스템에 포함되어 있지않기 때문에 설치시의
문제와
함께 , rc script의 미지원, MSS fixup문제등이 단점으로 생각됩니다.
어떻게 생각하면 "이렇게 복잡하게 커널모드 PPPoE와 pf/ipf/ipfw를 사용해야 하는가?"라는
의문을 가질 수 있습니다. 물론 아닙니다. 대분의 경우 xDSL의 최고 2 - 3 Mbps의 느린 속도는 유저모드 ppp(8)를
사용하는 구형의 시스템에서도 성능상의 문제는 느낄 수 없습니다. 또한 고정 IP를 사용하는 xDSL의 경우에는
커널모드/유저모드/PPPoE 등의 모든 문제를 잊어 버릴 수 있습니다. 다만 고정 IP의 경우 가격이 조금 더 비싼 단점이
있고,
ISP에서 설정된 bandwidth가 유동 IP에 비해서 더 낮게 설정되어 있습니다. 제가 이런 복잡한 일련의 설정을 한 이유는
전용 하드웨어 공유기에 비해서 FreeBSD시스템은 저렴한 가격으로 복잡하고 다양한 일을 할 수 있기 때문에, PPPoE의
지원으로 인해서 불필요한 시스템의 자원을 낭비하지 않는것이 다른 서비스를 효율적으로 하는데 바람직 하다고 생각하기 때문입니다.
mpd를 사용하면서 발생하는 문제나 pf와의 연동시 문제가 있는 분들은 <questions at kr.freebsd.org>로 문의하기 바랍니다.
W. Richard Stevens TCP/IP
Illustrated, Volume I, II
FreeBSD
Handbook의 PPPoE
OpenBSD pf Home Page
mpd Home Page
OpenBSD pf FAQ
ipfilter HOWTO
$Id: pppoe.html,v 1.2 2003-07-05 12:08:29+09 yongari Exp $