Iptables

파일:Pictogram-virtualisation-orange-hex.svg	작업 중인 문서!
	미완성이며, 디자인이 완성되지 않았거나, 아직 채워지지 않은 내용이 있어 여러분의 참여가 필요한 문서입니다.

서문[편집]

커널에서 지원하는 iptables와 관련한 모든 내용을 이곳에 기록하고자 한다. 경우에 따라서 어려울 수도 있다. 이 문서를 읽기 전 반드시 컴퓨터 네트워크 개론서를 "정독" 하여 네트워크 기본 지식을 습득하라. 누군가에게 물어보는 것에 대해 답변을 해주는 사람의 소중한 시간을 빼앗을 가능성에 대해 미안해하는 감정 정도는 가질 수 있겠으나, 누군가에게 질문하는 자체 또는 자기 자신의 치부를 드러내는 것을 두려워해선 안된다. 적당히 어설픈 지식을 갖추면 대강이라도 이해할 수 있지만 그렇지 못하면 외계어 내지는 고대 상형문자 문서보다 더 난해한 ― 흰 것은 도화지요, 검은 것은 그림이다(?) ― "예술" 작품으로밖에 안보일지도 모른다.

참고[편집]

이 문서의 최초 작성자는 질문에 답하지 않으며, 메우메우(?) 게으르므로 문서의 업데이트에 대해 보장하지 않는다. 이 문서는 GFDL 1.3을 따르므로 무단 복제 및 전제를 권장하되, 문서 편집 또는 배포시 이 문서 작업에 관여한 모든 구성원의 닉네임을 반드시 포함하도록 한다.
이 문서에 내용을 추가할 경우 내용의 근거가 되는 자료(참고문헌, 예:설명서, 안내서, 포럼, HOWTO, 블로그 게시글 등)를 필히 명시하도록 한다. 방법은 위키 원문 전체를 참고한다.
이 문서에는 iptables와 관련한 모든 내용을 하나 빠짐없이 문서화할 필요는 없다. 물론 실무에서 활용할 기술을 넣는 것도 좋겠지만, 전적으로 이 문서는 일반 사용자 측면에서 우선적으로 접근하기 쉬워야한다. 어차피 기본 내용이 들어가도 내용이 쓸데없을 만큼 길 수밖에 없고, 그게 이 문서의 한계이다. 어떤 내용을 넣어야 할지에 대해서는 굳이 상의할 이유가 없으니 문서 작성에 참여하는 스스로가 알아서 판단하고 추가하는 것이 좋겠다.

netfilter[편집]

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

무상태 패킷 선별(IPv4, IPv6)
상태별 패킷 선별(IPv4, IPv6)
모든 방식의 네트워크 주소, 포트 해석, 예: NAT/NAPT(IPv4, IPv6)
유연한 운영 기반
개별 기능 확장에 유리한 다중 계층 API

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

iptables[편집]

소개[편집]

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

iptables를 제대로 쓸 줄 알면 다음과 같은걸 만들 수 있다.

공유기
라우터
홈 게이트웨이
보안 방화벽
분산 서버
등.

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

마지막으로, 이 문서가 너무 허접해서 못봐주겠다고 하는 "자칭 전문가"는 iptables 문서를 정독하면 되겠다.

설명 모델[편집]

앞으로 설명을 진행할 하드웨어 레벨의 네트워크 구조는 다음과 같다.

파일:Slide1.jpg

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

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

동작 개념[편집]

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

파일:Slide2.jpg

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

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

참고자료[편집]