tail head cat sleep
QR code linking to this page

Man page  — IPFW

명칭

ipfw – IP 파이어 월(fire wall)와 트라픽크시이파의 제어 프로그램

내용

서식


ipfw [-cq] add rule
ipfw [-acdeftNS] { list | show} [number ...]
ipfw [-f | -q] flush
ipfw [-q] { delete | zero | resetlog} [ set] [number ...]


ipfw set [ disable number ... ][ enable number ...]
ipfw set move [ rule] number to number
ipfw set swap number number
ipfw set show


ipfw { pipe | queue} number config config-options
ipfw [-s [field]] { pipe | queue} { delete | list | show} [number ...]


ipfw [-q] [ -p preproc [-D macro[=value] ] [-U macro] ] pathname

해설

ipfw (와)과 그 유틸리티는 FreeBSD 의 ipfw(4) [영어] 파이어 월(fire wall)와 dummynet(4) 트라픽크시이파를 제어하는 유저 인터페이스입니다.

주: 이 메뉴얼 페이지는 2002 년 7 월에 도입되고 ipfw2 (으)로서도 알려져 있다 ipfw 의 신버젼을 참조하고 있습니다. 여기에 나타내는 명령의 리스트는 구판의 파이어 월(fire wall)의 슈퍼 세트입니다. 양자를 구별할 필요가 있을 때는 구판을 ipfw1 (이)라고 부르기로 하겠습니다.

ipfw2 하 FreeBSD CURRENT 의 표준입니다만, FreeBSD STABLE 에서는, options IPFW2 (을)를 붙여 커널을 컴파일 해, -DIPFW2 (을)를 붙여 /sbin/ipfw (와)과 /usr/lib/libalias (을)를 재컴파일 해 재인스톨 ( buildworld 의 전에 IPFW2=TRUE (을)를 /etc/make.conf 에 추가하면(자) 같은 결과가 됩니다 ) 하지 않으면 지금도 ipfw1 (을)를 사용합니다.

ipfw1 에 존재하지 않는 기능의 일람은 IPFW2 확장 섹션을 참조해 주세요.

ipfw 의 설정, 혹은 룰 세트 (은)는, 1 에서 65535 까지의 번호를 붙여졌다 의 리스트로부터 됩니다. 패킷은 프로토콜 스택의 많은 다른 개소에서 ipfw 에게 건네집니다 (패킷의 발신기지와 행선지에 의존해, ipfw (은)는 같은 패킷에 대해서 여러 차례 기동 당할 가능성이 있습니다). 파이어 월(fire wall)에게 건네지는 패킷은 파이어 월(fire wall)의 룰 세트 에 쓰여진 각 룰에 대해서 조합됩니다.

일치했을 경우, 일치한 룰에 대응하는 액션이 실행됩니다. 액션과 실제의 시스템의 설정에 따라서는, 매치 한 룰의 뒤의 룰로 한층 더 처리를 실시하기 위해서(때문에) 패킷이 파이어 월(fire wall)에 재주입되는 일이 있습니다.

ipfw 룰 세트에는 항상 디폴트 룰 (번호 65535)이 포함됩니다. 이 룰은 변경하지 못하고, 전패킷에 매치 합니다. 디폴트 룰에 관련지을 수 있는 액션은 deny 인가 allow 의 어딘가에 됩니다만, 이것은 어떻게 커널을 설정했는지를 의존합니다.

룰 세트가 keep-state 또는 limit 의 옵션 첨부의 룰을 포함한 경우, ipfw 스테이트 풀 (상태 의존형) 그리고 동작합니다. 즉, 어느 매치의 결과, 매치 한 패킷의 파라미터에 정확히 일치하는 룰이 동적으로 생성됩니다.

이러한 동적 룰의 생존 시간은 유한해, check-state 또는 keep-state 또는 limit 룰이 최초로 생긴 장소에서 체크됩니다. 동적 룰은, 정당한 트래픽을 On Demand로 파이어 월(fire wall)를 통과시키기 위해서(때문에) 이용하는 것이 보통입니다. ipfw 의 스테이트 풀인 동작에 대해 더욱 정보가 필요하면, 이하의 스테이트 풀 파이어 월(fire wall) 섹션과 사용예 섹션을 참조해 주세요.

모든 룰(동적 룰을 포함한다)은, 관련하는 카운터를 몇개인가 가지고 있습니다: 패킷 카운트, 바이트 카운트, 로그 카운트, 마지막에 매치 했을 때 각을 나타내는 타임 스탬프. 카운터는, ipfw 명령에 의해 표시할 수가 있어 또 리셋트 할 수가 있습니다.

룰의 추가는 add 명령에서 가능합니다. 개별, 또는 그룹에서의 룰의 삭제는 delete 명령에서 가능하고, 모든 룰의 삭제는 flush 명령에서 가능합니다. 룰의 표시 (옵션으로 카운터 내용을 포함할 수가 있습니다) (은)는, show 명령 및 list 명령에서 가능합니다. 마지막으로, 카운터의 리셋트는 zero 명령 및 resetlog 명령에서 가능합니다.

또, 각 룰은 32 의 다르다 세트 의 1 개(살)에 소속해, 세트에 대한 아토믹인 조작, 예를 들면 유효화·무효화·세트의 교체·세트내의 전룰을 다른 세트에 이동· 세트내의 전룰의 삭제 등을 행하기 위한 ipfw 명령이 있습니다. 이것들은 일시적인 설정을 인스톨 하거나 설정의 테스트를 실시하거나 할 경우에 편리합니다. 세트 에 관한 자세한 것은 섹션 룰 세트 (을)를 참조해 주세요.

다음의 옵션이 이용 가능합니다:
-a
  룰의 리스트를 표시할 때에, 카운터치를 나타냅니다. show 명령은, 이 옵션을 암묵적으로 지정했을 뿐의 것입니다.
-c
  룰을 입력하거나 참조하거나 할 경우에, 컴팩트한 서식에서 룰을 표시합니다. 즉, 룰이 무슨 추가 정보도 가지지 않을 때는, 옵셔널인 캐릭터 라인 "ip from any to any" 를 표시하지 않습니다.
-d
  룰의 리스트를 표시할 때에, 정적 룰에 가세해 동적 룰도 표시합니다.
-e
  룰의 리스트를 표시할 때에, 만약 -d 옵션이 지정되어 있으면, 기한 마감의 동적 룰도 표시합니다.
-f
  잘못해 사용하면(자) 문제를 일으킬 가능성이 있는 명령, 즉 flush 에 대해서, 실행의 확인을 실시하지 않습니다. 프로세스에 관련지을 수 있었던 tty 가 없는 경우, 이 옵션이 암묵중으로 지정되었다고 해서 처리됩니다.
-N
  출력에 포함되는 주소와 서비스명의 이름 해석을 시도합니다.
-q
  add, zero, resetlog, flush (을)를 실행할 때, 동작에 대해 보고하지 않습니다 (암묵중에 -f 하지만 지정됩니다). 스크립트 (예를 들면 ‘sh /etc/rc.firewall’) 중(안)에서 복수의 ipfw 명령을 실행해 룰을 변경하는 경우나, 리모트 로그인 세션 경유로 다수의 ipfw 룰을 포함한 파일을 처리하는 것으로써 룰을 변경하는 경우에 유용합니다. 통상 (장황) 모드로 (디폴트 커널 설정으로) flush 를 실시했을 경우, 메세지를 표시합니다. 모든 룰을 버려지기 때문에, 메세지는 로그인 세션에 건네줄 수 없습니다. 즉, 리모트 로그인 세션 경유의 경우, 세션은 클로우즈 되어 나머지의 룰 세트는 처리되지 않습니다. 이 상태로부터 회복하기 위해서는 콘솔에의 액세스가 필요하게 됩니다.
-S
  룰의 리스트를 표시할 때에, 각 룰이 속한다 세트 (을)를 표시합니다. 이 플래그가 지정되어 있지 않으면, 무효화되고 있는 룰은 표시되지 않습니다.
-s [field]
  파이프 경유로 리스트 출력하고 있을 때에, 4 개의 카운터의 1 개에 대해 정렬시킵니다 (현재의 패킷수).
-t
  룰의 리스트를 표시할 때에, 마지막에 매치 한 타임 스탬프를 표시합니다.

모두의 서식의 행으로 가리킨 것처럼, 설정을 간단하게 하기 위한(해), 룰을 ipfw 에 처리시키는 파일에 기술할 수가 있습니다. pathname 에는 절대 패스명을 사용할 필요가 있습니다. 이 파일로부터는 1 행씩 읽혀 ipfw 유틸리티의 인수로서 받아들일 수 있습니다.

-p preproc (을)를 사용해, pathname 하지만 파이프 되는 프리프로세서를 지정할 수도 있습니다. 유용한 프리프로세서에는, cpp(1) [영어] (와)과 m4(1) (이)가 있습니다. preproc 의 최초의 캐릭터가 slash (‘/’) (으)로부터 시작되지 않는 경우, PATH (을)를 사용한 통상의 이름 검색을 합니다. ipfw 하지만 실행될 때까지 전파일 시스템이 ( 아직) mount 되지 않는 것 같은 환경 (예를 들면 NFS 경유로 mount 되는 경우)에서는, 이것에 주의해 주세요. 한번 -p 하지만 지정되면(자), 옵션으로서 -D (와)과 -U 의 지정을 계속하는 것이 가능해져, 이것들이 프리프로세서에게 건네집니다. 이것에 의해, (로컬 호스트명에 의해 조건부하는 등) 유연성이 있는 설정 파일을 작성 가능해져, IP 주소와 같이 빈번하게 필요한 인수를 집중관리하기 위한 매크로를 사용 가능해집니다.

