# ping 8.8.8.8 
64 bytes from 8.8.8.8: icmp_req=1 ttl=48 time=206 ms 
64 bytes from 8.8.8.8: icmp_req=2 ttl=48 time=204 ms 
 

# tcpdump icmp -n 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode 
listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes 
23:30:35.869225 IP 172.30.1.3 > 8.8.8.8: ICMP echo request, id 1562, seq 1, length 64 
23:30:36.072678 IP 8.8.8.8 > 172.30.1.3: ICMP echo reply, id 1562, seq 1, length 64 
23:30:36.870535 IP 172.30.1.3 > 8.8.8.8: ICMP echo request, id 1562, seq 2, length 64 
23:30:37.074904 IP 8.8.8.8 > 172.30.1.3: ICMP echo reply, id 1562, seq 2, length 64 
 

# tcpdump icmp -n 
23:36:16.883660 IP 192.168.56.101 > 8.8.8.8: ICMP echo request, id 1746, seq 1, length 64 
23:36:17.086226 IP 8.8.8.8 > 192.168.56.101: ICMP echo reply, id 1746, seq 1, length 64 
 

1.2 Masquerade

기본적으로 masquerade와 snat는 같은일을 한다. 유일한 차이점은 snat는 변경할 source ip를 직접 명시하는데, masquerade는 명시하지 않는다는 점이다. masquerade룰을 설정할 경우 알아서 NIC의 인터넷 주소를 할당한다.

# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 
 

1.3 rp_filter

rp_filter는 reverse path filter 설정을 위한 커널 옵션입니다. 기본 값은 1인데, 이 경우 운영체제는 패킷의 출발지 주소가 라우팅 테이블에 등록되있는지를 검사합니다. 만약 등록되있지 않다면 패킷을 드롭해 버립니다. NAT 장비의 경우 네트워크 구성에 따라서 private NIC의 rp_filter 옵션을 꺼야 합니다.

# echo 0 > /proc/sys/net/ipv4/conf/eth*/rp_filter 
 

1.4 DNAT

DNAT는 SNAT의 반대입니다.

앞서 SNAT는 외부에서 내부로는 접근할 수 없다고 했습니다. DNAT는 목적지 IP 주소를 변경해서 내부로 접근할 수 있도록 패킷을 수정합니다.

NAT를 이용하면 외부 인터넷 환경으로 부터 내부 네트워크 환경을 숨길 수 있습니다. 하지만 때때로 인터넷을 내부 네트워크를 허용해야 할 때가 있습니다. DNAT를 사용하면 됩니다. SNAT의 반대라고 보시면 되겠습니다.

1.4.1 DNAT를 이용한 Load balancing

DNAT의 가장 대표적인 사용용도는 서비스 Load balancing입니다. 사설 네트워크인 192.168.0.2, 192.168.0.3 두 개에 웹 서비스를 구축을 했다고 가정해 보겠습니다. 우리가 원하는 것은 두 개의 내부 웹 서버로 부하를 분산하는 겁니다. 웹 서비스 포트 번호는 80번으로 했습니다.

DNAT를 이용하면 패킷을 내부로 보낼 수가 있으므로, 웹 요청을 192.168.0.2와 192.168.0.3 두 개중 하나를 선택해서 보내도록 제어할 수 있을 겁니다. iptable를 이용해서 이런 일을 할 수가 있죠.

DNAT 테스트를 위해서 다음과 같은 테스트 환경을 만들었습니다.

Vituralbox를 이용해서 NAT 환경을 만들고, 2 개의 VM에 Apache 웹 서버를 설치했습니다. 테스트를 위해서 윈도우 7이 설치된 노트북을 준비했습니다. DNAT로 Load balnacing를 제대로 구현한다면, HTTP 요청이 Web server 1과 2에 적당히 분배돼야 할 겁니다.

아래와 같이 DNAT 설정을 만들었습니다.

# iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 80 -m state \ 
--state NEW -m statistic --mode nth --every 2 --packet 0 -j DNAT --to 192.168.56.102 
# iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 80 -m state \ 
--state NEW -m statistic --mode nth --every 1 --packet 0 -j DNAT --to 192.168.56.101 
 

