🥇 लिनक्समध्ये जलद राउटिंग आणि NAT

IPv4 पत्ते संपुष्टात आल्याने, अनेक दूरसंचार ऑपरेटरना त्यांच्या क्लायंटना अॅड्रेस ट्रान्सलेशन वापरून नेटवर्क ऍक्सेस प्रदान करण्याची गरज भासते. या लेखात मी तुम्हाला कमोडिटी सर्व्हरवर कॅरियर ग्रेड NAT कामगिरी कशी मिळवू शकता ते सांगेन.

इतिहास एक बिट

IPv4 अॅड्रेस स्पेस एक्झोशनचा विषय आता नवीन नाही. काही क्षणी, RIPE मध्ये प्रतीक्षा यादी दिसू लागली, नंतर एक्सचेंजेस उदयास आल्या ज्यावर पत्त्यांच्या ब्लॉक्सची खरेदी-विक्री केली गेली आणि त्यांना भाड्याने देण्याचे सौदे पूर्ण झाले. हळूहळू, दूरसंचार ऑपरेटर पत्ता आणि पोर्ट भाषांतर वापरून इंटरनेट प्रवेश सेवा प्रदान करू लागले. काहींनी प्रत्येक ग्राहकाला “पांढरा” पत्ता जारी करण्यासाठी पुरेसे पत्ते मिळू शकले नाहीत, तर काहींनी दुय्यम बाजारात पत्ते खरेदी करण्यास नकार देऊन पैसे वाचवण्यास सुरुवात केली. नेटवर्क उपकरणांच्या निर्मात्यांनी या कल्पनेचे समर्थन केले, कारण या कार्यक्षमतेसाठी सहसा अतिरिक्त विस्तार मॉड्यूल किंवा परवाने आवश्यक असतात. उदाहरणार्थ, जुनिपरच्या MX राउटरच्या लाइनमध्ये (नवीनतम MX104 आणि MX204 वगळता), तुम्ही वेगळ्या MS-MIC सेवा कार्डवर NAPT करू शकता, Cisco ASR1k ला CGN परवाना आवश्यक आहे, Cisco ASR9k ला वेगळ्या A9K-ISM-100 मॉड्यूलची आवश्यकता आहे. आणि त्याला A9K-CGN परवाना -LIC. सर्वसाधारणपणे, आनंदासाठी खूप पैसे लागतात.

आयपीटीबल

NAT कार्यान्वित करण्यासाठी विशेष संगणकीय संसाधनांची आवश्यकता नसते; हे सामान्य-उद्देश प्रोसेसरद्वारे सोडवले जाऊ शकते, जे स्थापित केले जातात, उदाहरणार्थ, कोणत्याही होम राउटरमध्ये. टेलिकॉम ऑपरेटरच्या स्केलवर, फ्रीबीएसडी (ipfw/pf) किंवा GNU/Linux (iptables) चालवणारे कमोडिटी सर्व्हर वापरून ही समस्या सोडवली जाऊ शकते. आम्ही फ्रीबीएसडीचा विचार करणार नाही, कारण... मी हे 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 पर्यंत वाढली आहे (ही कमाल मूल्ये होती) , परंतु एका सर्व्हरद्वारे प्रक्रिया केलेल्या रहदारीच्या प्रमाणाची मागणी खूप वेगाने वाढली. परिणामी, वेगवेगळ्या सर्व्हरवरील भार संतुलित करण्यासाठी योजना विकसित केल्या गेल्या, परंतु या सर्वांमुळे प्रदान केलेल्या सेवांची स्थापना, देखभाल आणि गुणवत्ता राखण्याची जटिलता वाढली.

एनएफटेबल्स

आजकाल, सॉफ्टवेअर "शिफ्टिंग बॅग" मध्ये एक फॅशनेबल ट्रेंड म्हणजे 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 च्या अगदी अलीकडील आवृत्तीचा वापर करून iptables नियम nftables फॉरमॅटमध्ये पुन्हा लिहा. आवृत्ती 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 पर्यंत प्रक्रिया करतो आणि विनामूल्य CPU संसाधने असताना 40Gbps ची भौतिक नेटवर्क मर्यादा पूर्ण करण्यास स्पष्टपणे सक्षम आहे.

मला आशा आहे की ही सामग्री त्यांच्या सर्व्हरची कार्यक्षमता सुधारण्याचा प्रयत्न करणार्‍या नेटवर्क अभियंत्यांना उपयुक्त ठरेल.

स्त्रोत: www.habr.com

लिनक्समध्ये जलद राउटिंग आणि NAT

इतिहास एक बिट

आयपीटीबल

एनएफटेबल्स

कॉन्फिगरेशन

निकाल

एक टिप्पणी जोडा Отменить ответ