후술의 트라픽크시이파 설정 섹션으로 가리키도록(듯이), ipfw pipe queue 명령을 사용해, 트라픽크시이파를 구축 가능합니다.

패킷 플로우(flow)

시스템 파라미터의 제어에 의해, ipfw (은)는 프로토콜 스택안의 복수의 개소로부터 실행됩니다. 적절한 룰 세트를 설계하려면 , 이 현상을 이해하는 것이 중요합니다. ipfw 하지만 실행되는 개소는, 그 실행을 제어하는 sysctl 변수와 함께 이하로 거론되고 있습니다.
      ^     to upper layers   V
      |                       |
      +----------->-----------+
      ^                       V
 [ip_input]              [ip_output]   net.inet.ip.fw.enable=1
      |                       |
      ^                       V
[ether_demux]    [ether_output_frame]  net.link.ether.ipfw=1
      |                       |
      +-->--[bdg_forward]-->--+        net.link.ether.bridge_ipfw=1
      ^                       V
      |      to devices       |

윗 그림에 나타나도록(듯이), 동일한 패킷이 파이어 월(fire wall)를 통과하는 회수는, 패킷의 발신기지나 행선지, 시스템의 설정에 의해, 0 회부터 4 회의 범위에서 변동합니다. 이러한 각처에서, 그 레벨에 속하는 모든(그리고 유일한) 필드와 함께, 패킷은 ipfw 에게 건네집니다. 즉, 밖으로부터 들어 오는 패킷은 ether_demux() (으)로부터 ipfw 하지만 실행될 때는 MAC 헤더를 포함하고 있을 것입니다만, 그 같은 패킷이, ip_input() (으)로부터 ipfw 하지만 실행되었을 때에는 MAC 헤더는 제거되고 있을 것입니다.
ipfw 하지만 실행된 장소나, 패킷의 소스에 관련되어 없고, 완전한 룰 세트가 항상 사용됩니다. 실행된 개소에 따라서는 무효가 되는 것 같은 매치 패턴이나 액션 (예를 들면, ip_input() (으)로부터 ipfw 하지만 불려 갔을 때에 MAC 헤더와 매치을 시도하는 것 같은 것) (을)를 룰이 포함하고 있다면, 그 패턴은 매치 하지 않게 됩니다. 그렇다고는 해도, 그러한 패턴의 전에 not 오퍼레이터를 기술하면, 패턴은 항상 그러한 패킷에 매치 하게 되어, 바람직하지 않은 결과가 되겠지요. 따라서, 필요하면, 가능성이 있는 개소 중(안)에서 식별하도록(듯이), 적절한 룰 세트를 기술하는 것은 프로그래머의 책임입니다. 거기서 skipto 룰이 도움이 되겠지요. 예를 들면 다음과 같이 합니다:

# ether_demux 또는 bdg_forward 로부터의 패킷
ipfw add 10 skipto 1000 all from any to any layer2 in
# ip_input 로부터의 패킷
ipfw add 10 skipto 2000 all from any to any not layer2 in
# ip_output 로부터의 패킷
ipfw add 10 skipto 3000 all from any to any not layer2 out
# ether_output_frame 로부터의 패킷
ipfw add 10 skipto 4000 all from any to any layer2 out

(그렇습니다, 현재 ether_demux 와 bdg_forward 를 구별하는 방법은 없습니다).

룰 서식

ipfw 의 서식은 다음과 같습니다: [rule_number] [ set set_number] [ prob match_probability]
action [ log [ logamount number]] body

여기서, 룰의 보디는 다음과 같이, 패킷을 필터 하는데 어느 정보를 사용하는지를 지정합니다:

레이어 2 헤더 필드 가능하면
IPv4 프로토콜 TCP, UDP, ICMP 등
송신원 및 행선지의 주소와 포트
방향
  섹션 패킷 플로우(flow) (을)를 참조해 주세요
송신 및 수신 인터페이스 이름 또는 주소
그 외의 IP 헤더 필드 버젼, 서비스 타입, 데이터 그램장, 식별자, fragment 플래그 (0 이 아닌 IP 오프셋(offset)), 생존 시간
IP 옵션
그 외의 TCP 헤더 필드
  TCP 플래그 (SYN, FIN, ACK, RST 등), 순차 순서 번호, 확인 응답 번호, 윈도우
TCP 옵션
ICMP 타입
  ICMP 패킷의 경우
유저/그룹 ID 패킷을 로컬 소켓에 관련 짓는 것이 가능한 경우

상기의 정보, 예를 들면, 송신원 MAC 주소 또는 IP 주소와 TCP/UDP 포트 (은)는 용이하게 사칭이 가능한 것으로 주의해 주세요. 따라서, 이러한 필드만으로 필터 하는 것은 반드시 바람직한 결과는 되지 않습니다.
rule_number
  각 룰은, 1 에서 65535 의 범위의 rule_number 에 관련 지을 수 있고 있어 후자는 디폴트 룰을 위해서(때문에) 예약되고 있습니다. 룰은 룰 번호의 순서에 체크됩니다. 복수의 룰이 동일한 번호를 가지는 것이 가능해, 그 경우는 추가된 순서로 체크됩니다 (표시하는 경우도 같습니다) . 번호의 지정없이 룰이 입력되었을 경우, 커널은, 그 룰이 디폴트 룰보다 전에 있는 룰 중(안)에서 마지막에 되도록(듯이) 할당합니다. 자동적으로 붙여지는 룰 번호는, 디폴트를 제외한 중에서 최후가 되는 룰 번호를, sysctl 변수 net.inet.ip.fw.autoinc_step 의 값만 증가시켜 할당할 수 있습니다. 이 변수의 디폴트는 100 입니다. 만약, 이 조작이 (예를 들면 허가된 최대 룰 번호를 넘는다고 하는 이유로) 불가능하면, 마지막 디폴트가 아닌 값과 같은 번호가 대신에 사용됩니다.
set set_number
  각 룰은 0 에서 31 의 범위의 set_number 에 관련 지을 수 있고 있어 후자는 디폴트 룰을 위해서(때문에) 예약되고 있습니다. 세트는 개별적으로 무효화하거나 유효화하거나 할 수가 있습니다. 따라서, 이 파라미터는 아토믹인 룰 세트 조작을 실시하기 위해서(때문에) 필요 불가결한 것입니다. 룰 세트를 단순하게 삭제하는 일도 가능합니다. 세트 번호를 지정하지 않고 룰이 입력되었을 경우, 세트 0 이 사용됩니다.
prob match_probability
  지정한 확률 (0 에서 1 까지의 부동 소수점수(실수)입니다) 그리고 밖에 매치 하지 않는 성냥이 선언됩니다. 랜덤에 패킷을 떨어뜨리고 충분하는 것 같은 많은 어플리케이션이나, ( dummynet(4) (와)과 함께 사용해) 패킷 도달 순서의 혼란을 일으키는 복수 경로의 효과를 시뮬레이트 할 때에 유용합니다.
log [ logamount number]
  패킷이 log 키워드를 가진 룰에 매치 했을 경우, 메세지가 syslogd(8) LOG_SECURITY 퍼실리티로 기록됩니다. sysctl 변수 net.inet.ip.fw.verbose 하지만 1 (커널이 IPFIREWALL_VERBOSE 그리고 컴파일 되고 있으면 이것이 디폴트입니다) (으)로 설정되어 있어 그 룰에 대해 지금까지 기록된 패킷의 수가 그 logamount 파라미터를 넘지 않으면, 기록을 합니다. logamount 하지만 지정되어 있지 않으면, 제한은 sysctl 변수 net.inet.ip.fw.verbose_limit (으)로부터 참조됩니다. 양자의 값이 0 이면 기록의 제한은 제거됩니다.

한 번 제한에 이르렀다면, 이 엔트리에 대한 로깅카운타나 패킷 카운터를 클리어 하면 기록을 다시 유효하게 할 수가 있습니다. resetlog 명령을 참조해 주세요.

룰 액션

룰은 다음에 나타내는 액션의 1 개로 관련 지을 수가 있습니다. 이것은 패킷이 룰의 보디에 매치 했을 때에 실행됩니다.
allow | accept | pass | permit
  룰에 매치 하는 패킷을 받아들입니다. 검색은 종료합니다.
check-state
  동적 룰 세트에 대해서 패킷의 체크를 행합니다. 매치 했을 경우, 그 동적 룰을 생성한 룰에 관련 지을 수 있었던 액션을 실행해, 매치 하지 않았던 경우, 다음의 룰로 옮깁니다.
check-state 룰은 보디를 가지지 않습니다. check-state 룰이 발견되지 않을 때는, 동적 룰 세트는 최초의 keep-state 룰, 혹은 limit 룰의 장소에서 체크됩니다.
count 룰에 매치 한 모든 패킷의 카운터를 갱신합니다. 검색은 다음의 룰에 속행합니다.
deny | drop
  룰에 매치 한 모든 패킷을 파기합니다. 검색은 종료합니다.
divert port
  룰에 매치 하는 패킷을 포트 port 에 바인드 되고 있다 divert(4) 소켓에 송출합니다. 검색은 종료합니다.
fwd | forward ipaddr[,port]
  매치 한 패킷의 다음의 호프를 ipaddr (으)로 변경합니다. 이것에는 4개의 숫자를 닷으로 단락지은 IP 주소 또는 호스트명을 사용할 수 있습니다. 이 룰에 매치 했을 경우, 검색은 종료합니다.

