🥇 द्रुत मार्ग र लिनक्समा NAT

IPv4 ठेगानाहरू समाप्त भएपछि, धेरै दूरसंचार अपरेटरहरूले ठेगाना अनुवाद प्रयोग गरेर आफ्ना ग्राहकहरूलाई नेटवर्क पहुँच प्रदान गर्ने आवश्यकताको सामना गरिरहेका छन्। यस लेखमा म तपाइँलाई बताउनेछु कि तपाइँ कसरी कमोडिटी सर्भरहरूमा क्यारियर ग्रेड NAT प्रदर्शन प्राप्त गर्न सक्नुहुन्छ।

बिटको इतिहास

IPv4 ठेगाना स्पेस थकान को विषय अब नयाँ छैन। केहि बिन्दुमा, RIPE मा प्रतिक्षा सूचीहरू देखा पर्यो, त्यसपछि एक्सचेन्जहरू देखा पर्‍यो जसमा ठेगानाहरूको ब्लकहरू व्यापार गरियो र तिनीहरूलाई भाडामा दिने सम्झौताहरू सम्पन्न गरियो। बिस्तारै, टेलिकम अपरेटरहरूले ठेगाना र पोर्ट अनुवाद प्रयोग गरेर इन्टरनेट पहुँच सेवाहरू प्रदान गर्न थाले। केहीले प्रत्येक ग्राहकलाई "सेतो" ठेगाना जारी गर्न पर्याप्त ठेगानाहरू प्राप्त गर्न व्यवस्थापन गरेनन्, जबकि अरूले दोस्रो बजारमा ठेगानाहरू खरिद गर्न अस्वीकार गरेर पैसा बचत गर्न थाले। नेटवर्क उपकरणका निर्माताहरूले यो विचारलाई समर्थन गरे, किनभने यो कार्यक्षमतालाई सामान्यतया अतिरिक्त विस्तार मोड्युल वा इजाजतपत्र चाहिन्छ। उदाहरणका लागि, जुनिपरको MX राउटरहरूको लाइनमा (पछिल्लो MX104 र MX204 बाहेक), तपाईंले छुट्टै MS-MIC सेवा कार्डमा NAPT प्रदर्शन गर्न सक्नुहुन्छ, Cisco ASR1k लाई CGN इजाजतपत्र चाहिन्छ, Cisco ASR9k लाई छुट्टै A9K-ISM-100 मोड्युल चाहिन्छ। र उसलाई A9K-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 (लगभग 2013) को लागि GNU/Linux प्रयोग गर्ने मेरो पहिलो प्रयासमा, मैले प्रति सर्भर (Xeon E7-0.8v5) 1650Mpps मा लगभग 2Gbit/s को प्रदर्शन प्राप्त गर्न सक्षम भएँ। त्यस समयदेखि, GNU/Linux कर्नेल नेटवर्क स्ट्याकमा धेरै फरक अप्टिमाइजेसनहरू बनाइएका छन्, एउटै हार्डवेयरमा एउटा सर्भरको कार्यसम्पादन 18-19 Mpps मा लगभग 1.8-1.9 Gbit/s मा बढेको छ (यी अधिकतम मानहरू थिए)। , तर ट्राफिक भोल्युमको माग, एक सर्भर द्वारा प्रशोधन धेरै छिटो बढ्यो। नतिजाको रूपमा, विभिन्न सर्भरहरूमा लोड सन्तुलन गर्न योजनाहरू विकास गरियो, तर यी सबैले प्रदान गरिएका सेवाहरूको स्थापना, मर्मत र मर्मतसम्भारमा जटिलता बढायो।

NFT टेबलहरू

आजकल, सफ्टवेयर "सिफ्टिङ ब्याग" मा एक फैशनेबल प्रवृत्ति DPDK र XDP को प्रयोग हो। यस विषयमा धेरै लेखहरू लेखिएका छन्, धेरै फरक भाषणहरू बनाइएका छन्, र व्यावसायिक उत्पादनहरू देखा परिरहेका छन् (उदाहरणका लागि, VasExperts बाट SKAT)। तर टेलिकम अपरेटरहरूको सीमित प्रोग्रामिङ स्रोतहरूलाई दिईयो, यी फ्रेमवर्कहरूमा आधारित कुनै पनि "उत्पादन" सिर्जना गर्न यो एकदम समस्याग्रस्त छ। भविष्यमा यस्तो समाधान सञ्चालन गर्न धेरै गाह्रो हुनेछ; विशेष गरी, निदान उपकरणहरू विकास गर्नुपर्छ। उदाहरणका लागि, DPDK सँगको मानक tcpdump ले त्यसरी काम गर्दैन, र XDP प्रयोग गरेर तारहरूमा फिर्ता पठाइएका प्याकेटहरू "हेर्न" हुनेछैन। प्रयोगकर्ता-स्पेसमा प्याकेट फर्वार्डिङ आउटपुट गर्नका लागि नयाँ प्रविधिहरूको बारेमा सबै कुराकानीको बीचमा, तिनीहरू बेवास्ता भए। रिपोर्टहरू и लेख पाब्लो नेइरा आयुसो, iptables रखरखावकर्ता, nftables मा प्रवाह अफलोडिंग को विकास को बारे मा। यस संयन्त्रलाई थप विवरणमा हेरौं।

