ಲಿನಕ್ಸ್‌ನಲ್ಲಿ ವೇಗದ ರೂಟಿಂಗ್ ಮತ್ತು 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 ನಲ್ಲಿ ಸುಮಾರು 0.8Gbit/s ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪಡೆಯಲು ಸಾಧ್ಯವಾಯಿತು (Xeon E5-1650v2). ಆ ಸಮಯದಿಂದ, GNU/Linux ಕರ್ನಲ್ ನೆಟ್‌ವರ್ಕ್ ಸ್ಟಾಕ್‌ನಲ್ಲಿ ಅನೇಕ ವಿಭಿನ್ನ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳನ್ನು ಮಾಡಲಾಗಿದೆ, ಅದೇ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿನ ಒಂದು ಸರ್ವರ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಯು 18-19 Mpps ನಲ್ಲಿ ಸುಮಾರು 1.8-1.9 Gbit/s ಗೆ ಹೆಚ್ಚಾಗಿದೆ (ಇವುಗಳು ಗರಿಷ್ಠ ಮೌಲ್ಯಗಳಾಗಿವೆ) , ಆದರೆ ಒಂದು ಸರ್ವರ್‌ನಿಂದ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾದ ಟ್ರಾಫಿಕ್ ಪರಿಮಾಣದ ಬೇಡಿಕೆಯು ಹೆಚ್ಚು ವೇಗವಾಗಿ ಬೆಳೆಯಿತು. ಪರಿಣಾಮವಾಗಿ, ವಿವಿಧ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಲೋಡ್ ಅನ್ನು ಸಮತೋಲನಗೊಳಿಸಲು ಯೋಜನೆಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ, ಆದರೆ ಇವೆಲ್ಲವೂ ಒದಗಿಸಿದ ಸೇವೆಗಳ ಗುಣಮಟ್ಟವನ್ನು ಹೊಂದಿಸುವ, ನಿರ್ವಹಿಸುವ ಮತ್ತು ನಿರ್ವಹಿಸುವ ಸಂಕೀರ್ಣತೆಯನ್ನು ಹೆಚ್ಚಿಸಿತು.

NTFables

ಇತ್ತೀಚಿನ ದಿನಗಳಲ್ಲಿ, ಸಾಫ್ಟ್ವೇರ್ "ಶಿಫ್ಟಿಂಗ್ ಬ್ಯಾಗ್ಸ್" ನಲ್ಲಿ ಫ್ಯಾಶನ್ ಪ್ರವೃತ್ತಿಯು DPDK ಮತ್ತು XDP ಯ ಬಳಕೆಯಾಗಿದೆ. ಈ ವಿಷಯದ ಬಗ್ಗೆ ಬಹಳಷ್ಟು ಲೇಖನಗಳನ್ನು ಬರೆಯಲಾಗಿದೆ, ಅನೇಕ ವಿಭಿನ್ನ ಭಾಷಣಗಳನ್ನು ಮಾಡಲಾಗಿದೆ ಮತ್ತು ವಾಣಿಜ್ಯ ಉತ್ಪನ್ನಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತಿವೆ (ಉದಾಹರಣೆಗೆ, VasExperts ನಿಂದ SKAT). ಆದರೆ ಟೆಲಿಕಾಂ ಆಪರೇಟರ್‌ಗಳ ಸೀಮಿತ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನೀಡಿದರೆ, ಈ ಚೌಕಟ್ಟುಗಳ ಆಧಾರದ ಮೇಲೆ ಯಾವುದೇ "ಉತ್ಪನ್ನ" ಅನ್ನು ನಿಮ್ಮದೇ ಆದ ಮೇಲೆ ರಚಿಸುವುದು ಸಾಕಷ್ಟು ಸಮಸ್ಯಾತ್ಮಕವಾಗಿದೆ. ಭವಿಷ್ಯದಲ್ಲಿ ಅಂತಹ ಪರಿಹಾರವನ್ನು ನಿರ್ವಹಿಸುವುದು ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ; ನಿರ್ದಿಷ್ಟವಾಗಿ, ರೋಗನಿರ್ಣಯದ ಸಾಧನಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಬೇಕಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, DPDK ಯೊಂದಿಗಿನ ಸ್ಟ್ಯಾಂಡರ್ಡ್ tcpdump ಅದರಂತೆಯೇ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ ಮತ್ತು XDP ಅನ್ನು ಬಳಸಿಕೊಂಡು ತಂತಿಗಳಿಗೆ ಕಳುಹಿಸಲಾದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು "ನೋಡುವುದಿಲ್ಲ". ಪ್ಯಾಕೆಟ್ ಫಾರ್ವರ್ಡ್ ಮಾಡುವಿಕೆಯನ್ನು ಯೂಸರ್-ಸ್ಪೇಸ್‌ಗೆ ಔಟ್‌ಪುಟ್ ಮಾಡಲು ಹೊಸ ತಂತ್ರಜ್ಞಾನಗಳ ಕುರಿತು ಎಲ್ಲಾ ಚರ್ಚೆಗಳ ನಡುವೆ, ಅವರು ಗಮನಿಸಲಿಲ್ಲ ವರದಿಗಳು и ಲೇಖನಗಳು ಪ್ಯಾಬ್ಲೋ ನೀರಾ ಆಯುಸೊ, iptables ನಿರ್ವಾಹಕರು, nftables ನಲ್ಲಿ ಫ್ಲೋ ಆಫ್‌ಲೋಡಿಂಗ್ ಅಭಿವೃದ್ಧಿಯ ಬಗ್ಗೆ. ಈ ಕಾರ್ಯವಿಧಾನವನ್ನು ಹತ್ತಿರದಿಂದ ನೋಡೋಣ.

