🥇लिनक्स में तेज़ रूटिंग और NAT

जैसे ही IPv4 पते समाप्त हो जाते हैं, कई दूरसंचार ऑपरेटरों को अपने ग्राहकों को एड्रेस ट्रांसलेशन का उपयोग करके नेटवर्क एक्सेस प्रदान करने की आवश्यकता का सामना करना पड़ता है। इस लेख में मैं आपको बताऊंगा कि आप कमोडिटी सर्वर पर कैरियर ग्रेड NAT प्रदर्शन कैसे प्राप्त कर सकते हैं।

एक छोटा सा इतिहास

IPv4 एड्रेस स्पेस की कमी का विषय अब नया नहीं है। कुछ बिंदु पर, प्रतीक्षा सूची RIPE में दिखाई दी, फिर एक्सचेंज उभरे जिन पर पते के ब्लॉक का व्यापार किया गया और उन्हें पट्टे पर देने के लिए सौदे संपन्न हुए। धीरे-धीरे, टेलीकॉम ऑपरेटरों ने एड्रेस और पोर्ट ट्रांसलेशन का उपयोग करके इंटरनेट एक्सेस सेवाएं प्रदान करना शुरू कर दिया। कुछ ने प्रत्येक ग्राहक को "सफेद" पता जारी करने के लिए पर्याप्त पते प्राप्त करने का प्रबंधन नहीं किया, जबकि अन्य ने द्वितीयक बाजार पर पते खरीदने से इनकार करके पैसे बचाना शुरू कर दिया। नेटवर्क उपकरण के निर्माताओं ने इस विचार का समर्थन किया, क्योंकि इस कार्यक्षमता के लिए आमतौर पर अतिरिक्त एक्सटेंशन मॉड्यूल या लाइसेंस की आवश्यकता होती है। उदाहरण के लिए, जुनिपर की एमएक्स राउटर्स की लाइन में (नवीनतम एमएक्स104 और एमएक्स204 को छोड़कर), आप एक अलग एमएस-एमआईसी सर्विस कार्ड पर एनएपीटी निष्पादित कर सकते हैं, सिस्को एएसआर1के को सीजीएन लाइसेंस की आवश्यकता होती है, सिस्को एएसआर9के को एक अलग ए9के-आईएसएम-100 मॉड्यूल की आवश्यकता होती है। और उसे एक A9K-CGN लाइसेंस -LIC। सामान्य तौर पर, आनंद में बहुत पैसा खर्च होता है।

IPTables

NAT निष्पादित करने के कार्य के लिए विशेष कंप्यूटिंग संसाधनों की आवश्यकता नहीं होती है; इसे सामान्य प्रयोजन प्रोसेसर द्वारा हल किया जा सकता है, जो उदाहरण के लिए, किसी भी होम राउटर में स्थापित होते हैं। एक टेलीकॉम ऑपरेटर के पैमाने पर, इस समस्या को FreeBSD (ipfw/pf) या GNU/Linux (iptables) चलाने वाले कमोडिटी सर्वर का उपयोग करके हल किया जा सकता है। हम FreeBSD पर विचार नहीं करेंगे, क्योंकि... मैंने काफी समय पहले इस ओएस का उपयोग बंद कर दिया था, इसलिए हम जीएनयू/लिनक्स पर ही टिके रहेंगे।

पता अनुवाद सक्षम करना बिल्कुल भी कठिन नहीं है। सबसे पहले आपको नेट तालिका में 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 का उपयोग करने के अपने पहले प्रयास में, मैं 7Mpps प्रति सर्वर (Xeon E0.8-5v1650) पर लगभग 2Gbit/s का प्रदर्शन प्राप्त करने में सक्षम था। उस समय से, GNU/Linux कर्नेल नेटवर्क स्टैक में कई अलग-अलग अनुकूलन किए गए हैं, एक ही हार्डवेयर पर एक सर्वर का प्रदर्शन 18-19 Mpps पर लगभग 1.8-1.9 Gbit/s तक बढ़ गया है (ये अधिकतम मान थे) , लेकिन एक सर्वर द्वारा संसाधित ट्रैफ़िक वॉल्यूम की मांग बहुत तेज़ी से बढ़ी। परिणामस्वरूप, विभिन्न सर्वरों पर लोड को संतुलित करने के लिए योजनाएं विकसित की गईं, लेकिन इससे प्रदान की गई सेवाओं की गुणवत्ता को स्थापित करने, बनाए रखने और बनाए रखने की जटिलता बढ़ गई।

एनएफटेबल्स

आजकल, सॉफ़्टवेयर "शिफ्टिंग बैग" में एक फैशनेबल चलन DPDK और XDP का उपयोग है। इस विषय पर बहुत सारे लेख लिखे गए हैं, कई अलग-अलग भाषण दिए गए हैं, और वाणिज्यिक उत्पाद सामने आ रहे हैं (उदाहरण के लिए, वासएक्सपर्ट्स से SKAT)। लेकिन टेलीकॉम ऑपरेटरों के सीमित प्रोग्रामिंग संसाधनों को देखते हुए, इन रूपरेखाओं के आधार पर अपने दम पर कोई भी "उत्पाद" बनाना काफी समस्याग्रस्त है। भविष्य में ऐसे समाधान को संचालित करना अधिक कठिन होगा; विशेष रूप से, निदान उपकरण विकसित करने होंगे। उदाहरण के लिए, DPDK के साथ मानक tcpdump ऐसे ही काम नहीं करेगा, और यह XDP का उपयोग करके तारों पर वापस भेजे गए पैकेटों को "देख" नहीं पाएगा। उपयोगकर्ता-स्थान पर पैकेट फ़ॉरवर्डिंग को आउटपुट करने के लिए नई तकनीकों के बारे में सभी चर्चाओं के बीच, उन पर किसी का ध्यान नहीं गया रिपोर्टों и लेख पाब्लो नीरा अयुसो, आईपीटेबल्स मेंटेनर, एनएफटीएबल्स में फ्लो ऑफलोडिंग के विकास के बारे में। आइए इस तंत्र को अधिक विस्तार से देखें।

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

विन्यास

इस फ़ंक्शन का उपयोग करने के लिए हमें चाहिए:

ताजी गिरी का प्रयोग करें। इस तथ्य के बावजूद कि कार्यक्षमता स्वयं कर्नेल 4.16 में दिखाई देती है, काफी लंबे समय तक यह बहुत "कच्ची" थी और नियमित रूप से कर्नेल घबराहट का कारण बनती थी। दिसंबर 2019 के आसपास सब कुछ स्थिर हो गया, जब एलटीएस कर्नेल 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;
        }
}

वास्तव में, वह संपूर्ण सेटअप है। अब सभी टीसीपी/यूडीपी ट्रैफिक फास्टनैट टेबल में आ जाएंगे और बहुत तेजी से संसाधित होंगे।

निष्कर्ष

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

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

मुझे उम्मीद है कि यह सामग्री अपने सर्वर के प्रदर्शन को बेहतर बनाने की कोशिश कर रहे नेटवर्क इंजीनियरों के लिए उपयोगी होगी।

स्रोत: www.habr.com

Linux में तेज़ रूटिंग और NAT

एक छोटा सा इतिहास

IPTables

एनएफटेबल्स

विन्यास

निष्कर्ष

एक टिप्पणी जोड़ें उत्तर रद्द