Iptables - 편집 역사

imported>Darkcircle: /* 동작 개념 */

2015-07-26T22:59:23Z

동작 개념

← 이전 판		2015년 7월 26일 (일) 22:59 판
55번째 줄:		55번째 줄:
	</div>		</div>

	prerouting 및 postrouting단계를 제외한 모든 단계에서 필터링을 수행한다. prerouting 단계는 내부로 넘기기 전 단계이기 때문에 굳이 필터링을 할 이유가 없기 때문이다. 또한 postrouting단계에서는 prerouting에서 처리한 결과를 돌려내야 하므로 역시 이 단계에서도 필터링을 하면 안된다. pre/postrouting 단계에서는 패킷을 어디로 어떻게 보낼 것이냐를 결정하는게 주된 목적이자 역할이다. 만약 prerouting에서 필터링을 해버리면 다른 노드로 라우팅을 할 패킷이 사라지거나 서버에서 받아야 할 패킷이 사라질 것이다(...). 또한 postrouting 단계에서 필터링을 해버리면 전달 패킷이 사라질 것이다. iptables에서 적용하는 처리 대상 단계는 크게 다섯가지 단계다. 이 각각의 단계를 체인이라고 한다. 이 다섯가지 체인은 가장 기본적인 구성요소이며, 경우에 따라 새로 정의하고 추가할 수 있다. 각각의 체인에 대한 규칙(동작) 테이블은 기본적으로 filter, nat, mangle 세 가지로 구성되어 있다. iptables의 규칙 테이블은 동작 중심이며 체인 중심이 아니다.		prerouting 및 postrouting단계를 제외한 모든 단계에서 필터링을 수행한다. prerouting 단계는 내부로 넘기기 전 단계이기 때문에 굳이 필터링을 할 이유가 없기 때문이다. 또한 postrouting단계에서는 prerouting에서 처리한 결과를 돌려내야 하므로 역시 이 단계에서도 필터링을 하면 안된다. pre/postrouting 단계에서는 패킷을 어디로 어떻게 보낼 것이냐를 결정하는게 주된 목적이자 역할이다. 만약 prerouting에서 필터링을 해버리면 다른 노드로 라우팅을 할 패킷이 사라지거나 서버에서 받아야 할 패킷이 사라질 것이다(...). 또한 postrouting 단계에서 필터링을 해버리면 전달 결과를 반환하는 데이터의 패킷이 사라질 것이다. iptables에서 적용하는 처리 대상 단계는 크게 다섯가지 단계다. 이 각각의 단계를 체인이라고 한다. 이 다섯가지 체인은 가장 기본적인 구성요소이며, 경우에 따라 새로 정의하고 추가할 수 있다. 각각의 체인에 대한 규칙(동작) 테이블은 기본적으로 filter, nat, mangle 세 가지로 구성되어 있다. iptables의 규칙 테이블은 동작 중심이며 체인 중심이 아니다.

	* prerouting: 라우팅 전단계에서 패킷을 어떻게 처리할 지를 정의한다. nat 테이블과 mangle 테이블에 해당 체인 규칙을 넣을 수 있다.		* prerouting: 라우팅 전단계에서 패킷을 어떻게 처리할 지를 정의한다. nat 테이블과 mangle 테이블에 해당 체인 규칙을 넣을 수 있다.

imported>Darkcircle: /* 동작 개념 */

2015-07-26T22:55:44Z

동작 개념