ipaddr 하지만 로컬 주소의 경우, 매치 한 패킷은 로컬 머신의 port (또는, 룰로 지정되어 있지 않은 경우는 그 패킷의 포트 번호) 에 전송 됩니다.
ipaddr 하지만 로컬 주소가 아닌 경우, 포트 번호는 (지정되어 있어도) 무시되어 패킷은 로컬인 경로 테이블에 존재하는 그 IP 에 대한 경로를 사용해 리모트 주소에 전송 됩니다.
fwd 룰은 레이어 2 패킷 (그것들은 ether_input, ether_output, bridged 로 수신됩니다) 에는 매치 하지 않습니다.
fwd 액션은 패킷의 내용을 전혀 변경하지 않습니다. 실제, 행선지 주소가 수정되지 않고 남으므로, 전송처 시스템이 그러한 패킷을 수중에 넣는 룰을 가지지 않는 이상 해당 패킷은 통상 그 시스템이 거부합니다. 로컬로 전송 되는 패킷을 위해서(때문에), 소켓의 로컬 주소는 패킷의 원래의 행선지 주소로 설정됩니다. 이것에 의해 netstat(1) 엔트리는 오히려 기묘한 보이는 방법이 됩니다만, 이것은 투과 프록시 서버에서의 사용을 의도하고 있습니다.

pipe pipe_nr
  패킷을 dummynet(4) "파이프" (밴드폭 제한, 지연 등에 사용됩니다) 에 건네줍니다. 자세한 정보에 대해서는 트라픽크시이파 설정 섹션을 참조해 주세요. 검색은 종료합니다. 그러나, 파이프로부터 빠졌을 때에 sysctl(8) 변수 net.inet.ip.fw.one_pass 하지만 세트되어 있지 않은 경우, 패킷은 파이어 월(fire wall) 코드에 재차 건네받아 다음의 룰로부터 개시합니다.
queue queue_nr
  패킷을 dummynet(4) "큐" (WF2Q 를 사용한 밴드폭 제한으로 사용됩니다) 에 건네줍니다.
reject
  (가치가 저하하고 있습니다). unreach host (와)과 동의입니다.
reset 이 룰에 매치 한 패킷을 파기합니다. 게다가 그 패킷이 TCP 패킷이면, TCP 리셋트 (RST) 통지를 송출하려고 시도합니다. 검색은 종료합니다.
skipto number
  number 보다 작은 번호의 룰을 뛰어넘어, number 이상의 번호의 룰로 최초로 존재하는 것으로부터, 검색을 계속합니다.
tee port
  이 룰에 매치 한 패킷의 복제를, 포트 port 에 바인드 되었다 divert(4) 소켓에 송출합니다. 검색은 종료해, 원의 패킷은 받아들일 수 있습니다 (다만, 이하의 섹션 버그 (을)를 참조해 주세요).
unreach code
  이 룰에 매치 한 패킷을 파기해, 코드 code 의 ICMP 도달 불가 통지를 송출하려고 시도합니다. 여기서 code (은)는 0 에서 255 의 숫자, 또는 다음의 앨리어스(alias)의 머지않아인가입니다: net, host, protocol, port, needfrag, srcfail, net-unknown, host-unknown, isolated, net-prohib, host-prohib, tosnet, toshost, filter-prohib, host-precedence, precedence-cutoff 검색은 종료합니다.

룰 보디

룰의 보디는 0 이상의 패턴 (송신원과 행선지 주소나 포트의 지정, 프로토콜 옵션, 수신 또는 송신 인터페이스의 지정 등) (으)로부터 완성됩니다. 패킷은 해석되는 순으로 매치 하지 않으면 안됩니다. 통상, 패턴은 (암묵적으로) and 오퍼레이터로 접속됩니다 -- 즉, 룰이 매치 하기 위해서는 모두가 매치 하지 않으면 안됩니다. 개개의 패턴에는, 매치의 결과를 반전시키기 위해서(때문에) not 오퍼레이터를 전치 할 수가 있습니다. 이것은 다음과 같이 됩니다.

    ipfw add 100 allow ip from not 1.2. 3.4 to any

게다가 다음과 같이 or 오퍼레이터를 사용해, 환괄호 ()나 brace {} 로 괄내부에 패턴을 열거하는 것으로, 새로운 매치 패턴세트 ( 논리합 블록 )(을)를 구축할 수가 있습니다:

    ipfw add 100 allow ip from { x or not y or z } to any

괄호의 레벨은 1 개만이 가능합니다. 대부분의 쉘이 환괄호나 brace에 특별한 의미를 갖게하고 있는 것에 주의해 주세요. 따라서, 그러한 해석이 일어나지 않게 backslash \ 를 그 전에 두는 것을 권합니다.

룰의 보디는, 통상은 송신원과 행선지 주소의 지정을 포함하지 않으면 안됩니다. 키워드 any (은)는 필수 필드의 내용이 중요하지 않은 것을 지정하기 위해서 여러가지 개소에서 사용할 수가 있습니다.

룰 보디는 이하의 서식: [proto from src to dst] [options]

최초의 부분 (protocol from src to dst)은 ipfw1 (와)과의 후방 호환을 위해서(때문에) 있습니다. ipfw2 그럼, 임의의 매치 패턴 (MAC 헤더, IPv4 프로토콜, 주소, 포트를 포함한다) 하지만 options 섹션으로 지정할 수 있습니다.

룰 필드는 이하의 의미입니다:
proto : protocol | { protocol or ... }
  IPv4 프로토콜 (또는 복수의 프로토콜로부터 된다 논리합 블록 ) (은)는 숫자나 이름으로 지정됩니다 (완전한 리스트는 /etc/protocols (을)를 참조해 주세요). ip 또는 all 의 키워드를 사용하면(자), 모든 프로토콜이 매치 합니다.
srcdst : ip-address | { ip-address or ... } [ports]
  단일의 ip-address (이)나, 1 개(살) 이상의 주소를 포함한다 논리합 블록 (은)는, 후에 이어 ports 지시자를 옵션으로 둘 수가 있습니다.
ip-address:
  다음의 방법 (옵션으로 not 오퍼레이터를 전치 할 수가 있습니다) 의 어느쪽이든으로 지정된 주소 (또는 주소세트):
any 임의의 IP 주소에 매치 합니다.
me 시스템의 인터페이스로 설정된 임의의 IP 주소에 매치 합니다. 주소의 리스트는 패킷이 해석될 때 평가됩니다.
numeric-ip | hostname
  닷으로 단락지은 4 개의 숫자 또는 호스트명으로 지정한, 1 개의 IPv4 주소에 매치 합니다. 호스트명은 그 룰이 파이어 월(fire wall)의 리스트에 추가될 때 이름 해석을 합니다.
addr/masklen
  베이스가 된다 addr (닷으로 단락지은 4개의 숫자 또는 호스트명으로 지정됩니다) (와)과 masklen 비트폭의 마스크 에 일치하는 모든 주소에 매치 합니다. 예를 들면, 1.2. 3.4/25 는 1.2. 3.0 에서 1.2. 3.127 까지의 모든 IP 주소에 매치 하게 됩니다.
addr/masklen {num, num,... }
  베이스 주소가 addr (닷으로 단락지은 4개의 숫자 또는 호스트명으로 지정됩니다) (이어)여, 마지막 바이트가 brace {} 안에 열거되고 있다 모든 주소에 매치 합니다. brace, 콤마, 숫자의 사이에는 공백을 두어선 안 되는 것에 주의해 주세요. masklen 필드는 주소세트의 사이즈에 제한을 붙이기 위해서(때문에) 사용되어 24 에서 32 의 사이의 임의의 값을 받을 수가 있습니다.
예를 들면, 주소가 1.2. 3.4/24{128,35,55,89} 로서 지정되었을 경우, 다음의 주소가 매치 합니다:
1.2. 3.128 1.2. 3.35 1.2. 3.55 1.2. 3.89
이 서식은 1 살의 룰로 드문드문한 주소군을 취급할 때 특히 편리합니다. 매치이 비트 마스크를 사용해 행해지므로, 걸리는 시간은 일정으로, 룰 세트의 복잡함이 극적으로 감소합니다.
ports : [ not ]{port | port-port}[,...]
  포트 번호를 서포트하고 있는 프로토콜 (TCP 나 UDP 등)을 위해서(때문에), 옵션의 ports (은)는, 1 개(살) 이상의 포트 또는 포토의 범위를 공백 없음의 콤마 단락으로, 한층 더 옵션의 not 오퍼레이터를 부가해, 지정할 수가 있습니다. 기호 ‘-’ 에 의한 표현은, 포트 범위 (양단 포함한다)를 지정합니다.

포트 번호 대신에 (파일 /etc/services (으)로부터 취한) 서비스명을 사용할 수 있습니다. 포트 리스트의 길이는 30 포토 또는 포토 범위에 제한되고 있습니다만, 룰의 options 섹션으로 논리합 블록 (을)를 사용하면(자)보다 넓은 범위를 지정할 수가 있습니다. backslash (‘\’) (을)를 사용하는 것으로써, 서비스 명중의 (‘-’) 캐릭터를 이스케이프 가능합니다 (쉘로부터 입력할 때, backslash는 쉘 자신에게 이스케이프 캐릭터로서 사용되는 것을 막기 위해서(때문에) 2 회 타이프 치지 않으면 안됩니다).

    ipfw add count tcp from any ftp\\-data-ftp to any

