სწრაფი მარშრუტიზაცია და NAT Linux-ში

რადგან IPv4 მისამართები ამოიწურება, ბევრი სატელეკომუნიკაციო ოპერატორი დგება საჭიროების წინაშე, მიაწოდოს კლიენტებს ქსელში წვდომა მისამართების თარგმნის გამოყენებით. ამ სტატიაში მე გეტყვით, თუ როგორ შეგიძლიათ მიიღოთ Carrier Grade NAT შესრულება სასაქონლო სერვერებზე.

პატარა ისტორიის

IPv4 მისამართის სივრცის ამოწურვის თემა ახალი აღარ არის. რაღაც მომენტში RIPE-ში გაჩნდა მოლოდინის სიები, შემდეგ გაჩნდა ბირჟები, რომლებზეც ივაჭრებოდა მისამართების ბლოკები და გაფორმდა გარიგებები მათ იჯარაზე. თანდათან ტელეკომის ოპერატორებმა დაიწყეს ინტერნეტთან წვდომის სერვისების მიწოდება მისამართისა და პორტის თარგმანის გამოყენებით. ზოგიერთმა ვერ მოახერხა საკმარისი მისამართების მოპოვება თითოეული აბონენტისთვის „თეთრი“ მისამართის გასაცემად, ზოგმა კი ფულის დაზოგვა დაიწყო მეორად ბაზარზე მისამართების შეძენაზე უარის თქმით. ქსელური აღჭურვილობის მწარმოებლებმა მხარი დაუჭირეს ამ იდეას, რადგან ეს ფუნქცია ჩვეულებრივ მოითხოვს დამატებით გაფართოების მოდულებს ან ლიცენზიებს. მაგალითად, Juniper-ის MX მარშრუტიზატორების ხაზში (უახლესი MX104 და MX204-ის გარდა), შეგიძლიათ შეასრულოთ NAPT ცალკე MS-MIC სერვის ბარათზე, Cisco ASR1k მოითხოვს CGN ლიცენზიას, Cisco ASR9k მოითხოვს ცალკე A9K-ISM-100 მოდულს. და A9K-CGN ლიცენზია -LIC მისთვის. ზოგადად, სიამოვნება ძვირი ჯდება.

IPTables

NAT-ის შესრულების ამოცანა არ საჭიროებს სპეციალიზებულ გამოთვლით რესურსებს, მისი გადაჭრა შესაძლებელია ზოგადი დანიშნულების პროცესორებით, რომლებიც დამონტაჟებულია, მაგალითად, ნებისმიერ სახლის როუტერში. ტელეკომის ოპერატორის მასშტაბით, ამ პრობლემის მოგვარება შესაძლებელია FreeBSD (ipfw/pf) ან GNU/Linux (iptables) სასაქონლო სერვერების გამოყენებით. ჩვენ არ განვიხილავთ FreeBSD-ს, რადგან... მე შევწყვიტე ამ ოპერაციული სისტემის გამოყენება საკმაოდ დიდი ხნის წინ, ასე რომ, ჩვენ დავრჩებით GNU/Linux-ზე.

მისამართის თარგმნის ჩართვა სულაც არ არის რთული. ჯერ უნდა დაარეგისტრიროთ წესი iptables-ში nat ცხრილში:

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