SNAT와는 달리 PREROUTING룰을 추가했습니다. 패킷의 IP 주소는 라우팅 되기 전에 nat 룰이 걸려야 하기 때문입니다. 그래야 제대로 라우팅이 되니까요. wlan0 즉 인터넷으로 부터 들어오는 패킷 중 목적지 포트가 80인 포트에 대해서 룰을 적용합니다.

-m 옵션을 이용해서 모듈을 로딩할 수 있습니다. 먼저 state 모듈을 로딩했는데요. 이 모듈을 이용하면 패킷의 연결 상태에 따른 조건을 줄 수가 있습니다. ESTABLISHED, 'NEW등을 줄 수 있습니다. NEW는 새로 연결을 맺는 것을 의미합니다.

다음 statistic 모듈을 로딩했는데요. 이 모듈은 통계에 기반해서 패킷에 조건을 주기 위해서 사용합니다. random과 nth가 있는데, 전 nth를 사용했습니다. 첫번째 연결은 101, 두번째 연결은 102로 보내라 이런 의미입니다. random 이라면 지 맘대로 보내겠죠.

windows 7 노트북에서 172.30.1.3으로 몇번의 http 요청을 보냈습니다. 잘 되네요. 패킷이 어떻게 분배됐는지 iptables로 확인해 봤습니다.

# iptables -t nat -L -v 
Chain PREROUTING (policy ACCEPT 293 packets, 52270 bytes) 
 pkts bytes target     prot opt in     out   source     destination    
    6   312 DNAT       tcp  --  wlan0  any   anywhere   anywhere      
                    tcp dpt:www state NEW statistic mode nth every 2 packet 1 to:192.168.56.102  
    3   156 DNAT       tcp  --  wlan0  any   anywhere   anywhere       
                    tcp dpt:www state NEW statistic mode nth every 2 to:192.168.56.101  
 

1.4.2 성능 측정 결과

위 환경에서 iperf로 성능을 측정 했습니다만, 개인 노트북에 Apache VM올려서 테스트 한 거라서 성능측정의 의미가 없더군요. 안정적으로 로드 밸런싱이 된다는 정도만 확인할 수 있었습니다. 그래 회사에서 유사한 환경을 만들어서 성능측정을 했습니다. 기존의 haproxy와 함께 테스트를 했는데요. 대략 정리하자면 다음과 같습니다.

haproxy

• 테스트 대역폭 : 1GBits/sec
  
• 로드 밸런싱 웹 서버 : apache 서버 4대
  
• haproxy : 약 360 Mbits/sec
  
• iptables DNAT : 약 750 Mbits/sec
  

참고로 테스트는 KT uCloud 상에서 이루어졌습니다. haproxy와 DNAT서버는 물리적인 서버가 아닌 VM, 즉 가상 라우터로 테스트에 영향을 미칠 수 있습니다.

haproxy는 360MBits가 한계입니다. 이 쯤에서 CPU 자원을 모두 소모해 버립니다. core를 늘리고 - VM이기 때문에 core를 할당할 수가 있습니다. - haproxy를 멀티 프로세스 모드로 작동했지만 하나의 core만을 사용하기 때문에 위 한계를 벗어날 수 없었습니다. 네트워크 인터페이스에 하나의 ring buffer만 만들어지기 때문으로, 물리적인 서버라면 성능이 올라갈 수 있습니다.

iptables는 대역폭의 대부분을 사용하는 것으로 보입니다. CPU 점유율도 5% 미만으로 haproxy에 비할 수 없을 정도로 효율적입니다. 그렇다고 해서 haproxy 보다 무조건 좋은가 하면 그렇지는 않습니다. haproxy는 달리 커널 모드에서 작동하기 때문에, 로드 밸런싱 서버의 웹 서비스를 검사하는 등의 기능은 기대할 수가 없습니다. health 검사 기능을 만드는 수 밖에 없죠.

1.4.3 문제 해결 및 튜닝

• /proc/sys/net/ipv4/netfilter/ip_conntrack_count
  
  현재 추적하고 있는 연결의 갯수
  
• /proc/net/ip_conntrack
  
  추적중인 연결의 상세 정보를 확인할 수 있습니다.
  