단편화 된 패킷으로 오프셋(offset)가 비 0 의 것 (즉, 최초의 단편은 아닌 걸)(은)는, 1 개(살) 이상의 포트 지정을 가지는 룰에는 매치 하지 않습니다. 단편화 된 패킷에의 매칭에 관한 자세한 것은 frag 옵션을 참조해 주세요.

룰 옵션 (매치 패턴)

룰내에서 추가의 매치 패턴을 사용할 수가 있습니다. 이것들은 룰내에 0 이상 둘 수 있으므로 옵션 (으)로 불리고 있어 옵션으로 not 오퍼랜드를 전치 할 수가 있어 논리합 블록 (으)로 그룹화 하는 것이 가능합니다.

이하의 매치 패턴을 사용할 수 있습니다 (알파벳순서에 늘어놓고 있습니다):
bridged
  브릿지 되는 패킷에게만 매치 합니다.
dst-ip ip address
  행선지 IP 주소가 인수로 지정한 주소의 1 개이다 IP 패킷에 매치 합니다.
dst-port source ports
  행선지 포트가 인수로 지정한 포토의 1 개이다 IP 패킷에 매치 합니다.
established
  RST 나 ACK 비트가 세트 되고 있는 TCP 패킷에 매치 합니다.
frag IP 데이터 그램의 fragment이며, 한편, 최초의 fragment가 아니다 패킷에 매치 합니다. 이러한 패킷은 다음의 프로토콜 헤더 (예를 들면 TCP, UDP)를 가지지 않기 때문에, 이러한 헤더를 조사하는 옵션은 매치 하지 못하는 것에 주의해 주세요.
gid group
  group 에 의해 송신된, 또는 그에 대한 수신되었다 모든 TCP 혹은 UDP 패킷에 매치 합니다. group (은)는 이름이나 수치로 지정할 수가 있습니다.
icmptypes types
  ICMP 타입이 types 그리고 지정된 리스트중에 존재하는 ICMP 패킷에 매치 합니다. 리스트는 범위 지정에서도, 타입 각각을 콤마로 단락지은 것이라도 어느 쪽의 편성에서도 괜찮습니다. 서포트되고 있는 ICMP 타입은 다음과 같습니다:

에코 응답 ( 0), 행선지 도달 불가 ( 3), 발신기지 억제 ( 4), 리디렉트 ( 5), 에코 요구 ( 8), 라우터 광고 ( 9), 라우터 요청 ( 10), 시간 초과 ( 11), IP 헤더 이상 ( 12), 타임 스탬프 요구 ( 13), 타임 스탬프 응답 ( 14), 인포메이션 요구 ( 15), 인포메이션 대답 ( 16), address mask 요구 ( 17), address mask 응답 ( 18)

in | out
  각각 도착 또는 송출 패킷에 매치 합니다. in (와)과 out (은)는 서로 배타적입니다 (실제, out not in (으)로서 실장되고 있습니다).
ipid id
  ip_id 필드가 값 id 인 IP 패킷에 매치 합니다.
iplen len
  헤더와 데이터를 포함한 전체의 길이가 len 바이트인 IP 패킷에 매치 합니다.
ipoptions spec
  IP 헤더가 spec 그리고 지정된 콤마 단락의 옵션 리스트를 포함한다 패킷에 매치 합니다. IP 옵션은 다음의 것이 서포트되고 있습니다:

ssrr (스트릭트 소스 루팅), lsrr (루즈 소스 루팅), rr (레코드 루트), ts (타임 스탬프). ‘!’ (을)를 두는 것으로 특정의 옵션이 존재하지 않는다고 하는 기술을 할 수 있습니다.

ipprecedence precedence
  선행 필드가 precedence 에 동일한 IP 패킷에 매치 합니다.
iptos spec
  tos 필드가 spec 그리고 지정된 콤마 단락의 서비스 타입의 리스트를 포함한다 IP 패킷에 매치 합니다. 서포트되고 있는 서비스의 IP 타입은 다음과 같습니다:

lowdelay ( IPTOS_LOWDELAY), throughput ( IPTOS_THROUGHPUT), reliability ( IPTOS_RELIABILITY), mincost ( IPTOS_MINCOST), congestion ( IPTOS_CE) ‘!’ (을)를 두는 것으로 특정의 옵션이 존재하지 않는다고 하는 기술을 할 수 있습니다.

ipttl ttl
  생존 시간이 ttl 인 IP 패킷에 매치 합니다.
ipversion ver
  IP 버젼 필드가 ver 인 IP 패킷에 매치 합니다.
keep-state
  매치 할 때에, 파이어 월(fire wall)는 동적 룰을 작성합니다. 작성되는 룰은, 디폴트에서는, 같은 프로토콜을 사용하고 있다 발신기지와 행선지 IP/포트간에서의 쌍방향의 트래픽에 매치 하는 것 같은 동작이 됩니다. 이 룰에는 제한된 생존 시간 ( sysctl(8) 변수세트로 제어됩니다) (이)가 있어, 생존 시간은 매치 하는 패킷이 발견될 때마다 리프레쉬 됩니다.
layer2
  레이어 2 의 패킷에만 매치 합니다. 즉, ether_demux()와 ether_output_frame()로부터 ipfw 에 건네받는 패킷입니다.
limit { src-addr | src-port | dst-addr | dst-port }N
  파이어 월(fire wall)는, 룰로 지정한 동일한 파라미터세트에 대해서 N 개의 접속만을 허가합니다. 1 개(살) 이상의 발신기지와 행선지 주소 및 포트를 지정할 수 있습니다.
{ MAC | mac } dst-mac src-mac
  주어졌다 dst-mac 주소와 src-mac 주소를 가지는 패킷에 매치 합니다. 주소에는 any 키워드 (임의의 MAC 주소에 매치 합니다) 또는 코론으로 단락지은 16 진수 6 개의 짜, 다음에 나타내는 것 같은 옵션으로 그 후에 의미가 있는 비트수를 지정하는 마스크 (을)를 지정합니다.

    MAC 10:20:30:40:50:60/33 any

MAC 주소의 순서 (행선지가 최초로 2 번째에 발신기지)는 물리적인 선상의 것과 같습니다만, IP 주소로 사용되는 것과는 반대인 것에 주의해 주세요.

mac-type mac-type
  이더넷(ethernet)의 타입 필드가 인수로 지정했지만 1 개(살)로 일치한다 패킷에 매치 합니다. mac-type port numbers (와)과 같은 방법으로 지정합니다 (즉, 1 개(살) 이상의 콤마 단락의 단일의 값 또는 범위입니다). vlan, ipv4, ipv6 (와)과 같은 기존의 값에 대한 상징적인 명칭을 사용할 수가 있습니다. 값은 10 진수나 16 진수 (0x 가 카시라에 도착하는 경우)로 입력할 수가 있어 항상 16 진수로 출력됩니다 ( -N 옵션이 사용되어 있지 않은 경우입니다. 그 때는 상징적인 이름 해석이 시도됩니다).
proto protocol
  IPv4 프로토콜에 일치하는 패킷이 매치 합니다.
recv | xmit | via {ifX | if * | ipno | any}
  수신한 패킷, 송신하는 패킷, 통과하는 패킷이 각각 매치 합니다. 인터페이스는 정확한 이름 ( ifX), 디바이스명 ( if*), IP 주소로 지정하는지, 혹은 어떠한 인터페이스를 통과하는 것을 지정합니다.

via 키워드는 인터페이스가 항상 체크되게 됩니다. recv (이)나 xmit 하지만 via 대신에 사용되었을 경우, 수신한 인터페이스, 또는 송신하는 인터페이스 (각각 대응합니다) 만이 체크됩니다. 양쪽 모두 지정했을 경우, 송신 인터페이스와 수신 인터페이스의 양쪽 모두에 근거한다 패킷의 매치이 가능하게 됩니다. 예를 들면 다음과 같이 됩니다:

    ipfw add deny ip from any to any out recv ed0 xmit ed1

recv 인터페이스는 도착 또는 송출 패킷의 어딘가에 붙어 검사할 수가 있습니다만, xmit 인터페이스는 송출 패킷에만 붙어 검사할 수가 있습니다. 따라서 xmit (을)를 사용하는 경우에는 out (은)는 필수입니다 (그리고 in (은)는 무효가 됩니다).

패킷이 수신 인터페이스나 송신 인터페이스를 가지지 않는 것이 있습니다: 로컬 호스트로부터 발생한 패킷은 수신 인터페이스를 가지지않고, 로컬 호스트에 도착할 예정의 패킷은 송신 인터페이스를 가지지 않습니다.

setup SYN 비트가 세트 되고 있지만 ACK 비트를 가지지 않는다 TCP 패킷에 매치 합니다. 이것은 "tcpflags syn,! ack" 의 단축형입니다.
src-ip ip-address
  발신기지 IP 가 인수로 지정된 주소의 1 개인 IP 패킷에 매치 합니다.
src-port ports
  발신기지 포트가 인수로 지정된 포토의 1 개인 IP 패킷에 매치 합니다.
tcpack ack
  TCP 패킷만입니다. TCP 헤더의 확인 응답 번호 필드가 ack (으)로 설정되어 있으면 매치 합니다.
tcpflags spec
  TCP 패킷만입니다. TCP 헤더가 spec 그리고 지정한 콤마 단락의 플래그의 리스트를 포함하고 있으면 매치 합니다. 서포트되고 있는 TCP 플래그는 다음과 같습니다:

