Linuxలో ఫాస్ట్ రూటింగ్ మరియు NAT

IPv4 చిరునామాలు క్షీణించడంతో, చాలా మంది టెలికాం ఆపరేటర్లు తమ క్లయింట్‌లకు చిరునామా అనువాదాన్ని ఉపయోగించి నెట్‌వర్క్ యాక్సెస్‌ను అందించాల్సిన అవసరాన్ని ఎదుర్కొంటున్నారు. కమోడిటీ సర్వర్‌లలో మీరు క్యారియర్ గ్రేడ్ NAT పనితీరును ఎలా పొందవచ్చో ఈ కథనంలో నేను మీకు చెప్తాను.

ఒక బిట్ చరిత్ర

IPv4 చిరునామా ఖాళీ అయిపోయిన అంశం ఇప్పుడు కొత్తది కాదు. ఏదో ఒక సమయంలో, వెయిటింగ్ లిస్ట్‌లు RIPEలో కనిపించాయి, తర్వాత ఎక్స్ఛేంజీలు ఏవి అడ్రస్‌ల బ్లాక్‌లు వర్తకం చేయబడ్డాయి మరియు వాటిని లీజుకు తీసుకోవడానికి ఒప్పందాలు జరిగాయి. క్రమంగా, టెలికాం ఆపరేటర్లు చిరునామా మరియు పోర్ట్ అనువాదాన్ని ఉపయోగించి ఇంటర్నెట్ యాక్సెస్ సేవలను అందించడం ప్రారంభించారు. కొంతమంది ప్రతి చందాదారునికి "తెలుపు" చిరునామాను జారీ చేయడానికి తగినంత చిరునామాలను పొందలేకపోయారు, మరికొందరు ద్వితీయ మార్కెట్లో చిరునామాలను కొనుగోలు చేయడానికి నిరాకరించడం ద్వారా డబ్బు ఆదా చేయడం ప్రారంభించారు. నెట్వర్క్ పరికరాల తయారీదారులు ఈ ఆలోచనకు మద్దతు ఇచ్చారు, ఎందుకంటే ఈ కార్యాచరణకు సాధారణంగా అదనపు పొడిగింపు మాడ్యూల్స్ లేదా లైసెన్స్‌లు అవసరం. ఉదాహరణకు, జునిపెర్ యొక్క MX రూటర్‌ల లైన్‌లో (తాజా MX104 మరియు MX204 మినహా), మీరు ప్రత్యేక MS-MIC సర్వీస్ కార్డ్‌లో NAPTని నిర్వహించవచ్చు, Cisco ASR1kకి CGN లైసెన్స్ అవసరం, Cisco ASR9kకి ప్రత్యేక A9K-ISM-100 మాడ్యూల్ అవసరం మరియు అతనికి A9K-CGN లైసెన్స్ -LIC. సాధారణంగా, ఆనందం చాలా డబ్బు ఖర్చు అవుతుంది.

iptables

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కి పెరిగింది (ఇవి గరిష్ట విలువలు) , కానీ ఒక సర్వర్ ద్వారా ప్రాసెస్ చేయబడిన ట్రాఫిక్ వాల్యూమ్ కోసం డిమాండ్ చాలా వేగంగా పెరిగింది. ఫలితంగా, వివిధ సర్వర్‌లపై లోడ్‌ను సమతుల్యం చేయడానికి పథకాలు అభివృద్ధి చేయబడ్డాయి, అయితే ఇవన్నీ అందించిన సేవల నాణ్యతను ఏర్పాటు చేయడం, నిర్వహించడం మరియు నిర్వహించడం వంటి సంక్లిష్టతను పెంచాయి.

NFటేబుల్స్

ఈ రోజుల్లో, సాఫ్ట్‌వేర్ "షిఫ్టింగ్ బ్యాగ్స్"లో ఫ్యాషన్ ట్రెండ్ DPDK మరియు XDPలను ఉపయోగించడం. ఈ అంశంపై చాలా కథనాలు వ్రాయబడ్డాయి, అనేక విభిన్న ప్రసంగాలు చేయబడ్డాయి మరియు వాణిజ్య ఉత్పత్తులు కనిపిస్తాయి (ఉదాహరణకు, VasExperts నుండి SKAT). కానీ టెలికాం ఆపరేటర్ల యొక్క పరిమిత ప్రోగ్రామింగ్ వనరులను బట్టి, ఈ ఫ్రేమ్‌వర్క్‌ల ఆధారంగా ఏదైనా “ఉత్పత్తి” మీ స్వంతంగా సృష్టించడం చాలా సమస్యాత్మకం. భవిష్యత్తులో అటువంటి పరిష్కారాన్ని ఆపరేట్ చేయడం చాలా కష్టమవుతుంది; ముఖ్యంగా, రోగనిర్ధారణ సాధనాలను అభివృద్ధి చేయాలి. ఉదాహరణకు, DPDKతో ఉన్న ప్రామాణిక tcpdump అలాగే పని చేయదు మరియు ఇది XDPని ఉపయోగించి వైర్‌లకు తిరిగి పంపబడిన ప్యాకెట్‌లను "చూడదు". ప్యాకెట్ ఫార్వార్డింగ్‌ని యూజర్-స్పేస్‌కి అవుట్‌పుట్ చేయడానికి కొత్త టెక్నాలజీల గురించి అన్ని చర్చల మధ్య, అవి గుర్తించబడలేదు నివేదికలు и వ్యాసాలు పాబ్లో నీరా అయుసో, iptables మెయింటెయినర్, nftablesలో ఫ్లో ఆఫ్‌లోడింగ్ అభివృద్ధి గురించి. ఈ యంత్రాంగాన్ని మరింత వివరంగా పరిశీలిద్దాం.