• /proc/sys/net/ipv4/netfilter/ip_conntrack_max
  
  자원의 한계가 있개 때문에, 연결을 무한정 추적할 수는 없습니다. 추적가능한 연결의 최대 갯수가 정의돼 있습니다. 만약 이 최대 갯수를 추가해서 연결이 이뤄지면 패킷이 드랍됩니다. 아주 바쁜 웹 서버를 DNAT 기반으로 로드밸런싱 할 경우 ip_conntrack_max를 초과해서 패킷이 드랍될 수 있습니다. 이때는 ip_conntrack_max의 값을 변경하면 됩니다.
  
  

  # cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max  // 현재 값 
  65536 
  # echo 131072 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max 
   

• /sys/module/nf_conntrack_ipv4/parameters/hashsize
  
  연결 정보는 빠른 검색을 위해서 해쉬 테이블에 저장이 됩니다. 해쉬 테이블의 크기를 조정하는 것으로 성능을 튜닝할 수 있습니다. 바쁜 웹서버라면 해쉬 테이블을 크게 해서 선형 검색에 드는 시간을 줄일 수 있겠습니다. 기본 값은 16384 입니다. 만약 백만개 정도의 연결을 관리한다면, 하나의 해쉬 레코드는 1048576/16384 = 64개의 정보를 가지게 될건데, 선형 검색하기에는 지나치게 큰 수 입니다. 32768로 하면 32가 되니 좀더 효율적으로 작동할 겁니다.
  
  

  # echo 32768 > /sys/module/nf_conntrack_ipv4/parameters/hashsize 
   

해쉬 테이블을 크게 하면 메모리도 그만큼 더 소비하게 되겠죠. conntrack 하나의 크기는 228 byte이니 해쉬 테이블 크기에 따른 사용 메모리를 계산하실 수 있을 겁니다.

이제 tcp timeout에 대한 시간을 튜닝하면 됩니다. timeout 시간이 길면, 오랫동안 해쉬 테이블에 남아 있으니 성능이 떨어질 수 밖에 없습니다. 해쉬 테이블이 가득 차서 패킷이 드랍될 수도 있습니다. 그러니 가능한 해쉬 테이블을 빠르게 비워주는게 좋겠죠. 물론 그렇다고해서 timeout을 너무 짧게 하면 서비스에 문제가 생길 수 있으니 적당히 조절해 줘야 겠습니다. 관련 파일들은 /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_* 입니다.

리눅스의 기본 값은 굉장히 큽니다. 가능한 연결을 오래 보존하겠다는 얘기죠.

net.ipv4.ip_conntrack_max = 65496 
net.ipv4.netfilter.ip_conntrack_generic_timeout = 600 
net.ipv4.netfilter.ip_conntrack_icmp_timeout = 30 
net.ipv4.netfilter.ip_conntrack_udp_timeout_stream = 180 
net.ipv4.netfilter.ip_conntrack_udp_timeout = 30 
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 10 
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120 
net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 30 
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 259200 
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120 
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 432000 
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60 
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 120 
net.ipv4.netfilter.ip_conntrack_max = 65496 
 

이걸 웹 서비스에 맞게 조절을 했습니다. 웹은 연결을 유지하는 서비스가 아니니 timeout을 짧게 가져가도 괜찮을 겁니다. 값은 서비스 종류와 접속량등에 따라서 달라질 수 있으니, 적당히 튜닝해서 사용하시면 되겠습니다.

net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 10 
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 20 
net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 20 
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 20 
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 20 
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 30 
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 20  
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 20  
 

2 stateless NAT

Stateless NAT은 dumb NAT 라고 부르기도 한다. NAT의 가장 간단한 형태로 단지 SNAT은 Source IP 주소만 변환하고, DNAT은 Destination IP반 변환해서 넘긴다. conntrack를 유지 하지 않으므로 stateful NAT 보다 빠르게 작동할 것이라고 생각된다. 반면 1:1 static NAT만 사용할 수 있다.

3 history

• 작성일 : 2011년 11월 27일
  
  • 2011년 12/2일 : conntrack 관련 내용 추가
    
    

태그 : network nat dnat snat iptables

category_management