Linux માં ઝડપી રૂટીંગ અને 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 નો ઉપયોગ કરવાના મારા પ્રથમ પ્રયાસોમાં, હું સર્વર દીઠ 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