লিনাক্সে দ্রুত রাউটিং এবং NAT

IPv4 অ্যাড্রেসগুলি বন্ধ হয়ে যাওয়ায়, অনেক টেলিকম অপারেটর তাদের ক্লায়েন্টদের ঠিকানা অনুবাদ ব্যবহার করে নেটওয়ার্ক অ্যাক্সেস প্রদান করার প্রয়োজনের সম্মুখীন হয়। এই নিবন্ধে আমি আপনাকে বলব কিভাবে আপনি পণ্য সার্ভারে ক্যারিয়ার গ্রেড NAT কর্মক্ষমতা পেতে পারেন।

ইতিহাস একটি বিট

IPv4 অ্যাড্রেস স্পেস এক্সাউসশনের বিষয়টি আর নতুন নয়। কিছু সময়ে, RIPE-তে অপেক্ষমাণ তালিকা উপস্থিত হয়, তারপর বিনিময়ের আবির্ভাব ঘটে যার ভিত্তিতে ঠিকানাগুলির ব্লকগুলি লেনদেন করা হয় এবং সেগুলিকে ইজারা দেওয়ার জন্য চুক্তি করা হয়। ধীরে ধীরে, টেলিকম অপারেটররা ঠিকানা এবং পোর্ট অনুবাদ ব্যবহার করে ইন্টারনেট অ্যাক্সেস পরিষেবা সরবরাহ করতে শুরু করে। কেউ কেউ প্রতিটি গ্রাহককে একটি "সাদা" ঠিকানা ইস্যু করার জন্য পর্যাপ্ত ঠিকানা পেতে পরিচালনা করতে পারেনি, অন্যরা সেকেন্ডারি মার্কেটে ঠিকানা ক্রয় করতে অস্বীকার করে অর্থ সঞ্চয় করতে শুরু করে। নেটওয়ার্ক সরঞ্জাম নির্মাতারা এই ধারণা সমর্থন করে, কারণ এই কার্যকারিতার জন্য সাধারণত অতিরিক্ত এক্সটেনশন মডিউল বা লাইসেন্সের প্রয়োজন হয়। উদাহরণস্বরূপ, MX রাউটারগুলির জুনিপারের লাইনে (সর্বশেষ MX104 এবং MX204 ব্যতীত), আপনি একটি পৃথক MS-MIC পরিষেবা কার্ডে NAPT সম্পাদন করতে পারেন, Cisco ASR1k-এর একটি CGN লাইসেন্স প্রয়োজন, Cisco ASR9k-এর জন্য একটি পৃথক A9K-ISM-100 মডিউল প্রয়োজন এবং তার কাছে একটি A9K-CGN লাইসেন্স -LIC। সাধারণভাবে, আনন্দের জন্য অনেক টাকা খরচ হয়।

iptables

NAT সম্পাদনের জন্য বিশেষ কম্পিউটিং সংস্থানগুলির প্রয়োজন হয় না; এটি সাধারণ-উদ্দেশ্য প্রসেসর দ্বারা সমাধান করা যেতে পারে, যা ইনস্টল করা আছে, উদাহরণস্বরূপ, যে কোনও হোম রাউটারে। একটি টেলিকম অপারেটরের স্কেলে, ফ্রিবিএসডি (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 ব্যবহার করার আমার প্রথম প্রচেষ্টায়, আমি সার্ভার প্রতি 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-এ ফ্লো অফলোডিংয়ের বিকাশ সম্পর্কে। আসুন এই প্রক্রিয়াটি ঘনিষ্ঠভাবে দেখে নেওয়া যাক।

মূল ধারণা হল যে রাউটার যদি প্রবাহের উভয় দিকে একটি সেশন থেকে প্যাকেট পাস করে (টিসিপি সেশনটি স্থাপিত অবস্থায় চলে যায়), তাহলে ফায়ারওয়ালের সমস্ত নিয়মের মাধ্যমে এই সেশনের পরবর্তী প্যাকেটগুলি পাস করার প্রয়োজন নেই, কারণ এই সমস্ত চেক প্যাকেটটি আরও রাউটিংয়ে স্থানান্তরিত হওয়ার সাথে সাথে শেষ হবে। এবং আমাদের আসলে একটি রুট নির্বাচন করার দরকার নেই - আমরা ইতিমধ্যেই জানি কোন ইন্টারফেসে এবং কোন হোস্টে আমাদের এই সেশনের মধ্যে প্যাকেট পাঠাতে হবে। যা অবশিষ্ট থাকে তা হল এই তথ্য সংরক্ষণ করা এবং প্যাকেট প্রক্রিয়াকরণের প্রাথমিক পর্যায়ে রাউটিং করার জন্য এটি ব্যবহার করা। 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 পর্যন্ত প্রসেস করে এবং বিনামূল্যে CPU রিসোর্স থাকাকালীন 40Gbps-এর শারীরিক নেটওয়ার্ক সীমাবদ্ধতা পূরণ করতে স্পষ্টভাবে সক্ষম।

আমি আশা করি এই উপাদানটি তাদের সার্ভারের কর্মক্ষমতা উন্নত করার চেষ্টা করা নেটওয়ার্ক ইঞ্জিনিয়ারদের জন্য উপযোগী হবে।

উত্স: www.habr.com