मुख्य विचार यो हो कि यदि राउटरले प्रवाहको दुबै दिशामा एक सत्रबाट प्याकेटहरू पार गर्यो (TCP सत्र स्थापना गरिएको स्थितिमा गयो), तब सबै फायरवाल नियमहरू मार्फत यस सत्रको पछिल्ला प्याकेटहरू पास गर्न आवश्यक छैन, किनभने यी सबै जाँचहरू अझै पनि प्याकेटलाई राउटिङमा स्थानान्तरण गरेर समाप्त हुनेछन्। र हामीले वास्तवमा मार्ग चयन गर्न आवश्यक छैन - हामीलाई पहिले नै थाहा छ कुन इन्टरफेसमा र कुन होस्टमा हामीले यस सत्र भित्र प्याकेटहरू पठाउनु पर्छ। बाँकी सबै यो जानकारी भण्डारण गर्न र प्याकेट प्रशोधनको प्रारम्भिक चरणमा रूटिङको लागि प्रयोग गर्न हो। NAT प्रदर्शन गर्दा, nf_conntrack मोड्युल द्वारा अनुवादित ठेगानाहरू र पोर्टहरूमा परिवर्तनहरू बारे थप जानकारी भण्डारण गर्न आवश्यक छ। हो, निस्सन्देह, यस अवस्थामा, iptables मा विभिन्न पुलिस र अन्य जानकारी र सांख्यिकीय नियमहरूले काम गर्न रोक्छ, तर छुट्टै स्थायी NAT को कार्यको ढाँचा भित्र वा, उदाहरणका लागि, सीमाना, यो त्यति महत्त्वपूर्ण छैन, किनभने सेवाहरू। उपकरणहरूमा वितरित छन्।

कन्फिगरेसन

यो प्रकार्य प्रयोग गर्न हामीलाई आवश्यक छ:

ताजा कर्नेल प्रयोग गर्नुहोस्। तथ्यको बावजुद कार्यक्षमता आफै कर्नेल 4.16 मा देखा पर्‍यो, धेरै लामो समयको लागि यो धेरै "कच्चा" थियो र नियमित रूपमा कर्नेल आतंकको कारण थियो। सबै कुरा डिसेम्बर 2019 को आसपास स्थिर भयो, जब LTS कर्नेल 4.19.90 र 5.4.5 जारी गरियो।
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 ट्राफिक फास्टनाट तालिकामा पर्नेछ र धेरै छिटो प्रशोधन हुनेछ।

Результаты

यो कति "धेरै छिटो" छ भनेर स्पष्ट गर्नको लागि, म दुई वास्तविक सर्भरहरूमा लोडको स्क्रिनसट संलग्न गर्नेछु, समान हार्डवेयर (Xeon E5-1650v2), समान रूपमा कन्फिगर गरिएको, उही लिनक्स कर्नेल प्रयोग गरेर, तर iptables मा NAT प्रदर्शन गर्दै। (NAT4) र nftables मा (NAT5)।

स्क्रिनसटमा प्रति सेकेन्ड प्याकेटहरूको ग्राफ छैन, तर यी सर्भरहरूको लोड प्रोफाइलमा औसत प्याकेट साइज लगभग 800 बाइट हुन्छ, त्यसैले मानहरू 1.5Mpps सम्म पुग्छन्। तपाईले देख्न सक्नुहुने रूपमा, nftables को साथ सर्भरमा ठूलो प्रदर्शन रिजर्भ छ। हाल, यो सर्भरले 30Mpps मा 3Gbit/s सम्म प्रक्रिया गर्दछ र 40Gbps को भौतिक नेटवर्क सीमा पूरा गर्न स्पष्ट रूपमा सक्षम छ, जबकि नि:शुल्क CPU स्रोतहरू छन्।

मलाई आशा छ कि यो सामग्री नेटवर्क ईन्जिनियरहरु लाई आफ्नो सर्भर को प्रदर्शन सुधार गर्न को लागी उपयोगी हुनेछ।

स्रोत: www.habr.com

लिनक्समा द्रुत मार्ग र NAT

बिटको इतिहास

IPTables

NFT टेबलहरू

कन्फिगरेसन

Результаты

एक टिप्पणी थप्न Отменить ответ