← 이전 판		2015년 7월 26일 (일) 22:55 판
55번째 줄:		55번째 줄:
	</div>		</div>

	prerouting 및 postrouting단계를 제외한 모든 ~~테이블 및~~ 단계에서 필터링을 수행한다. prerouting 단계는 내부로 넘기기 전 단계이기 때문에 굳이 필터링을 할 이유가 없기 때문이다. 또한 postrouting단계에서는 prerouting에서 처리한 결과를 돌려내야 하므로 역시 이 단계에서도 필터링을 하면 안된다. pre/postrouting 단계에서는 패킷을 어디로 어떻게 보낼 것이냐를 결정하는게 주된 목적이자 역할이다. 만약 prerouting에서 필터링을 해버리면 다른 노드로 라우팅을 할 패킷이 사라지거나 서버에서 받아야 할 패킷이 사라질 것이다(...). 또한 postrouting 단계에서 필터링을 해버리면 전달 패킷이 사라질 것이다. iptables에서 적용하는 처리 대상 단계는 크게 다섯가지 단계다. 이 각각의 단계를 체인이라고 한다. 이 다섯가지 체인은 가장 기본적인 구성요소이며, 경우에 따라 새로 정의하고 추가할 수 있다. 각각의 체인에 대한 규칙(동작) 테이블은 기본적으로 filter, nat, mangle 세 가지로 구성되어 있다. iptables의 규칙 테이블은 동작 중심이며 체인 중심이 아니다.		prerouting 및 postrouting단계를 제외한 모든 단계에서 필터링을 수행한다. prerouting 단계는 내부로 넘기기 전 단계이기 때문에 굳이 필터링을 할 이유가 없기 때문이다. 또한 postrouting단계에서는 prerouting에서 처리한 결과를 돌려내야 하므로 역시 이 단계에서도 필터링을 하면 안된다. pre/postrouting 단계에서는 패킷을 어디로 어떻게 보낼 것이냐를 결정하는게 주된 목적이자 역할이다. 만약 prerouting에서 필터링을 해버리면 다른 노드로 라우팅을 할 패킷이 사라지거나 서버에서 받아야 할 패킷이 사라질 것이다(...). 또한 postrouting 단계에서 필터링을 해버리면 전달 패킷이 사라질 것이다. iptables에서 적용하는 처리 대상 단계는 크게 다섯가지 단계다. 이 각각의 단계를 체인이라고 한다. 이 다섯가지 체인은 가장 기본적인 구성요소이며, 경우에 따라 새로 정의하고 추가할 수 있다. 각각의 체인에 대한 규칙(동작) 테이블은 기본적으로 filter, nat, mangle 세 가지로 구성되어 있다. iptables의 규칙 테이블은 동작 중심이며 체인 중심이 아니다.

	* prerouting: 라우팅 전단계에서 패킷을 어떻게 처리할 지를 정의한다. nat 테이블과 mangle 테이블에 해당 체인 규칙을 넣을 수 있다.		* prerouting: 라우팅 전단계에서 패킷을 어떻게 처리할 지를 정의한다. nat 테이블과 mangle 테이블에 해당 체인 규칙을 넣을 수 있다.

imported>Darkcircle: /* 동작 개념 */

2015-07-26T22:54:27Z

동작 개념

← 이전 판		2015년 7월 26일 (일) 22:54 판
55번째 줄:		55번째 줄:
	</div>		</div>

	prerouting 및 postrouting단계를 제외한 모든 테이블 및 단계에서 필터링을 수행한다. prerouting 단계는 내부로 넘기기 전 단계이기 때문에 굳이 필터링을 할 이유가 없기 때문이다. 만약 prerouting에서 필터링을 해버리면 다른 노드로 라우팅을 할 패킷이 사라지거나 서버에서 받아야 할 패킷이 사라질 것이다(...). 또한 postrouting 단계에서 필터링을 해버리면 전달 패킷이 사라질 것이다. iptables에서 적용하는 처리 대상 단계는 크게 다섯가지 단계다. 이 각각의 단계를 체인이라고 한다. 이 다섯가지 체인은 가장 기본적인 구성요소이며, 경우에 따라 새로 정의하고 추가할 수 있다. 각각의 체인에 대한 상태 테이블은 기본적으로 filter, nat, mangle 세 가지로 구성되어 있다.		prerouting 및 postrouting단계를 제외한 모든 테이블 및 단계에서 필터링을 수행한다. prerouting 단계는 내부로 넘기기 전 단계이기 때문에 굳이 필터링을 할 이유가 없기 때문이다. 또한 postrouting단계에서는 prerouting에서 처리한 결과를 돌려내야 하므로 역시 이 단계에서도 필터링을 하면 안된다. pre/postrouting 단계에서는 패킷을 어디로 어떻게 보낼 것이냐를 결정하는게 주된 목적이자 역할이다. 만약 prerouting에서 필터링을 해버리면 다른 노드로 라우팅을 할 패킷이 사라지거나 서버에서 받아야 할 패킷이 사라질 것이다(...). 또한 postrouting 단계에서 필터링을 해버리면 전달 패킷이 사라질 것이다. iptables에서 적용하는 처리 대상 단계는 크게 다섯가지 단계다. 이 각각의 단계를 체인이라고 한다. 이 다섯가지 체인은 가장 기본적인 구성요소이며, 경우에 따라 새로 정의하고 추가할 수 있다. 각각의 체인에 대한 규칙(동작) 테이블은 기본적으로 filter, nat, mangle 세 가지로 구성되어 있다. iptables의 규칙 테이블은 동작 중심이며 체인 중심이 아니다.

	* prerouting: 라우팅 전단계에서 패킷을 어떻게 처리할 지를 정의한다. nat 테이블과 mangle 테이블에 해당 체인 규칙을 넣을 수 있다.		* prerouting: 라우팅 전단계에서 패킷을 어떻게 처리할 지를 정의한다. nat 테이블과 mangle 테이블에 해당 체인 규칙을 넣을 수 있다.
	* postrouting: 라우팅을 처리하고 난 패킷을 어떻게 처리할 지를 정한다. 이 또한 nat 테이블과 mangle 테이블에 체인 규칙을 넣을 수 있다.		* postrouting: 라우팅을 처리하고 난 패킷을 어떻게 처리할 지를 정한다. 이 또한 nat 테이블과 mangle 테이블에 체인 규칙을 넣을 수 있다.
	* input, output: 보통 output 테이블은 잘 안쓰고 input 테이블을 많이 쓴다. input 테이블을 쓰는 목적은 아무래도 검열(?)과 차단(???)이 아닐까 (?????)		* input, output: 보통 output 테이블은 잘 안쓰고 input 테이블을 많이 쓴다. input 테이블을 쓰는 목적은 아무래도 검열(?)과 차단(???)이 아닐까 (?????) 물론 기업체에서는 외부로의 접속을 막기 위해 output 테이블을 활용하기도 한다. 순전히 통제와 검열이 목적이다. =3
	* forward: 전달 패킷을 걸러내거나 패킷을 전달할 대상을 위해 패킷의 특성을 일부 수정한다.		* forward: 전달 패킷을 걸러내거나 패킷을 전달할 대상을 위해 패킷의 특성을 일부 수정한다. 서버 요청과 같은 패킷을 포워딩할 때 쓴다.

	== 참고자료 ==		== 참고자료 ==
	<references/>		<references/>