fin, syn, rst, psh, ack, urg!’ (을)를 두는 것으로 특정의 플래그가 존재하지 않는다고 하는 기술을 할 수 있습니다. tcpflags 의 지정을 포함한 룰은 0 이 아닌 오프셋(offset)를 가지는 fragment 패킷에는 결코 매치 할 수 없습니다. fragment 패킷의 매치에 대한 자세한 것은 frag 옵션을 참조해 주세요.

tcpseq seq
  TCP 패킷만입니다. TCP 헤더의 순차 순서 번호 필드가 seq (으)로 설정되어 있으면 매치 합니다.
tcpwin win
  TCP 패킷만입니다. TCP 헤더의 윈도우 필드가 win (으)로 설정되어 있으면 매치 합니다.
tcpoptions spec
  TCP 패킷만입니다. spec 그리고 지정한 콤마 단락의 옵션의 리스트가 TCP 헤더에 포함되어 있으면 매치 합니다. 서포트되고 있는 TCP 옵션은 다음과 같습니다:

mss (최대 세그먼트(segment) 사이즈), window (TCP 윈도우 광고), sack (선택적 ACK), ts (RFC1323 타임 스탬프), cc (RFC1644 T/TCP connection 카운트) ‘!’ (을)를 두는 것으로 특정의 옵션이 존재하지 않는다고 하는 기술을 할 수 있습니다.

uid user
  user 하지만 송신한 또는 수신하는, 모든 TCP 패킷과 UDP 패킷에 매치 합니다. user (은)는, 이름이라도 ID 번호에서도 매치 합니다.

룰세트

각 룰은 0 에서 31 까지 번호를 붙여진 32 가 다르다 세트 의 어느 쪽인가에 속하고 있습니다. 세트 31 은 디폴트 룰을 위해서(때문에) 예약되고 있습니다.

디폴트에서는, 신규의 룰을 입력할 때에 set N 애트리뷰트(attribute) 를 사용하지 않으면, 룰은 세트 0 에 놓여집니다. 세트는 개별적으로, 한편, 아토믹에 유효화하거나 무효화하거나 할 수 있으므로, 이 기구에 의해, 파이어 월(fire wall)에 관한 복수의 설정을 격납해, 그러한 설정을 재빠르게 (한편 아토믹에) 바꾸기 위한 방법이 간단하게 됩니다. 세트를 유효화/무효화하는 명령은 다음과 같이.

ipfw set disable number ... [ enable number ...]

여기에서는 복수의 enable 또는 disable 섹션이 지정 가능합니다. 명령로 지정한 모든 세트에 대해, 명령은 아토믹에 실행됩니다. 디폴트에서는 모든 세트는 유효화 된 상태입니다.

세트를 무효화할 때, 파이어 월(fire wall)의 설정안에 그 룰이 존재하지 않는 것처럼 행동합니다. 다만 예외가 1 개만 있습니다:

룰세트 번호는 다음의 명령로 변경할 수 있습니다.

ipfw set move { rule rule-number | old-set} to new-set

또, 다음의 명령을 사용해 2 살의 룰 세트를 아토믹에 바꿔 넣을 수가 있습니다.

ipfw set swap first-set second-set

룰세트로 사용할 수 있는 항목은 사용예 섹션을 참조해 주세요.

스테이트 풀 파이어 월(fire wall)

스테이트 풀 오퍼레이션은, 주어진 패턴에 매치 하는 패킷이 검출되었을 때에, 특정의 플로우(flow)에 대한 룰을 동적으로 파이어 월(fire wall)에 작성하기 위한 방법입니다. 스테이트 풀 오퍼레이션에 대한 서포트는 check-state, keep-state limit 옵션을 통해서 제공됩니다.

src-ip/src-port dst-ip/dst-port 의 주소의 페어의 사이에게 줄 수 있었다 protocol (을)를 사용해 모두 또는 그것만의 패킷에 매치 한다 동적 룰이 생성되는 경우, 동적 룰은 패킷이 keep-state (이)나 limit 룰에 매치 했을 때에 생성됩니다 ( src (와)과 dst (은)는 여기에서는 초기 상태로 매치 하는 주소를 나타내기 위해서(때문에) 마셔 사용되고 있습니다만, 그것들은 다음에 가리키는 것과 완전하게 등가입니다). 동적 룰은 최초로 check-state, keep-state 또는 limit 의 발생이 체크되어 매치 했을 때에 실행되는 액션은 친룰과 같은 것이 됩니다.

프로토콜과 IP 주소 이외에 추가되는 속성은 없고, 포트는 동적 룰로 체크되는 것에 주의해 주세요.

동적 룰의 전형적인 사용법은, 파이어 월(fire wall)의 설정을 닫은 채로 해 두는 것입니다. 그러나, 내부 네트워크로부터의 최초의 TCP SYN 패킷에 의해, 플로우(flow)에 대한 동적 룰이 인스톨 되므로, 그 세션에 소속하는 패킷은 파이어 월(fire wall)의 통과를 허가되게 됩니다.

    ipfw add check-state

    ipfw add allow tcp from my-subnet to any setup

    ipfw add deny tcp from any to any

동일한 접근가 UDP 에 대해서도 사네, 내부로부터 오는 UDP 패킷에 의해, 그 응답은 파이어 월(fire wall)를 통과하도록(듯이) 동적 룰이 인스톨 되게 됩니다:

    ipfw add check-state

    ipfw add allow udp from my-subnet to any

    ipfw add deny udp from any to any

동적 룰은 당분간 경과한 후기한조각이 됩니다. 그 시간은, 플로우(flow) 상태 물어 구두인가의 sysctl 변수의 설정에 의존합니다. 자세한 것은 섹션 sysctl 변수 (을)를 참조해 주세요. TCP 세션에서는, 기한 마감이 되는 무렵에 룰 상태를 리프레쉬 시키기 (위해)때문에, 정기적으로 킵얼라이브 패킷을 송출하는 듯 동적 룰에 통지할 수가 있습니다.

동적 룰의 사용 방법에 관한 다른 예는 섹션 사용예 (을)를 참조해 주세요.

트라픽크시이파 설정

ipfw (은)는, dummynet(4) 트라픽크시이파에의 유저 인터페이스도 제공합니다. 시이파는, 유저가 지정한 마스크를 IP 헤더가 다른 필드에 적용하는 것으로써, 패킷을 플로우(flow) (flow)에 분할합니다. 같은 플로우(flow)에 속하는 패킷은 2 개가 다른 오브젝트에 건네받습니다. 그것은 파이프 (pipe) 또는 (queue)(으)로 불리는 것입니다. 파이프 (은)는, 주어진 밴드폭, 지연 시간, 큐의 길이, 패킷 손실율을 가지는 링크를 에뮤레이트 합니다. 이 파라미터에 따라, 패킷은 파이프중을 천이 합니다.

(은)는, WF2Q+ (Worst-case Fair Weighted Fair Queueing) 포리시를 실장하기 위해서 사용하는 추상화입니다. 큐는, 각 플로우(flow)에 대해, 중량감과 참조 파이프를 관련짓습니다. 그리고, 같은 파이프에 연결시킬 수 있던 모든 플로우(flow)는, WF2Q+ 포리시에 따라, 파이프에 의해 고정된 레이트로 스케줄 됩니다.

ipfw 파이프 설정의 서식은 다음과 같습니다: pipe number config pipe-configuration

ipfw 큐 설정의 서식은 다음과 같습니다: queue number config queue-configuration

다음의 파라미터를 파이프에 대해서 설정 가능합니다:

bw bandwidth | device
  밴드폭으로, 단위는 [K|M]{bit/s|Byte/s}입니다.

값 0 (디폴트)은 무한의 밴드폭을 의미합니다. 단위는 수치의 직후에 잇고 쓸 필요가 있어, 다음과 같이 합니다.

    ipfw pipe 1 config bw 300Kbit/s

수치대신에 디바이스명이 지정되었을 경우, 송신 클락은 지정한 디바이스로부터 주어집니다. 현재로서는, tun(4) 디바이스만이 ppp(8) (와)과 조합해 사용하기 위해서, 이 기능을 제공하고 있습니다.

delay ms-delay
  지연 시간이며, 밀리 세컨드 단위로 지정합니다. 값은, 크로크틱의 배수 (전형적으로는 10ms 입니다만, 커널을 "options HZ=1000" 그리고 동작시켜 정밀도를 1ms 이하로 하면 좋다 일이 경험적으로 알려져 있습니다)에 말 수 있습니다. 기본값은 0 이며, 지연 없음을 의미합니다.

다음의 파라미터를 큐에 대해서 설정 가능합니다:

pipe pipe_nr
  큐를 지정한 파이프에 접속합니다. 복수의 큐 (대체로는 다른 중량감을 가집니다) (을)를 동일한 파이프에 접속할 수가 있습니다. 파이프는 큐의 집합에 대한 집약된 레이트를 지정합니다.

weight weight
  이 큐에 매치 하는 플로우(flow)에 적용하는 중량감을 지정합니다. 중량감은 1 에서 100 의 범위가 아니면 안되어, 디폴트는 1 입니다.

마지막으로, 다음의 파라미터가 파이프나 큐에 대해서 설정할 수 있습니다:

buckets hash-table-size
  여러가지 큐를 격납하는 해시표의 사이즈를 지정합니다. 디폴트는 64 로, sysctl(8) 변수 net.inet.ip.dummynet.hash_size 에 의해 16 에서 1024 까지의 범위에서 제어하는 것이 가능합니다.

