Linux의 빠른 라우팅 및 NAT

IPv4 주소가 고갈됨에 따라 많은 통신 사업자는 주소 변환을 사용하여 클라이언트에게 네트워크 액세스를 제공해야 하는 필요성에 직면하게 되었습니다. 이 기사에서는 상용 서버에서 캐리어급 NAT 성능을 얻을 수 있는 방법에 대해 설명합니다.

역사의 비트

IPv4 주소 공간 고갈이라는 주제는 더 이상 새로운 것이 아닙니다. 어떤 시점에서 RIPE에 대기자 명단이 나타난 다음 주소 블록이 거래되고 이를 임대하는 거래가 체결되는 교환이 나타났습니다. 점차적으로 통신 사업자는 주소 및 포트 변환을 사용하여 인터넷 액세스 서비스를 제공하기 시작했습니다. 일부는 각 가입자에게 "화이트" 주소를 발급할 만큼 충분한 주소를 확보하지 못한 반면, 다른 일부는 104차 시장에서 주소 구매를 거부하여 비용을 절약하기 시작했습니다. 네트워크 장비 제조업체가 이 아이디어를 지지한 이유는 다음과 같습니다. 이 기능을 사용하려면 일반적으로 추가 확장 모듈이나 라이센스가 필요합니다. 예를 들어 Juniper의 MX 라우터 제품군(최신 MX204 및 MX1 제외)에서 NAPT는 별도의 MS-MIC 서비스 카드에서 수행될 수 있으며 Cisco ASR9k에는 CGN 라이센스가 필요하고 Cisco ASR9k에는 별도의 A100K-ISM-9 모듈이 필요합니다. 그리고 AXNUMXK-CGN 라이센스 -LIC를 그에게 부여합니다. 일반적으로 즐거움을 누리려면 많은 비용이 듭니다.

IPTables

NAT를 수행하는 작업에는 특수한 컴퓨팅 리소스가 필요하지 않으며, 예를 들어 홈 라우터에 설치된 범용 프로세서로 해결할 수 있습니다. 통신 사업자 규모에서 이 문제는 FreeBSD(ipfw/pf) 또는 GNU/Linux(iptables)를 실행하는 상용 서버를 사용하여 해결할 수 있습니다. 우리는 FreeBSD를 고려하지 않을 것입니다. 왜냐하면... 나는 꽤 오래 전에 이 OS를 사용하지 않았기 때문에 GNU/Linux를 계속 사용할 것입니다.

주소 변환을 활성화하는 것은 전혀 어렵지 않습니다. 먼저 nat 테이블의 iptables에 규칙을 등록해야 합니다.

iptables -t nat -A POSTROUTING -s 100.64.0.0/10 -j SNAT --to <pool_start_addr>-<pool_end_addr> --persistent

운영 체제는 모든 활성 연결을 모니터링하고 필요한 변환을 수행하는 nf_conntrack 모듈을 로드합니다. 여기에는 몇 가지 미묘함이 있습니다. 첫째, 통신 사업자 규모의 NAT에 대해 이야기하고 있기 때문에 기본값을 사용하면 변환 테이블의 크기가 치명적인 값으로 빠르게 증가하기 때문에 시간 초과를 조정해야 합니다. 다음은 내 서버에서 사용한 설정의 예입니다.

net.ipv4.ip_forward = 1
net.ipv4.ip_local_port_range = 8192 65535

net.netfilter.nf_conntrack_generic_timeout = 300
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 600
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 45
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.netfilter.nf_conntrack_icmpv6_timeout = 30
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_events_retry_timeout = 15
net.netfilter.nf_conntrack_checksum=0

둘째, 변환표의 기본 크기는 통신 사업자의 조건에서 작동하도록 설계되지 않았기 때문에 이를 늘려야 합니다.

net.netfilter.nf_conntrack_max = 3145728

또한 모든 브로드캐스트를 저장하는 해시 테이블의 버킷 수를 늘려야 합니다(이것은 nf_conntrack 모듈의 옵션입니다).

options nf_conntrack hashsize=1572864

이러한 간단한 조작 후에는 많은 수의 클라이언트 주소를 외부 주소 풀로 변환할 수 있는 완벽하게 작동하는 디자인이 얻어집니다. 그러나 이 솔루션의 성능은 아직 많이 부족합니다. NAT에 GNU/Linux를 사용하려는 첫 번째 시도(2013년경)에서 서버(Xeon E7-0.8v5)당 1650Mpps에서 약 2Gbit/s의 성능을 얻을 수 있었습니다. 그 이후로 GNU/Linux 커널 네트워크 스택에서 다양한 최적화가 이루어졌으며 동일한 하드웨어에 있는 한 서버의 성능은 18-19 Mpps에서 거의 1.8-1.9 Gbit/s로 증가했습니다(이는 최대값입니다). , 그러나 하나의 서버에서 처리하는 트래픽 양에 대한 수요는 훨씬 빠르게 증가했습니다. 결과적으로 다양한 서버의 로드 균형을 조정하는 체계가 개발되었지만 이로 인해 제공되는 서비스 품질을 설정, 유지 및 유지하는 복잡성이 증가했습니다.

NFTable