imported>Darkcircle: /* 동작 개념 */

2015-07-26T22:40:58Z

동작 개념

← 이전 판		2015년 7월 26일 (일) 22:40 판
55번째 줄:		55번째 줄:
	</div>		</div>

	prerouting ~~단계를~~ 제외한 모든 테이블 및 단계에서 필터링을 수행한다. prerouting 단계는 내부로 넘기기 전 단계이기 때문에 굳이 필터링을 할 이유가 없기 때문이다. 만약 prerouting에서 필터링을 해버리면 다른 노드로 라우팅을 할 패킷이 사라질 것이다(...). iptables에서 적용하는 처리 대상 단계는 크게 다섯가지 단계다. 이 각각의 단계를 체인이라고 한다. 이 다섯가지 체인은 가장 기본적인 구성요소이며, 경우에 따라 새로 정의하고 추가할 수 있다.		prerouting 및 postrouting단계를 제외한 모든 테이블 및 단계에서 필터링을 수행한다. prerouting 단계는 내부로 넘기기 전 단계이기 때문에 굳이 필터링을 할 이유가 없기 때문이다. 만약 prerouting에서 필터링을 해버리면 다른 노드로 라우팅을 할 패킷이 사라지거나 서버에서 받아야 할 패킷이 사라질 것이다(...). 또한 postrouting 단계에서 필터링을 해버리면 전달 패킷이 사라질 것이다. iptables에서 적용하는 처리 대상 단계는 크게 다섯가지 단계다. 이 각각의 단계를 체인이라고 한다. 이 다섯가지 체인은 가장 기본적인 구성요소이며, 경우에 따라 새로 정의하고 추가할 수 있다. 각각의 체인에 대한 상태 테이블은 기본적으로 filter, nat, mangle 세 가지로 구성되어 있다.

			* prerouting: 라우팅 전단계에서 패킷을 어떻게 처리할 지를 정의한다. nat 테이블과 mangle 테이블에 해당 체인 규칙을 넣을 수 있다.
			* postrouting: 라우팅을 처리하고 난 패킷을 어떻게 처리할 지를 정한다. 이 또한 nat 테이블과 mangle 테이블에 체인 규칙을 넣을 수 있다.
			* input, output: 보통 output 테이블은 잘 안쓰고 input 테이블을 많이 쓴다. input 테이블을 쓰는 목적은 아무래도 검열(?)과 차단(???)이 아닐까 (?????)
			* forward: 전달 패킷을 걸러내거나 패킷을 전달할 대상을 위해 패킷의 특성을 일부 수정한다.

	== 참고자료 ==		== 참고자료 ==
	<references/>		<references/>

imported>Darkcircle: /* 동작 개념 */

2015-07-26T22:22:40Z

동작 개념

← 이전 판		2015년 7월 26일 (일) 22:22 판
49번째 줄:		49번째 줄:

	=== 동작 개념 ===		=== 동작 개념 ===
	iptables는 전송 계층 위로 패킷이 도달하기 전에 규칙을 검사하고 패킷을 넘겨줄지 폐기할지를 결정하는 역할을 한다. iptables의 동작 개념은 다음 그림과 같다.		iptables는 전송 계층 위로 패킷이 도달하기 전에 규칙을 검사하고 패킷을 넘겨줄지 폐기할지를 결정하는 역할을 한다. iptables의 동작 개념은 다음 그림과 같다. 정확히 말하자면 동작 자체를 설명하기 보다는 동작하는 테이블의 구조를 표현하는 그림이라 해야 맞겠다.

			<div align="center">
			[[File:Slide2.jpg]]
			</div>

			prerouting 단계를 제외한 모든 테이블 및 단계에서 필터링을 수행한다. prerouting 단계는 내부로 넘기기 전 단계이기 때문에 굳이 필터링을 할 이유가 없기 때문이다. 만약 prerouting에서 필터링을 해버리면 다른 노드로 라우팅을 할 패킷이 사라질 것이다(...). iptables에서 적용하는 처리 대상 단계는 크게 다섯가지 단계다. 이 각각의 단계를 체인이라고 한다. 이 다섯가지 체인은 가장 기본적인 구성요소이며, 경우에 따라 새로 정의하고 추가할 수 있다.

	== 참고자료 ==		== 참고자료 ==
	<references/>		<references/>