ಮುಖ್ಯ ಆಲೋಚನೆಯೆಂದರೆ, ರೂಟರ್ ಒಂದು ಸೆಷನ್‌ನಿಂದ ಹರಿವಿನ ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ರವಾನಿಸಿದರೆ (TCP ಸೆಷನ್ ಸ್ಥಾಪಿತ ಸ್ಥಿತಿಗೆ ಹೋಯಿತು), ನಂತರ ಈ ಅಧಿವೇಶನದ ನಂತರದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಎಲ್ಲಾ ಫೈರ್‌ವಾಲ್ ನಿಯಮಗಳ ಮೂಲಕ ರವಾನಿಸುವ ಅಗತ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ರೂಟಿಂಗ್‌ಗೆ ವರ್ಗಾಯಿಸುವುದರೊಂದಿಗೆ ಈ ಎಲ್ಲಾ ಚೆಕ್‌ಗಳು ಇನ್ನೂ ಕೊನೆಗೊಳ್ಳುತ್ತವೆ. ಮತ್ತು ನಾವು ನಿಜವಾಗಿಯೂ ಮಾರ್ಗವನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ - ಈ ಸೆಷನ್‌ನಲ್ಲಿ ನಾವು ಯಾವ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಯಾವ ಹೋಸ್ಟ್‌ಗೆ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಕಳುಹಿಸಬೇಕು ಎಂದು ನಮಗೆ ಈಗಾಗಲೇ ತಿಳಿದಿದೆ. ಪ್ಯಾಕೆಟ್ ಸಂಸ್ಕರಣೆಯ ಆರಂಭಿಕ ಹಂತದಲ್ಲಿ ಈ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಮತ್ತು ರೂಟಿಂಗ್‌ಗಾಗಿ ಬಳಸುವುದು ಮಾತ್ರ ಉಳಿದಿದೆ. NAT ಅನ್ನು ನಿರ್ವಹಿಸುವಾಗ, nf_conntrack ಮಾಡ್ಯೂಲ್‌ನಿಂದ ಅನುವಾದಿಸಲಾದ ವಿಳಾಸಗಳು ಮತ್ತು ಪೋರ್ಟ್‌ಗಳಲ್ಲಿನ ಬದಲಾವಣೆಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಹೆಚ್ಚುವರಿಯಾಗಿ ಸಂಗ್ರಹಿಸುವುದು ಅವಶ್ಯಕ. ಹೌದು, ಸಹಜವಾಗಿ, ಈ ಸಂದರ್ಭದಲ್ಲಿ ಐಪ್ಟೇಬಲ್‌ಗಳಲ್ಲಿನ ವಿವಿಧ ಪೋಲೀಸರ್‌ಗಳು ಮತ್ತು ಇತರ ಮಾಹಿತಿ ಮತ್ತು ಅಂಕಿಅಂಶಗಳ ನಿಯಮಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತವೆ, ಆದರೆ ಪ್ರತ್ಯೇಕ ನಿಂತಿರುವ NAT ಕಾರ್ಯದ ಚೌಕಟ್ಟಿನೊಳಗೆ ಅಥವಾ, ಉದಾಹರಣೆಗೆ, ಗಡಿ, ಇದು ಅಷ್ಟು ಮುಖ್ಯವಲ್ಲ, ಏಕೆಂದರೆ ಸೇವೆಗಳು ಸಾಧನಗಳಾದ್ಯಂತ ವಿತರಿಸಲಾಗುತ್ತದೆ.

ಸಂರಚನೆ

ಈ ಕಾರ್ಯವನ್ನು ಬಳಸಲು ನಮಗೆ ಅಗತ್ಯವಿದೆ:

• ತಾಜಾ ಕರ್ನಲ್ ಬಳಸಿ. ಕಾರ್ಯವು ಸ್ವತಃ ಕರ್ನಲ್ 4.16 ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡಿದ್ದರೂ ಸಹ, ದೀರ್ಘಕಾಲದವರೆಗೆ ಅದು ತುಂಬಾ "ಕಚ್ಚಾ" ಮತ್ತು ನಿಯಮಿತವಾಗಿ ಕರ್ನಲ್ ಪ್ಯಾನಿಕ್ಗೆ ಕಾರಣವಾಯಿತು. LTS ಕರ್ನಲ್‌ಗಳು 2019 ಮತ್ತು 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