لینکس میں تیز روٹنگ اور NAT

جیسے جیسے IPv4 ایڈریس ختم ہو جاتے ہیں، بہت سے ٹیلی کام آپریٹرز کو ایڈریس ٹرانسلیشن کا استعمال کرتے ہوئے اپنے کلائنٹس کو نیٹ ورک تک رسائی فراہم کرنے کی ضرورت کا سامنا کرنا پڑتا ہے۔ اس مضمون میں میں آپ کو بتاؤں گا کہ آپ کموڈٹی سرورز پر کیریئر گریڈ NAT کارکردگی کیسے حاصل کر سکتے ہیں۔

تاریخ کا ایک تھوڑا سا

IPv4 ایڈریس کی جگہ ختم ہونے کا موضوع اب نیا نہیں ہے۔ کسی وقت، RIPE میں انتظار کی فہرستیں نمودار ہوئیں، پھر تبادلے سامنے آئے جن پر پتوں کے بلاکس کی تجارت کی گئی اور انہیں لیز پر دینے کے لیے سودے کیے گئے۔ آہستہ آہستہ، ٹیلی کام آپریٹرز نے ایڈریس اور پورٹ ٹرانسلیشن کا استعمال کرتے ہوئے انٹرنیٹ تک رسائی کی خدمات فراہم کرنا شروع کر دیں۔ کچھ نے ہر سبسکرائبر کو "سفید" ایڈریس جاری کرنے کے لیے کافی پتے حاصل کرنے کا انتظام نہیں کیا، جب کہ دوسروں نے سیکنڈری مارکیٹ میں پتے خریدنے سے انکار کر کے پیسے بچانے شروع کر دیے۔ نیٹ ورک کے سازوسامان کے مینوفیکچررز نے اس خیال کی حمایت کی، کیونکہ اس فعالیت کے لیے عام طور پر اضافی ایکسٹینشن ماڈیولز یا لائسنس کی ضرورت ہوتی ہے۔ مثال کے طور پر، MX راؤٹرز کی Juniper کی لائن میں (جدید ترین MX104 اور MX204 کے علاوہ)، آپ ایک علیحدہ MS-MIC سروس کارڈ پر NAPT انجام دے سکتے ہیں، Cisco ASR1k کو CGN لائسنس درکار ہے، Cisco ASR9k کو الگ A9K-ISM-100 ماڈیول کی ضرورت ہے۔ اور اسے A9K-CGN لائسنس -LIC۔ عام طور پر، خوشی بہت پیسہ خرچ کرتی ہے.

آئی ٹی ٹیبلز

NAT کو انجام دینے کے لیے مخصوص کمپیوٹنگ وسائل کی ضرورت نہیں ہوتی؛ اسے عام مقصد کے پروسیسرز کے ذریعے حل کیا جا سکتا ہے، جو کہ کسی بھی ہوم روٹر میں انسٹال ہوتے ہیں۔ ٹیلی کام آپریٹر کے پیمانے پر، یہ مسئلہ FreeBSD (ipfw/pf) یا GNU/Linux (iptables) چلانے والے کموڈٹی سرورز کے ذریعے حل کیا جا سکتا ہے۔ ہم FreeBSD پر غور نہیں کریں گے، کیونکہ... میں نے کافی عرصہ پہلے اس OS کو استعمال کرنا بند کر دیا تھا، لہذا ہم GNU/Linux پر قائم رہیں گے۔

ایڈریس ٹرانسلیشن کو فعال کرنا بالکل مشکل نہیں ہے۔ پہلے آپ کو نیٹ ٹیبل میں 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 کا استعمال ہے۔ اس موضوع پر بہت سارے مضامین لکھے گئے ہیں، بہت سی مختلف تقریریں کی گئی ہیں، اور تجارتی مصنوعات ظاہر ہو رہی ہیں (مثال کے طور پر، 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