imported>Darkcircle: /* 설명 모델 */

2015-07-26T21:59:20Z

설명 모델

← 이전 판		2015년 7월 26일 (일) 21:59 판
46번째 줄:		46번째 줄:
	그림에서 보는 바와 같이 서버 A를 통해 내부 네트워크를 형성하며 서버 A와 연결된 WiFi 어댑터와 유선 스위칭 허브로 하위 네트워크의 모든 노드에 유무선 네트워크 환경을 제공한다. 이를 가능케 하기 위해 iptables와 dhcpd를 활용할 것이다. 이 환경에 붙어있는 서버 B는 서버 A의 서비스를 일부 분산할 수 있도록 물리적으로 서버 A로부터 자원을 분리/분산하였다. 서버 B의 위치는 구조상 서버 A를 통한 하위 네트워크에 속하기 때문에 외부에서 직접적인 접근이 불가능하여 서버 A에서 iptables를 통해 서버 B의 서비스를 전달할 것이다. 또한 유선 라우터에 연결한 무선 라우터에서도 마찬가지로 업링크 자원을 활용하여 외부와 통신 가능한 유무선 네트워크 환경을 구축할 것이다. 무선 라우터는 서버로부터 비교적 떨어진 위치에 있다고 가정하며, 서버의 WiFi Coverage와 WiFi Router의 WiFi Coverage는 중첩되지 아니한다고 본다. 앞으로 진행할 모든 과정은 서버 A에서 모든 설정을 처리하는 것을 전제로 한다.		그림에서 보는 바와 같이 서버 A를 통해 내부 네트워크를 형성하며 서버 A와 연결된 WiFi 어댑터와 유선 스위칭 허브로 하위 네트워크의 모든 노드에 유무선 네트워크 환경을 제공한다. 이를 가능케 하기 위해 iptables와 dhcpd를 활용할 것이다. 이 환경에 붙어있는 서버 B는 서버 A의 서비스를 일부 분산할 수 있도록 물리적으로 서버 A로부터 자원을 분리/분산하였다. 서버 B의 위치는 구조상 서버 A를 통한 하위 네트워크에 속하기 때문에 외부에서 직접적인 접근이 불가능하여 서버 A에서 iptables를 통해 서버 B의 서비스를 전달할 것이다. 또한 유선 라우터에 연결한 무선 라우터에서도 마찬가지로 업링크 자원을 활용하여 외부와 통신 가능한 유무선 네트워크 환경을 구축할 것이다. 무선 라우터는 서버로부터 비교적 떨어진 위치에 있다고 가정하며, 서버의 WiFi Coverage와 WiFi Router의 WiFi Coverage는 중첩되지 아니한다고 본다. 앞으로 진행할 모든 과정은 서버 A에서 모든 설정을 처리하는 것을 전제로 한다.

	서버 A에서 외부와 연결한 랜카드를 A, 내부로 연결하는 랜카드를 ~~B라고~~ 하며, 인터페이스 이름은 그림에 나타난 바와 같다. 이 네트워크 인터페이스 이름을 통해 칩셋의 장착 위치와 네트워크 장치의 특성을 가늠할 수 있다. 자세한 내용은 freedesktop.org 문서<ref>http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/</ref>를 참고하도록.		서버 A에서 외부와 연결한 랜카드를 A(enp2s1), 내부로 연결하는 랜카드를 B(eno1)라고 하며, 인터페이스 이름은 그림에 나타난 바와 같다. 이 네트워크 인터페이스 이름을 통해 칩셋의 장착 위치와 네트워크 장치의 특성을 가늠할 수 있다. 자세한 내용은 freedesktop.org 문서<ref>http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/</ref>를 참고하도록.

	=== 동작 개념 ===		=== 동작 개념 ===

imported>Darkcircle: /* 설명 모델 */

2015-07-26T21:58:35Z

설명 모델