ამ მარტივი მანიპულაციების შემდეგ მიიღება სრულიად მოქმედი დიზაინი, რომელსაც შეუძლია კლიენტის მისამართების დიდი რაოდენობა გარედან აუზში გადააქციოს. თუმცა, ამ გადაწყვეტის შესრულება სასურველს ტოვებს. GNU/Linux-ის NAT-ისთვის გამოყენების ჩემს პირველ მცდელობებში (დაახლოებით 2013 წელს), მე შევძელი მუშაობის დაახლოებით 7 გბიტი/წმ თითო სერვერზე 0.8 მეგაპიქსელი წმ (Xeon E5-1650v2). მას შემდეგ მრავალი განსხვავებული ოპტიმიზაცია გაკეთდა GNU/Linux-ის ბირთვის ქსელის სტეკში, ერთი სერვერის მუშაობა იმავე აპარატურაზე გაიზარდა თითქმის 18-19 გბიტ/წმ-მდე 1.8-1.9 Mpps (ეს იყო მაქსიმალური მნიშვნელობები) , მაგრამ ერთი სერვერის მიერ დამუშავებული ტრაფიკის მოცულობაზე მოთხოვნა ბევრად უფრო სწრაფად გაიზარდა. შედეგად, შემუშავდა სქემები სხვადასხვა სერვერებზე დატვირთვის დასაბალანსებლად, მაგრამ ამ ყველაფერმა გაზარდა მოწოდებული სერვისების დაყენების, შენარჩუნებისა და ხარისხის შენარჩუნების სირთულე.

NF მაგიდები

დღესდღეობით, მოდური ტენდენცია პროგრამული უზრუნველყოფის "გაცვლის ჩანთებში" არის DPDK და XDP გამოყენება. ამ თემაზე ბევრი სტატია დაიწერა, ბევრი სხვადასხვა გამოსვლა გამოვიდა და ჩნდება კომერციული პროდუქტები (მაგალითად, SKAT VasExperts-ისგან). მაგრამ სატელეკომუნიკაციო ოპერატორების შეზღუდული პროგრამირების რესურსების გათვალისწინებით, საკმაოდ პრობლემურია ამ ჩარჩოებზე დაფუძნებული რაიმე „პროდუქტის“ შექმნა საკუთარ თავზე. მომავალში ასეთი გადაწყვეტის ფუნქციონირება გაცილებით რთული იქნება, კერძოდ, დიაგნოსტიკური საშუალებების შემუშავება იქნება საჭირო. მაგალითად, სტანდარტული tcpdump DPDK-ით არ იმუშავებს ასე და ვერ „იხილავს“ სადენებში გაგზავნილ პაკეტებს XDP-ის გამოყენებით. ყველა საუბრის ფონზე ახალი ტექნოლოგიების შესახებ პაკეტების გადამისამართების მომხმარებლის სივრცეში, ისინი შეუმჩნეველი დარჩნენ იუწყება и მუხლი პაბლო ნეირა აიუსო, iptables-ის შემნარჩუნებელი, nftables-ში ნაკადის გადმოტვირთვის განვითარების შესახებ. მოდით უფრო ახლოს მივხედოთ ამ მექანიზმს.

მთავარი იდეა ისაა, რომ თუ როუტერმა გადასცა პაკეტები ერთი სესიიდან ნაკადის ორივე მიმართულებით (TCP სესია გადავიდა ESTABLISHED მდგომარეობაში), მაშინ არ არის საჭირო ამ სესიის შემდგომი პაკეტების გადატანა Firewall-ის ყველა წესით, რადგან ყველა ეს შემოწმება მაინც დასრულდება პაკეტის მარშრუტიზაციის შემდგომ გადატანით. და ჩვენ ნამდვილად არ გვჭირდება მარშრუტის არჩევა - ჩვენ უკვე ვიცით, რომელ ინტერფეისს და რომელ ჰოსტს უნდა გავუგზავნოთ პაკეტები ამ სესიის ფარგლებში. რჩება მხოლოდ ამ ინფორმაციის შენახვა და მისი გამოყენება მარშრუტიზაციისთვის პაკეტების დამუშავების ადრეულ ეტაპზე. NAT-ის შესრულებისას საჭიროა დამატებით შეინახოთ ინფორმაცია nf_conntrack მოდულის მიერ თარგმნილი მისამართებისა და პორტების ცვლილებების შესახებ. დიახ, რა თქმა უნდა, ამ შემთხვევაში სხვადასხვა პოლიციელები და სხვა ინფორმაცია და სტატისტიკური წესები iptables-ში წყვეტს მუშაობას, მაგრამ ცალკე მდგარი NAT-ის ან, მაგალითად, საზღვრის ამოცანის ფარგლებში, ეს არც ისე მნიშვნელოვანია, რადგან სერვისები ნაწილდება მოწყობილობებზე.