mask mask-specifier
  dummynet(4) 그럼, 플로우(flow)마다의 큐를 생성 가능합니다. 플로우(flow) 식별자는, 파이프 설정에 대해 지정된다 IP 주소, 포트, 프로토콜 타입으로 마스크 하는 것으로 구축됩니다. 마스크 후에 같은 식별자를 가지는 패킷은, 같은 큐에 떨어집니다. 사용 가능한 마스크 지정자는, 다음을 조합한 것입니다: dst-ip mask, src-ip mask, dst-port mask, src-port mask, proto mask, all 마지막 지정자는, 모든 필드의 모든 비트가 검사되는 것을 의미하고 있습니다. 파이프 설정 중(안)에서 사용되는 경우, 각 플로우(flow)에는 파이프의 레이트에 동일한 레이트를 할당할 수 있습니다. 설정 중(안)에서 사용되는 경우, 각 플로우(flow)에는 큐의 중량감에 동일한 중량감을 할당할 수 있어 같은 파이프를 구성하는 큐는 중량감에 비례해 밴드폭을 공유합니다.

noerror
  패킷이 dummynet 의 큐나 파이프에 의해 떨어뜨려졌을 때, 통상은, 디바이스 큐가 가득하게 되었을 때에 생기는 것과 같은 형태로, 에러가 커널내의 호출원routine에 보고됩니다. 이 옵션을 설정하면(자), 패킷의 배송에 성공했는지와 같이 보고됩니다. 이것은, 원격지에 있는 라우터에서의 손실이나 congestion를 시뮬레이트 하고 싶다고 한다 일부의 실험적인 설정을 위해서(때문에) 필요하게 되고 있습니다.

plr packet-loss-rate
  패킷의 손실율입니다. 인수 packet-loss-rate (은)는 0 에서 1 까지의 부동 소수점수(실수)로, 0 이 손실이 없는 것을, 1 이 100% 없어지는 것을 의미합니다. 손실율은 내부적으로는 31 비트로 표현되고 있습니다.

queue {slots | size Kbytes}
  slots 또는 KBytes 그리고 나타낸 큐의 사이즈입니다. 디폴트는 50 슬롯에서, 이것은 이더넷(ethernet) 디바이스에 있어서의 전형적인 큐의 사이즈입니다. 저속 링크를 위해서(때문에) 큐의 사이즈를 작은 채로 해 두는 것이 추천 됩니다. 그렇게 하지 않으면 트래픽에 대한 큐의 지연이 현저해질지도 모릅니다. 예를 들면, 최대 사이즈의 이더넷(ethernet) 패킷 (1500 바이트)이 50 개 때, 600 Kbit, 즉 30 Kbit/초의 파이프로 20 초라는 것이 됩니다. 그것보다 훨씬 큰 MTU 를 가진 인터페이스 (예를 들면 루프백 인터페이스는 16KB 패킷입니다) (으)로부터 패킷을 받는다고 해도 나쁜 결과가 되는 일이 있습니다.

red | gred w_q/min_th/max_th/max_p
  RED (Random Early Detection) 큐 관리 알고리즘을 사용합니다. w_q (와)과 max_p (은)는 0 에서 1 (0 을 포함하지 않습니다)의 범위의 부동 소수점수(실수)이며, min_th (와)과 max_th (은)는 큐 관리용의 반응을 일으키는 최소의 물리량을 지정하는 정수입니다 (큐가 바이트수로 지정되었을 경우는 반응을 일으키는 최소의 물리량은 아르바이트로 계산되어 그렇지 않은 경우는 슬롯수로 계산됩니다). dummynet(4) (은)는, gentle RED 라고 하는 변형 (gred)도 서포트합니다. RED 의 동작을 제어하기 위해서, 3 개의 sysctl(8) 변수를 사용 가능합니다:
net.inet.ip.dummynet.red_lookup_depth
  링크가 아이돌때의, 평균 큐의 계산 정밀도를 지정합니다 (디폴트는 256 이며, 0 보다 클 필요가 있습니다)
net.inet.ip.dummynet.red_avg_pkt_size
  패킷 사이즈의 평균의 기대치를 지정합니다 (디폴트는 512 이며, 0 보다 클 필요가 있습니다)
net.inet.ip.dummynet.red_max_pkt_size
  패킷 사이즈의 최대치의 기대치를 지정합니다. 큐의 반응을 일으키는 최소의 물리량이 바이트의 경우만 사용됩니다 (디폴트는 1500 이며, 0 보다 클 필요가 있습니다)

대조표

룰을 구성할 때에 고려해야 할 중요한 점을 말합니다.

세세한 일

패킷의 행선지 변경

지정된 포트에 바인드 되었다 divert(4) 소켓은, 그 포트에 행선지 변경된 패킷을, 전부 받습니다. 행선지 포트에 바인드 된 소켓이 없는 경우나, 커널이 패킷의 행선지 변경 소켓을 서포트하도록(듯이)는 컴파일되어 있지 않은 경우, 패킷은 파기됩니다.

SYSCTL 변수

sysctl(8) 변수의 집합은, 파이어 월(fire wall)와 관련하는 모듈 ( dummynet, )의 동작을 제어합니다. 기본값 (어느 값이 실제로 사용될까는 sysctl 그리고 확인해 주세요)와 의미와 함께, 이것들을 이하에 열거합니다.
net.inet.ip.dummynet.expire: 1
  미결정의 트래픽이 한번도 없었던 동적 파이프/큐를 나태하게 삭제합니다. 이 변수를 0 으로 설정하는 것으로 이 동작을 무효로 할 수가 있습니다. 이 경우, 파이프/큐는 반응을 일으키는 최소의 물리량에 이르렀을 경우에게만 삭제되게 됩니다.
net.inet.ip.dummynet.hash_size: 64
  동적 파이프/큐에 사용되는 해시표의 디폴트의 크기입니다. 이 값은 파이프/큐를 설정할 경우에 buckets 옵션이 1 개나 지정되지 않았던 경우에 사용됩니다.
net.inet.ip.dummynet.max_chain_len: 16
  해시 버킷 (hash bucket) 내의 파이프/큐의 최대 개수의 값입니다. net.inet.ip.dummynet.expire=0 에서 만나도, 적 max_chain_len*hash_size 하지만 하늘의 파이프/큐가 기한 마감이 되었다고 하는 반응을 일으키는 최소의 물리량을 결정하는데 사용됩니다.
net.inet.ip.dummynet.red_lookup_depth: 256
net.inet.ip.dummynet.red_avg_pkt_size: 512
net.inet.ip.dummynet.red_max_pkt_size: 1500
  RED 알고리즘을 사용해 떨어뜨리는 확률을 계산하는데 사용되는 파라미터입니다.
net.inet.ip.fw.autoinc_step: 100
  룰 번호를 자동 생성할 때의 룰 번호간의 차분입니다. 이 값은 1 에서 100 의 범위가 아니면 안됩니다.
net.inet.ip.fw.curr_dyn_buckets: net.inet.ip.fw.dyn_buckets
  동적 룰의 해시표내의 현재의 버킷의 개수입니다 (읽기만).
net.inet.ip.fw.debug: 1
  ipfw 하지만 생성하는 디버그 메세지를 제어합니다.
net.inet.ip.fw.dyn_buckets: 256
  동적 룰로 사용되는 해시표에 포함되는 버킷의 개수입니다. 2 의 누승이 아니면 안되어, 상한은 65536 입니다. 모든 동적 룰이 기한 마감이 되었을 때에 마셔 효과가 나타나므로, 확실히 해시표의 사이즈가 변경되도록(듯이) 하려면 flush 명령을 사용해야 하는 것이지요.
net.inet.ip.fw.dyn_count: 3
  현재의 동적 룰의 수입니다 (읽기 전용).
net.inet.ip.fw.dyn_keepalive: 1
  TCP 세션에 대해 keep-state 룰을 위한 킵얼라이브 패킷을 생성하도록(듯이) 합니다. 킵얼라이브 패킷은 룰의 생존 시간이 남아 20 초가 되었을 때에 접속의 양단을 향해 5 초 마다 생성됩니다.
net.inet.ip.fw.dyn_max: 8192
  동적 룰의 최대치입니다. 이 한계에 살아 붙으면(자), 낡은 룰이 무효가 될 때까지는, 그 이상, 동적 룰을 짜넣을 수 없습니다.
net.inet.ip.fw.dyn_ack_lifetime: 300
net.inet.ip.fw.dyn_syn_lifetime: 20
net.inet.ip.fw.dyn_fin_lifetime: 1
net.inet.ip.fw.dyn_rst_lifetime: 1
net.inet.ip.fw.dyn_udp_lifetime: 5
net.inet.ip.fw.dyn_short_lifetime: 30
  이러한 값은, 동적 룰의 생존 시간을 초단위로 컨트롤 합니다. 최초의 SYN 교환 시에는 생존 시간이 단기 (short)가 되어, 그 후 서로의 SYN 가 검출된 후는 증가 당해 마지막 FIN 교환동안, 또는 RST 를 수신했을 때에 다시 줄여집니다. dyn_fin_lifetime dyn_rst_lifetime (은)는 엄밀하게 5 초 (킵얼라이브를 반복하는 주기)보다 짧지 않으면 안됩니다. 파이어 월(fire wall)에서는 이것이 강제당합니다.
net.inet.ip.fw.enable: 1
  파이어 월(fire wall)를 유효하게 합니다. 이 변수를 0 으로 설정하면(자), 머신이 컴파일시에 유효의 설정이 되고 있는 경우여도, 파이어 월(fire wall)가 없는 상태로 실행됩니다.