← 이전 판		2015년 7월 26일 (일) 21:58 판
44번째 줄:		44번째 줄:
	</div>		</div>

	그림에서 보는 바와 같이 서버 A를 통해 내부 네트워크를 형성하며 서버 A와 연결된 WiFi 어댑터와 유선 스위칭 허브로 하위 네트워크의 모든 노드에 유무선 네트워크 환경을 제공한다. 이를 가능케 하기 위해 iptables와 dhcpd를 활용할 것이다. 이 환경에 붙어있는 서버 B는 서버 A의 서비스를 일부 분산할 수 있도록 물리적으로 서버 A로부터 자원을 분리/분산하였다. 서버 B의 위치는 구조상 서버 A를 통한 하위 네트워크에 속하기 때문에 외부에서 직접적인 접근이 불가능하여 서버 A에서 iptables를 통해 서버 B의 서비스를 전달할 것이다. 또한 유선 라우터에 연결한 ~~유무선~~ 라우터에서도 마찬가지로 업링크 자원을 활용하여 외부와 통신 가능한 유무선 네트워크 환경을 구축할 것이다. ~~물론 이~~ 모든 과정은 서버 A에서 모든 설정을 처리하는 것을 전제로 한다.		그림에서 보는 바와 같이 서버 A를 통해 내부 네트워크를 형성하며 서버 A와 연결된 WiFi 어댑터와 유선 스위칭 허브로 하위 네트워크의 모든 노드에 유무선 네트워크 환경을 제공한다. 이를 가능케 하기 위해 iptables와 dhcpd를 활용할 것이다. 이 환경에 붙어있는 서버 B는 서버 A의 서비스를 일부 분산할 수 있도록 물리적으로 서버 A로부터 자원을 분리/분산하였다. 서버 B의 위치는 구조상 서버 A를 통한 하위 네트워크에 속하기 때문에 외부에서 직접적인 접근이 불가능하여 서버 A에서 iptables를 통해 서버 B의 서비스를 전달할 것이다. 또한 유선 라우터에 연결한 무선 라우터에서도 마찬가지로 업링크 자원을 활용하여 외부와 통신 가능한 유무선 네트워크 환경을 구축할 것이다. 무선 라우터는 서버로부터 비교적 떨어진 위치에 있다고 가정하며, 서버의 WiFi Coverage와 WiFi Router의 WiFi Coverage는 중첩되지 아니한다고 본다. 앞으로 진행할 모든 과정은 서버 A에서 모든 설정을 처리하는 것을 전제로 한다.

			서버 A에서 외부와 연결한 랜카드를 A, 내부로 연결하는 랜카드를 B라고 하며, 인터페이스 이름은 그림에 나타난 바와 같다. 이 네트워크 인터페이스 이름을 통해 칩셋의 장착 위치와 네트워크 장치의 특성을 가늠할 수 있다. 자세한 내용은 freedesktop.org 문서<ref>http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/</ref>를 참고하도록.

	=== 동작 개념 ===		=== 동작 개념 ===

imported>Darkcircle: /* 설명 모델 */

2015-07-26T21:51:25Z

설명 모델

← 이전 판		2015년 7월 26일 (일) 21:51 판
39번째 줄:		39번째 줄:
	=== 설명 모델 ===		=== 설명 모델 ===
	앞으로 설명을 진행할 하드웨어 레벨의 네트워크 구조는 다음과 같다.		앞으로 설명을 진행할 하드웨어 레벨의 네트워크 구조는 다음과 같다.

			<div align="center">
			[[File:Slide1.jpg]]
			</div>

			그림에서 보는 바와 같이 서버 A를 통해 내부 네트워크를 형성하며 서버 A와 연결된 WiFi 어댑터와 유선 스위칭 허브로 하위 네트워크의 모든 노드에 유무선 네트워크 환경을 제공한다. 이를 가능케 하기 위해 iptables와 dhcpd를 활용할 것이다. 이 환경에 붙어있는 서버 B는 서버 A의 서비스를 일부 분산할 수 있도록 물리적으로 서버 A로부터 자원을 분리/분산하였다. 서버 B의 위치는 구조상 서버 A를 통한 하위 네트워크에 속하기 때문에 외부에서 직접적인 접근이 불가능하여 서버 A에서 iptables를 통해 서버 B의 서비스를 전달할 것이다. 또한 유선 라우터에 연결한 유무선 라우터에서도 마찬가지로 업링크 자원을 활용하여 외부와 통신 가능한 유무선 네트워크 환경을 구축할 것이다. 물론 이 모든 과정은 서버 A에서 모든 설정을 처리하는 것을 전제로 한다.

	=== 동작 개념 ===		=== 동작 개념 ===

2015년 7월 26일 (일) 05:28에 imported>Darkcircle님의 편집

2015-07-26T05:28:04Z