요즘 소프트웨어 "이동 가방"의 유행 추세는 DPDK 및 XDP를 사용하는 것입니다. 이 주제에 관해 많은 기사가 작성되었고 다양한 연설이 이루어졌으며 상용 제품이 등장하고 있습니다(예: VasExperts의 SKAT). 그러나 통신 사업자의 제한된 프로그래밍 리소스를 고려할 때 이러한 프레임워크를 기반으로 자체적으로 "제품"을 만드는 것은 상당히 문제가 됩니다. 앞으로 이러한 솔루션을 운영하는 것은 훨씬 더 어려울 것이며, 특히 진단 도구가 개발되어야 할 것입니다. 예를 들어 DPDK가 포함된 표준 tcpdump는 이와 같이 작동하지 않으며 XDP를 사용하여 회선으로 다시 전송된 패킷을 "인식"하지 않습니다. 패킷 전달을 사용자 공간으로 출력하는 새로운 기술에 대한 모든 이야기 속에서 그들은 눈에 띄지 않았습니다. 보고서 и 조항 iptables 관리자인 Pablo Neira Ayuso가 nftables의 흐름 오프로딩 개발에 대해 설명합니다. 이 메커니즘을 더 자세히 살펴보겠습니다.

주요 아이디어는 라우터가 흐름의 양방향으로 한 세션의 패킷을 전달한 경우(TCP 세션이 ESTABLISHED 상태로 전환됨) 모든 방화벽 규칙을 통해 이 세션의 후속 패킷을 전달할 필요가 없다는 것입니다. 이러한 모든 검사는 패킷이 라우팅으로 더 전송되면서 종료됩니다. 그리고 실제로 경로를 선택할 필요가 없습니다. 우리는 이 세션 내에서 어떤 인터페이스와 어떤 호스트로 패킷을 보내야 하는지 이미 알고 있습니다. 남은 것은 이 정보를 저장하고 패킷 처리 초기 단계에서 라우팅에 사용하는 것입니다. NAT 수행 시 nf_conntrack 모듈에서 변환된 주소 및 포트 변경 정보를 추가로 저장해야 합니다. 예, 물론 이 경우 iptables의 다양한 정책과 기타 정보 및 통계 규칙이 작동을 중지하지만 별도의 상설 NAT 작업 프레임워크 내에서 또는 예를 들어 국경에서는 그다지 중요하지 않습니다. 여러 장치에 분산됩니다.

구성

이 기능을 사용하려면 다음이 필요합니다.

• 새로운 커널을 사용하십시오. 기능 자체가 커널 4.16에 등장했다는 사실에도 불구하고 꽤 오랫동안 이 기능은 매우 "원시적"이었고 정기적으로 커널 패닉을 일으켰습니다. LTS 커널 2019 및 4.19.90가 출시된 5.4.5년 XNUMX월쯤 모든 것이 안정화되었습니다.
• 최신 버전의 nftables를 사용하여 nftables 형식으로 iptables 규칙을 다시 작성합니다. 버전 0.9.0에서 정확히 작동합니다.

원칙적으로 첫 번째 항목으로 모든 것이 명확하다면 가장 중요한 것은 조립 중에 구성에 모듈을 포함하는 것을 잊지 않는 것입니다(CONFIG_NFT_FLOW_OFFLOAD=m). 그러면 두 번째 항목에 대한 설명이 필요합니다. nftables 규칙은 iptables와 완전히 다르게 설명됩니다. Документация 거의 모든 포인트를 공개하며 특별한 포인트도 있습니다 변환기 iptables에서 nftables까지의 규칙. 따라서 NAT 및 흐름 오프로드 설정의 예만 설명하겠습니다. 예를 들어 작은 범례는 다음과 같습니다. , - 트래픽이 통과하는 네트워크 인터페이스이며 실제로는 두 개 이상이 있을 수 있습니다. , — "흰색" 주소 범위의 시작 및 끝 주소.

NAT 구성은 매우 간단합니다.

#! /usr/sbin/nft -f

table nat {
        chain postrouting {
                type nat hook postrouting priority 100;
                oif <o_if> snat to <pool_addr_start>-<pool_addr_end> persistent
        }
}

흐름 오프로드를 사용하면 조금 더 복잡하지만 이해하기 쉽습니다.

#! /usr/sbin/nft -f

table inet filter {
        flowtable fastnat {
                hook ingress priority 0
                devices = { <i_if>, <o_if> }
        }

        chain forward {
                type filter hook forward priority 0; policy accept;
                ip protocol { tcp , udp } flow offload @fastnat;
        }
}

사실 이것이 전체 설정입니다. 이제 모든 TCP/UDP 트래픽은 fastnat 테이블에 포함되어 훨씬 빠르게 처리됩니다.

조사 결과

이것이 얼마나 "훨씬 더 빠른지" 명확하게 하기 위해 동일한 하드웨어(Xeon E5-1650v2), 동일 구성, 동일한 Linux 커널을 사용하지만 iptables에서 NAT를 수행하는 두 개의 실제 서버에 대한 로드 스크린샷을 첨부하겠습니다. (NAT4) 및 nftables (NAT5)에서.

스크린샷에는 초당 패킷 수에 대한 그래프가 없지만 이들 서버의 로드 프로필을 보면 평균 패킷 크기가 800바이트 정도이므로 그 값은 최대 1.5Mpps에 이릅니다. 보시다시피, nftables가 있는 서버는 엄청난 성능을 보유하고 있습니다. 현재 이 서버는 30Mpps에서 최대 3Gbit/s를 처리하며 40Gbps의 물리적 네트워크 제한을 충족하는 동시에 여유 CPU 리소스를 확보할 수 있습니다.

이 자료가 서버 성능을 향상시키려는 네트워크 엔지니어에게 도움이 되기를 바랍니다.

출처 : habr.com