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 ஆக அதிகரித்துள்ளது (இவை அதிகபட்சம் மதிப்புகள்), ஆனால் ஒரு சேவையகத்தால் செயலாக்கப்பட்ட போக்குவரத்து அளவுக்கான தேவை மிக வேகமாக வளர்ந்தது. இதன் விளைவாக, வெவ்வேறு சேவையகங்களில் சுமையை சமப்படுத்த திட்டங்கள் உருவாக்கப்பட்டன, ஆனால் இவை அனைத்தும் வழங்கப்பட்ட சேவைகளின் தரத்தை அமைப்பது, பராமரித்தல் மற்றும் பராமரிப்பது ஆகியவற்றின் சிக்கலை அதிகரித்தது.
NTFables
இப்போதெல்லாம், மென்பொருள் "ஷிஃப்டிங் பைகள்" இல் ஒரு நாகரீகமான போக்கு DPDK மற்றும் XDP பயன்பாடு ஆகும். இந்த தலைப்பில் நிறைய கட்டுரைகள் எழுதப்பட்டுள்ளன, பலவிதமான உரைகள் செய்யப்பட்டுள்ளன, மேலும் வணிக தயாரிப்புகள் தோன்றுகின்றன (எடுத்துக்காட்டாக, VasExperts இலிருந்து SKAT). ஆனால் தொலைத்தொடர்பு ஆபரேட்டர்களின் வரையறுக்கப்பட்ட நிரலாக்க வளங்களைப் பொறுத்தவரை, இந்த கட்டமைப்பின் அடிப்படையில் எந்தவொரு "தயாரிப்பையும்" சொந்தமாக உருவாக்குவது மிகவும் சிக்கலானது. எதிர்காலத்தில் அத்தகைய தீர்வை இயக்குவது மிகவும் கடினமாக இருக்கும்; குறிப்பாக, கண்டறியும் கருவிகள் உருவாக்கப்பட வேண்டும். எடுத்துக்காட்டாக, DPDK உடனான நிலையான tcpdump அது போல் இயங்காது, மேலும் இது XDPஐப் பயன்படுத்தி கம்பிகளுக்கு அனுப்பப்பட்ட பாக்கெட்டுகளை "பார்க்காது". பாக்கெட் ஃபார்வர்டிங்கை யூசர்-ஸ்பேஸுக்கு வெளியிடுவதற்கான புதிய தொழில்நுட்பங்களைப் பற்றிய அனைத்து பேச்சுகளுக்கும் மத்தியில், அவை கவனிக்கப்படாமல் போய்விட்டது.
முக்கிய யோசனை என்னவென்றால், திசைவி ஒரு அமர்விலிருந்து பாக்கெட்டுகளை ஓட்டத்தின் இரு திசைகளிலும் அனுப்பியிருந்தால் (TCP அமர்வு நிறுவப்பட்ட நிலைக்குச் சென்றது), பின்னர் இந்த அமர்வின் அடுத்தடுத்த பாக்கெட்டுகளை அனைத்து ஃபயர்வால் விதிகள் மூலம் அனுப்ப வேண்டிய அவசியமில்லை. இந்த காசோலைகள் அனைத்தும் பாக்கெட் ரூட்டிங்கிற்கு மேலும் மாற்றப்படும் உடன் முடிவடையும். நாங்கள் உண்மையில் ஒரு வழியைத் தேர்ந்தெடுக்க வேண்டியதில்லை - இந்த அமர்விற்குள் எந்த இடைமுகம் மற்றும் எந்த ஹோஸ்டுக்கு பாக்கெட்டுகளை அனுப்ப வேண்டும் என்பது எங்களுக்கு முன்பே தெரியும். இந்தத் தகவலைச் சேமித்து, பாக்கெட் செயலாக்கத்தின் ஆரம்ப கட்டத்தில் ரூட்டிங் செய்வதற்குப் பயன்படுத்துவது மட்டுமே எஞ்சியுள்ளது. NAT ஐச் செய்யும்போது, nf_conntrack தொகுதி மூலம் மொழிபெயர்க்கப்பட்ட முகவரிகள் மற்றும் போர்ட்களில் ஏற்படும் மாற்றங்கள் பற்றிய தகவலை கூடுதலாகச் சேமிப்பது அவசியம். ஆம், நிச்சயமாக, இந்த விஷயத்தில் பல்வேறு போலீஸ்காரர்கள் மற்றும் iptables இல் உள்ள பிற தகவல்கள் மற்றும் புள்ளிவிவர விதிகள் வேலை செய்வதை நிறுத்துகின்றன, ஆனால் ஒரு தனி NAT அல்லது, எடுத்துக்காட்டாக, ஒரு எல்லையின் பணியின் கட்டமைப்பிற்குள், இது அவ்வளவு முக்கியமல்ல, ஏனெனில் சேவைகள் சாதனங்கள் முழுவதும் விநியோகிக்கப்படுகின்றன.
கட்டமைப்பு
இந்த செயல்பாட்டைப் பயன்படுத்த நமக்குத் தேவை:
- புதிய கர்னலைப் பயன்படுத்தவும். செயல்பாடு கர்னல் 4.16 இல் தோன்றிய போதிலும், நீண்ட காலமாக இது மிகவும் "பச்சையாக" இருந்தது மற்றும் வழக்கமாக கர்னல் பீதியை ஏற்படுத்தியது. எல்டிஎஸ் கர்னல்கள் 2019 மற்றும் 4.19.90 வெளியிடப்பட்ட 5.4.5 டிசம்பரில் அனைத்தும் உறுதிப்படுத்தப்பட்டன.
- nftables இன் மிகச் சமீபத்திய பதிப்பைப் பயன்படுத்தி iptables விதிகளை nftables வடிவத்தில் மீண்டும் எழுதவும். பதிப்பு 0.9.0 இல் சரியாக வேலை செய்கிறது
கொள்கையளவில் அனைத்தும் முதல் புள்ளியுடன் தெளிவாக இருந்தால், முக்கிய விஷயம் என்னவென்றால், சட்டசபையின் போது உள்ளமைவில் தொகுதியைச் சேர்க்க மறக்கக்கூடாது (CONFIG_NFT_FLOW_OFFLOAD=m), பின்னர் இரண்டாவது புள்ளிக்கு விளக்கம் தேவை. nftables விதிகள் iptables ஐ விட முற்றிலும் வித்தியாசமாக விவரிக்கப்பட்டுள்ளன.
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