ప్రధాన ఆలోచన ఏమిటంటే, రౌటర్ ఒక సెషన్ నుండి ప్రవాహం యొక్క రెండు దిశలలో ప్యాకెట్లను పాస్ చేసినట్లయితే (TCP సెషన్ స్థాపించబడిన స్థితికి వెళ్లింది), అప్పుడు ఈ సెషన్ యొక్క తదుపరి ప్యాకెట్లను అన్ని ఫైర్‌వాల్ నియమాల ద్వారా పాస్ చేయవలసిన అవసరం లేదు, ఎందుకంటే ప్యాకెట్ రూటింగ్‌కు బదిలీ చేయబడటంతో ఈ తనిఖీలన్నీ ఇప్పటికీ ముగుస్తాయి. మరియు మేము వాస్తవానికి మార్గాన్ని ఎంచుకోవలసిన అవసరం లేదు - ఈ సెషన్‌లో ప్యాకెట్‌లను ఏ ఇంటర్‌ఫేస్‌కి మరియు ఏ హోస్ట్‌కి పంపాలో మాకు ఇప్పటికే తెలుసు. ప్యాకెట్ ప్రాసెసింగ్ యొక్క ప్రారంభ దశలో ఈ సమాచారాన్ని నిల్వ చేయడం మరియు రూటింగ్ కోసం ఉపయోగించడం మాత్రమే మిగిలి ఉంది. NAT చేస్తున్నప్పుడు, nf_conntrack మాడ్యూల్ ద్వారా అనువదించబడిన చిరునామాలు మరియు పోర్ట్‌లలో మార్పుల గురించి సమాచారాన్ని అదనంగా నిల్వ చేయడం అవసరం. అవును, వాస్తవానికి, ఈ సందర్భంలో వివిధ పోలీసులు మరియు ఇతర సమాచారం మరియు iptablesలోని గణాంక నియమాలు పనిచేయడం మానేస్తాయి, కానీ ప్రత్యేక స్టాండింగ్ NAT యొక్క విధి యొక్క చట్రంలో లేదా, ఉదాహరణకు, సరిహద్దు, ఇది అంత ముఖ్యమైనది కాదు, ఎందుకంటే సేవలు పరికరాల అంతటా పంపిణీ చేయబడతాయి.

ఆకృతీకరణ

ఈ ఫంక్షన్‌ను ఉపయోగించడానికి మనకు ఇది అవసరం:

• తాజా కెర్నల్ ఉపయోగించండి. ఫంక్షనాలిటీ కెర్నల్ 4.16లో కనిపించినప్పటికీ, చాలా కాలం పాటు ఇది చాలా “ముడి”గా ఉంది మరియు క్రమం తప్పకుండా కెర్నల్ భయాందోళనలకు కారణమైంది. LTS కెర్నలు 2019 మరియు 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), ఒకే లైనక్స్ కెర్నల్‌ను ఉపయోగించి, ఒకే విధంగా కాన్ఫిగర్ చేయబడి, ఐప్టేబుల్స్‌లో NATని నిర్వహిస్తాను. (NAT4) మరియు nftablesలో (NAT5).

స్క్రీన్‌షాట్‌లో సెకనుకు ప్యాకెట్‌ల గ్రాఫ్ లేదు, కానీ ఈ సర్వర్‌ల లోడ్ ప్రొఫైల్‌లో సగటు ప్యాకెట్ పరిమాణం సుమారు 800 బైట్లు ఉంటుంది, కాబట్టి విలువలు 1.5Mpps వరకు చేరుకుంటాయి. మీరు చూడగలిగినట్లుగా, nftables ఉన్న సర్వర్ భారీ పనితీరు నిల్వను కలిగి ఉంది. ప్రస్తుతం, ఈ సర్వర్ 30Mpps వద్ద 3Gbit/s వరకు ప్రాసెస్ చేస్తుంది మరియు ఉచిత CPU వనరులను కలిగి ఉండగా, 40Gbps భౌతిక నెట్‌వర్క్ పరిమితిని స్పష్టంగా చేరుకోగలదు.

వారి సర్వర్‌ల పనితీరును మెరుగుపరచడానికి ప్రయత్నిస్తున్న నెట్‌వర్క్ ఇంజనీర్‌లకు ఈ విషయం ఉపయోగకరంగా ఉంటుందని నేను ఆశిస్తున్నాను.

మూలం: www.habr.com