net.inet.ip.fw.one_pass: 1
  설정되어 있는 경우, dummynet(4) 파이프로부터 나오는 패킷은 재차 파이어 월(fire wall)를 통과할 것은 없습니다. 그렇지 않은 경우, 파이프 액션의 뒤, 패킷은 다음의 룰로 파이어 월(fire wall)에 재주입됩니다.

주: 파이프로부터 생기는 브릿지 된 패킷이나 레이어 2 패킷은, 이 변수의 값에 관련되지 않고, 파이어 월(fire wall)에 결코 재주입되지 않습니다.

net.inet.ip.fw.verbose: 1
  장황 메세지를 유효하게 합니다.
net.inet.ip.fw.verbose_limit: 0
  장황 출력을 실시하도록(듯이) 설정된 파이어 월(fire wall)가 생성하는 메세지수를 제한합니다.
net.link.ether.ipfw: 0
  ipfw 하지만 레이어 2 패킷을 통하는지 어떤지를 제어합니다. 디폴트는 no 입니다.
net.link.ether.bridge_ipfw: 0
  ipfw 하지만 브릿지 된 패킷을 통하는지 어떤지를 제어합니다. 디폴트는 no 입니다.

IPFW2 확장

이 섹션에서는 ipfw2 그리고 도입되어 ipfw1 에는 없는 기능의 일람을 나타냅니다. 여기에서는 룰 세트를 기술할 때에 영향이 크다고 생각되는 순으로 가리킵니다. 보다 효과적인 방식으로 룰 세트를 기술하기 위해서 이러한 기능을 사용하고 싶다고 생각할지도 모릅니다.
비 IPv4 의 패킷의 취급
  ipfw1 (은)는 모든 비 IPv4 패킷을 입다물고 받아들입니다 ( ipfw1 net.link.ether.bridge_ipfw=1 의 경우에게만 참조합니다). ipfw2 하 모든 패킷 (비 IPv4 패킷을 포함한다)을 룰 세트에 따라 필터 합니다. ipfw1 (와)과 같은 동작을 시키고 싶은 경우는 룰 세트의 선두에서 다음과 같이 합니다:

    ipfw add 1 allow layer2 not mac-type ip

layer2 옵션은 장황하도록 보입니다만, 필요합니다 -- 레이어 3 으로부터 파이어 월(fire wall)를 통과하는 패킷은 MAC 헤더를 기다리지 않기 때문에, mac-type ip 패턴은 레이어 3의 패킷에 대해서 항상 실패합니다. 즉, not 오퍼레이터를 두면(자) 모두를 통과시키는 룰이 되어 버립니다.

주소 세트 ipfw1 (은)는 주소 세트 ( addr/masklen{num, num,...} 그렇다고 하는 형식의 것) (을)를 서포트하고 있지 않습니다.

ipfw1 (와)과 ipfw2 에는, ipno:mask (와)과 같은 주소 지정으로, 연속하는 비트열 대신에 임의의 비트 마스크를 마스크로 지정하는 것이 할 수 있다고 하는 작은 차이가 있습니다. ipfw2 (은)는 이미 이 문법을 서포트하고 있었습니다만, 커널의 옆에서 서포트되고 있으므로 사소한 일입니다만 다시 도입하고 있습니다.

포트의 지정 ipfw1 그럼 TCP 와 UDP 의 포트를 지정할 때에 지정할 수 있는 포트 범위는 1 개만이었습니다. 또, ipfw2 그리고 가능한 15 엔트리에 대해서 10 엔트리에 제한되고 있었습니다. 또, ipfw1 그럼 tcp 또는 udp 패킷을 요구하는 룰의 경우에 한해서 포트를 지정하는 것이 가능합니다. ipfw2 그럼 모든 패킷에 매치 시키는 룰로 포트의 지정을 실시하는 것이 가능해, 매치은 포트 식별자를 포함한 프로토콜을 옮기는 패킷에만 적용됩니다.

마지막으로, ipfw1 그럼 최초의 포트 엔트리를 port:mask (와)과 지정할 수가 있습니다. 여기서 mask (은)는 임의의 16 비트 마스크가 사용 가능합니다. 이 문법이 유용한지 어떤지는 의문이므로 ipfw2 그럼 이미 서포트되고 있지 않습니다.

논리합 블록 ipfw1 (은)는 논리합 블록을 서포트하고 있지 않습니다.
킵얼라이브 ipfw1 (은)는 상태 의존 세션을 위한 킵얼라이브를 생성하지 않습니다. 결과적으로, 휴지 상태의 세션은 동적 룰의 생존 시간이 기한 마감이 되기 위해서(때문에) 떨어뜨려지는 일이 있습니다.
룰 세트 ipfw1 (은)는 룰 세트를 실장하고 있지 않습니다.
MAC 헤더에 의한 필터와 레이어 2 의 파이어 월(fire wall)
  ipfw1 (은)는 MAC 헤더 필드에 의한 필터를 실장하고 있지않고, ether_demux() (와)과 ether_output_frame() (으)로부터의 패킷에 의해도 기동하지 않습니다. sysctl 변수 net.link.ether.ipfw (은)는 여기에서는 아무 효과도 없습니다.
옵션 다음의 옵션은 ipfw1 그럼 서포트되고 있지 않습니다.

dst-ip, dst-port, layer2, mac, mac-type, src-ip, src-port

게다가 다음의 옵션은 ipfw1 (RELENG_4) 의 룰에서는 서포트되고 있지 않습니다: ipid, iplen, ipprecedence, iptos, ipttl, ipversion, tcpack, tcpseq, tcpwin

dummynet 옵션
  dummynet 파이프/큐용의 다음의 옵션은 서포트되고 있지 않습니다: noerror

사용예

ipfw (은)는 너무 많은 사용 방법이 있으므로 이 섹션에서는 사용 예의 일부를 나타낼 뿐으로 해 둡니다.

기본적인 패킷 필터링

다음의 명령은 cracker.evil.org (으)로부터 wolf.tambov.su 의 telnet 포트에 보내지는 모든 TCP 패킷을 거부하는 룰을 추가합니다.

    ipfw add deny tcp from cracker.evil.org to wolf.tambov.su telnet

다음의 명령은 크래커의 네트워크 전체로부터 호스트 my 에의 모든 connection를 거부합니다.

    ipfw add deny ip from 123.45. 67.0/24 to my.host.org

최초로 효율 좋게 (동적 룰을 이용하지 않고 ) 액세스를 제한하는 방법은, 다음의 룰을 이용하는 것입니다.

    ipfw add allow tcp from any to any established

    ipfw add allow tcp from net1 portlist1 to net2 portlist2 setup

    ipfw add allow tcp from net3 portlist3 to net3 portlist3 setup

    ...

    ipfw add deny tcp from any to any

최초의 룰은 통상의 TCP 패킷에 곧바로 매치 합니다만, 최초의 SYN 패킷에는 매치 하지 않습니다. 지정한 발신기지/행선지의 조의 SYN 패킷만, 다음의 setup 룰에 매치 합니다. 이것들 이외의 SYN 패킷은, 마지막 deny 룰에 의해 각하 됩니다.

만약, 1 개(살) 이상의 서스네트워크의 관리자라면, 이하와 같이, 주소 세트와 논리합 블록을 지정해 클라이언트의 블록에 서비스를 선택적으로 이용 가능하게 한다 지극히 컴팩트한 룰 세트를 기술한다고 한다 ipfw2 의 문법의 이점을 채용할 수가 있습니다.

    goodguys=q{ 10.1. 2.0/24{20,35,66,18} or 10.2. 3.0/28{6,3,11} }q

    badguys=q10. 1.2. 0/24{8,38,60}q

   

    ipfw add allow ip from ${goodguys} to any

    ipfw add deny ip from ${badguys} to any

    ... normal policies ...

ipfw1 의 문법에서는, 위의 예에서는 각 IP 에 다른 룰을 준비할 필요가 있습니다.

동적 룰

가짜의 TCP 패킷을 포함한 노도의 공격 (flood attack)으로부터 사이트를 보호하기 위해서는, 다음의 동적 룰을 이용하는 것이 안전합니다.

    ipfw add check-state

    ipfw add deny tcp from any to any established

    ipfw add allow tcp from my-net to any setup keep-state

이러한 룰에 의해, 파이어 월(fire wall)는, 스스로의 네트워크의 안쪽으로부터 도착하는 통상의 SYN 패킷으로 시작되는 connection에 대해서 마셔 동적 룰을 짜넣습니다. 동적 룰은, 최초의 check-state 룰, 또는, keep-state 룰에 조우한 시점에서 체크됩니다. 룰 집합의 스캔량을 최소로 하기 위해서(때문에), check-state 룰은, 룰 집합의 최초 쪽에 두게 되는 것이 보통입니다. 실제의 연비는 변동합니다.

유저가 열리는 접속수를 제한하려면 , 다음의 타입의 룰을 사용 가능합니다:

    ipfw add allow tcp from my-net/24 to any setup limit src-addr 10

    ipfw add allow tcp from any to me setup limit src-addr 4

전자 (게이트웨이상에서 동작하는 것을 가정)는,/24 넷상의 각 호스트가 최대 10 개의 TCP 접속을 여는 것을 허락합니다. 후자는, 서버상으로 설정 가능하고, 단일의 클라이언트가 동시에 4 개를 넘는 접속을 사용할 수 없게 합니다.