კონფიგურაცია

ამ ფუნქციის გამოსაყენებლად გვჭირდება:

• გამოიყენეთ ახალი ბირთვი. იმისდა მიუხედავად, რომ ფუნქციონალობა თავად გამოჩნდა ბირთვში 4.16, საკმაოდ დიდი ხნის განმავლობაში ის ძალიან "ნედლი" იყო და რეგულარულად იწვევდა ბირთვის პანიკას. ყველაფერი დასტაბილურდა 2019 წლის დეკემბერში, როდესაც გამოვიდა LTS ბირთვები 4.19.90 და 5.4.5.
• გადაწერეთ iptables წესები nftables ფორმატში nftables-ის საკმაოდ უახლესი ვერსიის გამოყენებით. მუშაობს ზუსტად 0.9.0 ვერსიაში

თუ პირველ პუნქტთან პრინციპში ყველაფერი ნათელია, მთავარია არ დაგავიწყდეს აწყობის დროს მოდულის კონფიგურაციაში ჩართვა (CONFIG_NFT_FLOW_OFFLOAD=m), მაშინ მეორე პუნქტი მოითხოვს განმარტებას. nftables წესები აღწერილია სრულიად განსხვავებულად, ვიდრე iptables-ში. დოკუმენტაცია ავლენს თითქმის ყველა პუნქტს, არის ასევე განსაკუთრებული გადამყვანები წესები iptable-დან nftable-მდე. ამიტომ, მე მხოლოდ NAT-ის დაყენების და flow offload-ის მაგალითს მოვიყვან. მაგალითად, პატარა ლეგენდა: , - ეს არის ქსელის ინტერფეისები, რომლებითაც გადის ტრაფიკი; სინამდვილეში შეიძლება იყოს ორზე მეტი. , — „თეთრი“ მისამართების დიაპაზონის საწყისი და დასასრული მისამართი.

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 ტრაფიკი მოხვდება fastnat ცხრილში და დამუშავდება ბევრად უფრო სწრაფად.

დასკვნები

იმის გასაგებად, თუ რამდენად სწრაფია ეს, მე დავამაგრებ დატვირთვის სკრინშოტს ორ რეალურ სერვერზე, იგივე აპარატურით (Xeon E5-1650v2), იდენტურად კონფიგურირებული, იგივე Linux ბირთვის გამოყენებით, მაგრამ ასრულებს NAT-ს iptables-ში. (NAT4) და nftable-ებში (NAT5).

სკრინშოტში არ არის პაკეტების გრაფიკი წამში, მაგრამ ამ სერვერების დატვირთვის პროფილში პაკეტის საშუალო ზომაა დაახლოებით 800 ბაიტი, ასე რომ, მნიშვნელობები აღწევს 1.5 მეგაპიქსამდე. როგორც ხედავთ, nftables სერვერს აქვს შესრულების უზარმაზარი რეზერვი. ამჟამად, ეს სერვერი ამუშავებს 30 გბიტ/წმ-მდე 3 მეგაპიტ/წმ სიჩქარით და აშკარად შეუძლია დააკმაყოფილოს ქსელის ფიზიკური შეზღუდვა 40 გბიტი/წმ, ხოლო აქვს CPU თავისუფალი რესურსები.

ვიმედოვნებ, რომ ეს მასალა სასარგებლო იქნება ქსელის ინჟინრებისთვის, რომლებიც ცდილობენ გააუმჯობესონ თავიანთი სერვერების მუშაობა.

წყარო: www.habr.com