← 이전 판		2015년 7월 26일 (일) 05:28 판
9번째 줄:		9번째 줄:
	* 이 문서에는 iptables와 관련한 모든 내용을 하나 빠짐없이 문서화할 필요는 없다. 물론 실무에서 활용할 기술을 넣는 것도 좋겠지만, 전적으로 이 문서는 일반 사용자 측면에서 우선적으로 접근하기 쉬워야한다. 어차피 기본 내용이 들어가도 내용이 쓸데없을 만큼 길 수밖에 없고, 그게 이 문서의 한계이다. 어떤 내용을 넣어야 할지에 대해서는 굳이 상의할 이유가 없으니 문서 작성에 참여하는 스스로가 알아서 판단하고 추가하는 것이 좋겠다.		* 이 문서에는 iptables와 관련한 모든 내용을 하나 빠짐없이 문서화할 필요는 없다. 물론 실무에서 활용할 기술을 넣는 것도 좋겠지만, 전적으로 이 문서는 일반 사용자 측면에서 우선적으로 접근하기 쉬워야한다. 어차피 기본 내용이 들어가도 내용이 쓸데없을 만큼 길 수밖에 없고, 그게 이 문서의 한계이다. 어떤 내용을 넣어야 할지에 대해서는 굳이 상의할 이유가 없으니 문서 작성에 참여하는 스스로가 알아서 판단하고 추가하는 것이 좋겠다.

	== netfilter 소개 ==		== netfilter ==
	netfilter는 리눅스 커널에서 지원하는 패킷 선별 프레임워크이다. 기본적으로 다음과 같은 기능을 지원한다.<ref>http://netfilter.org/</ref>		netfilter는 리눅스 커널에서 지원하는 패킷 선별 프레임워크이다. 기본적으로 다음과 같은 기능을 지원한다.<ref>http://netfilter.org/</ref>