주의: 스테이트 풀인 룰은, 노도의 SYN 공격에 의해 지극히 대량의 동적 룰을 만들어 버려, 서비스 불능 공격을 받게 될 가능성이 있습니다. 파이어 월(fire wall)의 동작을 컨트롤 한다 sysctl(8) 변수에 따라 파이어 월(fire wall)가 동작하는 것에 의해, 이러한 공격의 영향을 부분적이라도 제한할 수 있습니다.

다음은 카운트 되고 있는 정보와 타임 스탬프 정보를 본다 list 명령이 좋은 예입니다.

    ipfw -at list

이것은 타임 스탬프를 생략 해 다음과 같이 지정할 수 있습니다.

    ipfw -a list

이것은 다음의 지정과 등가입니다.

    ipfw show

다음의 룰은 192.168. 2.0/24 로부터의 모든 수신 패킷을, 5000 번의 포트에 행선지 변경하는 것입니다.

    ipfw divert 5000 ip from 192.168. 2.0/24 to any in

트라픽크시이파

다음의 룰은, ipfw (와)과 dummynet(4) (을)를 시뮬레이션등으로 사용할 때의 사용 방법을 나타내고 있습니다.

이 룰은 5% 의 확률로 랜덤에 패킷을 떨어뜨립니다.

    ipfw add prob 0.05 deny ip from any to any in

같은 효과는 dummynet 파이프로 실현 가능합니다:

    ipfw add pipe 10 ip from any to any

    ipfw pipe 10 config plr 0.05

인공적으로 밴드폭을 제한하기 위해서 파이프를 사용 가능합니다. 예를 들면 라우터로서 동작하는 머신상에서, 192.168. 2.0/24 상의 로컬 클라이언트로부터의 트래픽을 제한하고 싶은 경우, 다음과 같이 합니다:

    ipfw add pipe 1 ip from 192.168. 2.0/24 to any out

    ipfw pipe 1 config bw 300Kbit/s queue 50KBytes

out 지시자를 사용하고 있으므로, 룰이 2 번 사용되지 않는 것에 주의해 주세요. ipfw 룰은, 실제로는, 입력 패킷과 출력 패킷의 양쪽 모두에 적용되는 것을 기억해 둬 주세요.

밴드폭에 제한이 있는 쌍방향 링크를 시뮬레이트 하는 경우, 올바른 방법은 다음과 같습니다:

    ipfw add pipe 1 ip from any to any out

    ipfw add pipe 2 ip from any to any in

    ipfw pipe 1 config bw 64Kbit/s queue 10Kbytes

    ipfw pipe 2 config bw 64Kbit/s queue 10Kbytes

상술의 방법은 매우 유용한 경우가 있어, 예를 들면 당신의 장식적인 웹페이지가 저속 링크만으로 접속되고 있는 재택 유저에게 어떻게 보이고 있을까 알고 싶은 경우에 유용합니다. 반이중 미디어 (예를 들면 appletalk, Ethernet, IRDA)를 시뮬레이트 하고 싶다 경우를 제외해, 단일의 파이프를 양쪽 모두의 방향으로 사용해야 하지는 않습니다. 양쪽 모두의 파이프가 같은 설정일 필요는 없기 때문에, 비대칭 링크를 시뮬레이트 가능합니다.

RED 큐 관리 알고리즘을 사용해 네트워크 성능을 검증하려면 , 다음과 같이 합니다:

    ipfw add pipe 1 ip from any to any

    ipfw pipe 1 config bw 500Kbit/s queue 100 red 0.002/30/80/0. 1

트라픽크시이파의 다른 전형적인 응용은, 약간의 통신 지연을 도입하는 것입니다. 이것은, 원격 수속 호출을 다용하는 어플리케이션으로, 밴드폭보다 접속의 왕복 여행 시간이 자주 제약 조건이 된다 어플리케이션에, 큰 영향을 줍니다:

    ipfw add pipe 1 ip from any to any out

    ipfw add pipe 2 ip from any to any in

    ipfw pipe 1 config delay 250ms bw 1Mbit/s

    ipfw pipe 2 config delay 250ms bw 1Mbit/s

플로우(flow)마다의 큐는 다양한 용도에 유용합니다. 매우 단순한 용도는, 트래픽의 집계입니다:

    ipfw add pipe 1 tcp from any to any

    ipfw add pipe 1 udp from any to any

    ipfw add pipe 1 ip from any to any

    ipfw pipe 1 config mask all

상술의 룰 세트는, 모든 트래픽에 대한 큐를 생성 (해 통계 정보를 수집)합니다. 파이프에는 제한을 붙이지 않기 때문에, 통계 정보를 모으는 효과 밖에 없습니다. 마지막 룰 뿐만이 아니라 3 개의 룰이 필요한 일로 주의해 주세요. ipfw 하지만 IP 패킷의 매치을 시도할 때 포트를 고려하지 않기 때문에, 다른 포트상의 접속은 우리에게는 같은 것으로 보입니다.

보다 세련된 예는, 네트워크의 출력 트래픽을, 네트워크마다 제약하는 것이 아니라, 호스트마다 제약하는 것입니다:

    ipfw add pipe 1 ip from 192.168. 2.0/24 to any out

    ipfw add pipe 2 ip from any to 192.168. 2.0/24 in

    ipfw pipe 1 config mask src-ip 0x000000ff bw 200Kbit/s queue 20Kbytes

    ipfw pipe 2 config mask dst-ip 0x000000ff bw 200Kbit/s queue 20Kbytes

룰 세트

룰 세트를 자동적으로 추가하려면 , 예를 들면 세트 18 이라면:

    ipfw disable set 18

    ipfw add NN set 18 ... # 필요에 따라서 반복한다

    ipfw enable set 18

룰 세트를 자동적으로 삭제하려면 명령은 단지:

    ipfw delete set 18

룰 세트의 테스트를 실시하거나 무엇인가 실수가 있었을 경우에 룰 세트를 삭제해 제어를 회복하려면:

    ipfw disable set 18

    ipfw add NN set 18 ... # 필요에 따라서 반복한다

    ipfw enable set 18 ; echo done; sleep 30 && ipfw disable set 18

여기서 각 설정이 잘되었을 경우, "sleep" 가 종료되기 전에 control-C 를 누르면(자), 룰 세트는 활동 상태인 채됩니다. 그렇지 않은 경우, 비록 상자에 액세스 할 수가 없었다고 해도, 룰 세트는 단말이 sleeve 한 다음에 무효인 상태가 되므로 이전의 상황이 복원됩니다.

관련 항목

cpp(1) [영어], m4(1), bridge(4), divert(4), dummynet(4), ip(4), ipfirewall(4), protocols(5), services(5), init(8), kldload(8), reboot(8), sysctl(8), syslogd(8)

S. Floyd, V. Jacobson, Random Early Detection gateways for Congestion Avoidance, August 1993.

B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang, RFC 2309, Recommendations on Queue Management and Congestion Avoidance in the Internet, April 1998.

버그

세월과 함께 문법이 커져, 가끔 혼란하는 일도 있겠지요. 불행하게 해, 후방 호환성을 위해서(때문에) 문법의 정의의 잘못을 정정할 수 없고 있습니다.

!!! 경고 !!!

파이어 월(fire wall)를 잘못해 설정하면(자) 컴퓨터가 사용 불능인 상태가 될 가능성이 있습니다. 것에 의하면(자), 네트워크의 서비스를 정지해 버려, 제어를 회복하기 위해서 콘솔 액세스가 필요해 버리겠지요.

들어 온 패킷의 단편 (fragment)이 divert 에 의해 행선지가 변경될까 tee 되면(자), 소켓에 배송되기 전에 패킷은 재구성됩니다. 이러한 패킷으로 사용되는 액션은 패킷의 최초의 fragment에 매치 한 룰의 1 개입니다.

tee 룰에 매치 하는 패킷은, 즉시에 수리되어야 하는 것이 아니고, 룰 리스트를 더욱 통과해야 합니다. 이것은, 이후의 버젼으로 수정될지도 모릅니다.

유저 랜드에 향할 수 있어 유저 랜드의 프로세스 (예를 들면 natd(8)) 에 의해 재투입되는 패킷은, 패킷의 발신기지 인터페이스를 포함한다 패킷 속성의 여러 가지를 잃고 있습니다. 패킷이 이 방법으로 재투입되었을 경우, 후의 룰은 올바르게 적용되지 않을지도 모릅니다. 룰의 및 둘 수 있다 divert 룰의 순서는 매우 중요한 것이 됩니다.

저자

Ugen J. S. Antsilevich, Poul-Henning Kamp, Alex Nash, Archie Cobbs, Luigi Rizzo.

API 는 Daniel Boulet 하지만 BSDI 용으로 기술한 코드에 근거하고 있습니다.

dummynet(4) 트라픽크시이파는 Akamba Corp. 하지만 서포트했습니다.

역사

ipfw (은)는, FreeBSD 2.0 그리고 최초로 나타났습니다. dummynet(4) 하 FreeBSD 2.2.8 (으)로부터 도입되었습니다. 스테이트 풀 확장은, FreeBSD 4.0 (으)로부터 도입되었습니다. ipfw2 (은)는 2002 년 여름에 도입되었습니다.

IPFW (8) August 13, 2002

tail head cat sleep
QR code linking to this page


Ben Bullock이 유닉스 매뉴얼 페이지에서 서비스에 대한 의견을 주시기 바랍니다. Privacy policy.

If you have any trouble sounding condescending, find a Unix user to show you how it's done.
— Scott Adams