20번째 줄:		20번째 줄:
	netfilter 프레임워크를 사용하는 데이터 흐름 선별 프로그램으로는 iptables, ip6tables, arptables, ebtables가 있으며, 이 중, 이 문서에서 설명할 대상은 iptables이다(추후 ip6tables의 내용을 이곳에 추가할 수 있다). 네트워크 '패킷' 흐름을 관리하기 때문에 통상적으로 OSI Layer 3를 처리하는 것으로 알려져 있으나, 실제로는 iptables에서도 '프레임' 통제가 가능(MAC address 필터링)<ref>[http://www.cyberciti.biz/tips/iptables-mac-address-filtering.html Iptables MAC Address Filterling - nixCraft]</ref>하며, 전송 계층에서의 흐름 통제도 가능하기 때문에 OSI 계층 이론으로는 데이터 단위 선별 처리에 대한 계층이나 기본 데이터 처리 단위 구분이 모호하다. netfilter 프로젝트에서는 데이터 흐름 선별 도구 프로젝트가 문어발식으로 퍼져나가는 문제로 인해, 네트워크 데이터 흐름을 관리할 새로운 도구 nftables<ref>[http://netfilter.org/projects/nftables/index.html The netfilter.org "nftables" project]</ref>를 만들고있다.		netfilter 프레임워크를 사용하는 데이터 흐름 선별 프로그램으로는 iptables, ip6tables, arptables, ebtables가 있으며, 이 중, 이 문서에서 설명할 대상은 iptables이다(추후 ip6tables의 내용을 이곳에 추가할 수 있다). 네트워크 '패킷' 흐름을 관리하기 때문에 통상적으로 OSI Layer 3를 처리하는 것으로 알려져 있으나, 실제로는 iptables에서도 '프레임' 통제가 가능(MAC address 필터링)<ref>[http://www.cyberciti.biz/tips/iptables-mac-address-filtering.html Iptables MAC Address Filterling - nixCraft]</ref>하며, 전송 계층에서의 흐름 통제도 가능하기 때문에 OSI 계층 이론으로는 데이터 단위 선별 처리에 대한 계층이나 기본 데이터 처리 단위 구분이 모호하다. netfilter 프로젝트에서는 데이터 흐름 선별 도구 프로젝트가 문어발식으로 퍼져나가는 문제로 인해, 네트워크 데이터 흐름을 관리할 새로운 도구 nftables<ref>[http://netfilter.org/projects/nftables/index.html The netfilter.org "nftables" project]</ref>를 만들고있다.

	== iptables 소개 ==		== iptables ==
			=== 소개 ===
	흔히들 알고 있는 기본 방화벽의 '''근본''' 도구다. 레드햇 기반의 배포판에서는 방화벽을 활성화 한 상태를 기본으로 설치<ref>[https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-Firewalls-Basic_Firewall_Configuration.html Basic Firewall Configuration - RedHat Customer Portal]</ref>하는데, 이 방화벽을 구성하는 부분이 바로 커널에 내장된 netfilter 프레임워크와 iptables다. 일반 초보자라면 iptables 자체가 워낙 무식하게 복잡한 느낌이기 때문에 우분투 배포판 사용자의 경우 배포판에서 제공하는 ufw<ref>[https://wiki.ubuntu.com/UncomplicatedFirewall Uncomplicated Fire Wall - ubuntu wiki, official.]</ref><ref>[https://help.ubuntu.com/community/UFW UFW - ubuntu documentation, official.]</ref><ref>[http://webdir.tistory.com/206 우분투 방화벽(UFW) 설정 - WEBDIR]</ref>를 쓰는데, ufw도 결국 iptables를 쓰게 만들어놓은 프론트엔드일 뿐이다. 만약 iptables의 근본 동작 따위(?)는 이해하고 싶지 않고, 속시원하게 ufw만 신경쓰겠다면 [http://wiki.ubuntu-kr.org/index.php/UFWHowToKo 이 문서]를 참고한다. 어쨌든, 어떤 리눅스 플랫폼에서든 직접적이든 간접적이든 무조건 netfilter+iptables를 쓴다.		흔히들 알고 있는 기본 방화벽의 '''근본''' 도구다. 레드햇 기반의 배포판에서는 방화벽을 활성화 한 상태를 기본으로 설치<ref>[https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-Firewalls-Basic_Firewall_Configuration.html Basic Firewall Configuration - RedHat Customer Portal]</ref>하는데, 이 방화벽을 구성하는 부분이 바로 커널에 내장된 netfilter 프레임워크와 iptables다. 일반 초보자라면 iptables 자체가 워낙 무식하게 복잡한 느낌이기 때문에 우분투 배포판 사용자의 경우 배포판에서 제공하는 ufw<ref>[https://wiki.ubuntu.com/UncomplicatedFirewall Uncomplicated Fire Wall - ubuntu wiki, official.]</ref><ref>[https://help.ubuntu.com/community/UFW UFW - ubuntu documentation, official.]</ref><ref>[http://webdir.tistory.com/206 우분투 방화벽(UFW) 설정 - WEBDIR]</ref>를 쓰는데, ufw도 결국 iptables를 쓰게 만들어놓은 프론트엔드일 뿐이다. 만약 iptables의 근본 동작 따위(?)는 이해하고 싶지 않고, 속시원하게 ufw만 신경쓰겠다면 [http://wiki.ubuntu-kr.org/index.php/UFWHowToKo 이 문서]를 참고한다. 어쨌든, 어떤 리눅스 플랫폼에서든 직접적이든 간접적이든 무조건 netfilter+iptables를 쓴다.

36번째 줄:		37번째 줄:
	마지막으로, 이 문서가 너무 허접해서 못봐주겠다고 하는 "자칭 전문가"는 [http://www.iptables.info/en/iptables-contents.html iptables 문서]를 정독하면 되겠다.		마지막으로, 이 문서가 너무 허접해서 못봐주겠다고 하는 "자칭 전문가"는 [http://www.iptables.info/en/iptables-contents.html iptables 문서]를 정독하면 되겠다.

	== ~~iptables~~ 동작 개념 ==		=== 설명 모델 ===
			앞으로 설명을 진행할 하드웨어 레벨의 네트워크 구조는 다음과 같다.

			=== 동작 개념 ===
	iptables는 전송 계층 위로 패킷이 도달하기 전에 규칙을 검사하고 패킷을 넘겨줄지 폐기할지를 결정하는 역할을 한다. iptables의 동작 개념은 다음 그림과 같다.		iptables는 전송 계층 위로 패킷이 도달하기 전에 규칙을 검사하고 패킷을 넘겨줄지 폐기할지를 결정하는 역할을 한다. iptables의 동작 개념은 다음 그림과 같다.

	== 참고자료 ==		== 참고자료 ==
	<references/>		<references/>

121.136.217.36: /* iptables 소개 */

2015-07-25T21:07:03Z

iptables 소개

← 이전 판		2015년 7월 25일 (토) 21:07 판
21번째 줄:		21번째 줄:

	== iptables 소개 ==		== iptables 소개 ==
	흔히들 알고 있는 기본 방화벽의 '''근본''' 도구다. 레드햇 기반의 배포판에서는 방화벽을 활성화 한 상태를 기본으로 설치<ref>[https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-Firewalls-Basic_Firewall_Configuration.html Basic Firewall Configuration - RedHat Customer Portal]</ref>하는데, 이 방화벽을 구성하는 부분이 바로 커널에 내장된 netfilter 프레임워크와 iptables다. 일반 초보자라면 iptables 자체가 워낙 무식하게 복잡한 느낌이기 때문에 우분투 배포판 사용자의 경우 배포판에서 제공하는 ufw<ref>[https://wiki.ubuntu.com/UncomplicatedFirewall Uncomplicated Fire Wall - ubuntu wiki, official.]</ref><ref>[https://help.ubuntu.com/community/UFW UFW - ubuntu documentation, official.]</ref><ref>[http://webdir.tistory.com/206 우분투 방화벽(UFW) 설정 - WEBDIR]</ref>를 쓰는데, ufw도 결국 iptables를 쓰게 만들어놓은 프론트엔드일 뿐이다. 만약 iptables의 근본 동작 따위(?)는 이해하고 싶지 않고, 속시원하게 ufw만 신경쓰겠다면 [http://wiki.ubuntu-kr.org/index.php/UFWHowToKo 이 문서]를 ~~참고하면 되겠다~~. 어쨌든, 어떤 리눅스 플랫폼에서든 직접적이든 간접적이든 무조건 netfilter+iptables를 쓴다.		흔히들 알고 있는 기본 방화벽의 '''근본''' 도구다. 레드햇 기반의 배포판에서는 방화벽을 활성화 한 상태를 기본으로 설치<ref>[https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-Firewalls-Basic_Firewall_Configuration.html Basic Firewall Configuration - RedHat Customer Portal]</ref>하는데, 이 방화벽을 구성하는 부분이 바로 커널에 내장된 netfilter 프레임워크와 iptables다. 일반 초보자라면 iptables 자체가 워낙 무식하게 복잡한 느낌이기 때문에 우분투 배포판 사용자의 경우 배포판에서 제공하는 ufw<ref>[https://wiki.ubuntu.com/UncomplicatedFirewall Uncomplicated Fire Wall - ubuntu wiki, official.]</ref><ref>[https://help.ubuntu.com/community/UFW UFW - ubuntu documentation, official.]</ref><ref>[http://webdir.tistory.com/206 우분투 방화벽(UFW) 설정 - WEBDIR]</ref>를 쓰는데, ufw도 결국 iptables를 쓰게 만들어놓은 프론트엔드일 뿐이다. 만약 iptables의 근본 동작 따위(?)는 이해하고 싶지 않고, 속시원하게 ufw만 신경쓰겠다면 [http://wiki.ubuntu-kr.org/index.php/UFWHowToKo 이 문서]를 참고한다. 어쨌든, 어떤 리눅스 플랫폼에서든 직접적이든 간접적이든 무조건 netfilter+iptables를 쓴다.

	iptables를 제대로 쓸 줄 알면 다음과 같은걸 만들 수 있다.		iptables를 제대로 쓸 줄 알면 다음과 같은걸 만들 수 있다.
32번째 줄:		32번째 줄:
	* 등.		* 등.

	물논. iptables로 무슨 짓이든 가능케 하는 문서가 구글 창고를 뒤지면 엄청나게 많이 있다. 그게 다 영어로 써져 있다는게 문제지. 다음부터 진행할 이야기는 iptables 동작 기본 개념이다. 일단 이 부분을 알고 넘긴 후에는 실제로 유무선 공유기와 같은 여러가지 실제 구축 사례를 예제로 ~~선보이도록 하겠다~~. 예제에 대해서는 충분히 기대 ~~안하는게~~ 좋다. 생각처럼 바로바로 쉽게 되는게 아니니까. 게다가 장비도 제대로 갖추어야 한다. 네트워크 ~~구성도 치밀하게 이해할 필요가 있다~~. 멘탈을 아끼고 싶으면 그냥 iptime 공유기를 사서 쓰는게 낫다. 이 문서는 iptime 공유기에 충분히 불만이 있는 사람들을 위한 문서니까.		물논. iptables로 무슨 짓이든 가능케 하는 문서가 구글 창고를 뒤지면 엄청나게 많이 있다. 그게 다 영어로 써져 있다는게 문제지. 다음부터 진행할 이야기는 iptables 동작 기본 개념이다. 일단 이 부분을 알고 넘긴 후에는 실제로 유무선 공유기와 같은 여러가지 실제 구축 사례를 예제로 선보이겠다. 예제에 대해서는 충분히 기대 안 하는게 좋다. 생각처럼 바로바로 쉽게 되는게 아니니까. 게다가 장비도 제대로 갖추어야 한다. 네트워크 구성에 대한 치밀한 이해가 필요하다. 멘탈을 아끼고 싶으면 그냥 iptime 공유기를 사서 쓰는게 낫다. 이 문서는 iptime 공유기에 충분히 불만이 있는 사람들을 위한 문서니까.

	마지막으로, 이 문서가 너무 허접해서 못봐주겠다고 하는 "자칭 전문가"는 [http://www.iptables.info/en/iptables-contents.html iptables 문서]를 정독하면 되겠다.		마지막으로, 이 문서가 너무 허접해서 못봐주겠다고 하는 "자칭 전문가"는 [http://www.iptables.info/en/iptables-contents.html iptables 문서]를 정독하면 되겠다.