ਲੀਨਕਸ ਵਿੱਚ ਤੇਜ਼ ਰਾਊਟਿੰਗ ਅਤੇ 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 ਨਾਲ ਜੁੜੇ ਰਹਾਂਗੇ।

ਪਤੇ ਦੇ ਅਨੁਵਾਦ ਨੂੰ ਸਮਰੱਥ ਕਰਨਾ ਬਿਲਕੁਲ ਵੀ ਮੁਸ਼ਕਲ ਨਹੀਂ ਹੈ। ਪਹਿਲਾਂ ਤੁਹਾਨੂੰ 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 ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀਆਂ ਮੇਰੀਆਂ ਪਹਿਲੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਵਿੱਚ, ਮੈਂ ਪ੍ਰਤੀ ਸਰਵਰ (Xeon E7-0.8v5) 1650Mpps 'ਤੇ ਲਗਭਗ 2Gbit/s ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਸੀ। ਉਸ ਸਮੇਂ ਤੋਂ, GNU/Linux ਕਰਨਲ ਨੈੱਟਵਰਕ ਸਟੈਕ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਵੱਖ-ਵੱਖ ਅਨੁਕੂਲਨ ਕੀਤੇ ਗਏ ਹਨ, ਉਸੇ ਹਾਰਡਵੇਅਰ 'ਤੇ ਇੱਕ ਸਰਵਰ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ 18-19 Mpps 'ਤੇ ਲਗਭਗ 1.8-1.9 Gbit/s ਤੱਕ ਵਧ ਗਈ ਹੈ (ਇਹ ਵੱਧ ਤੋਂ ਵੱਧ ਮੁੱਲ ਸਨ) , ਪਰ ਇੱਕ ਸਰਵਰ ਦੁਆਰਾ ਸੰਸਾਧਿਤ ਟ੍ਰੈਫਿਕ ਵਾਲੀਅਮ ਦੀ ਮੰਗ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਵਧੀ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਵੱਖ-ਵੱਖ ਸਰਵਰਾਂ 'ਤੇ ਲੋਡ ਨੂੰ ਸੰਤੁਲਿਤ ਕਰਨ ਲਈ ਯੋਜਨਾਵਾਂ ਵਿਕਸਿਤ ਕੀਤੀਆਂ ਗਈਆਂ ਸਨ, ਪਰ ਇਸ ਸਭ ਨੇ ਪ੍ਰਦਾਨ ਕੀਤੀਆਂ ਸੇਵਾਵਾਂ ਦੀ ਗੁਣਵੱਤਾ ਨੂੰ ਸਥਾਪਤ ਕਰਨ, ਸਾਂਭ-ਸੰਭਾਲ ਕਰਨ ਅਤੇ ਬਣਾਈ ਰੱਖਣ ਦੀ ਗੁੰਝਲਤਾ ਨੂੰ ਵਧਾ ਦਿੱਤਾ।

NFT ਟੇਬਲ

ਅੱਜਕੱਲ੍ਹ, ਸੌਫਟਵੇਅਰ "ਬੈਗ ਬਦਲਣ" ਵਿੱਚ ਇੱਕ ਫੈਸ਼ਨੇਬਲ ਰੁਝਾਨ DPDK ਅਤੇ XDP ਦੀ ਵਰਤੋਂ ਹੈ। ਇਸ ਵਿਸ਼ੇ 'ਤੇ ਬਹੁਤ ਸਾਰੇ ਲੇਖ ਲਿਖੇ ਗਏ ਹਨ, ਬਹੁਤ ਸਾਰੇ ਵੱਖ-ਵੱਖ ਭਾਸ਼ਣ ਦਿੱਤੇ ਗਏ ਹਨ, ਅਤੇ ਵਪਾਰਕ ਉਤਪਾਦ ਦਿਖਾਈ ਦੇ ਰਹੇ ਹਨ (ਉਦਾਹਰਣ ਵਜੋਂ, ਵੈਸਐਕਸਪਰਟਸ ਤੋਂ SKAT). ਪਰ ਟੈਲੀਕਾਮ ਓਪਰੇਟਰਾਂ ਦੇ ਸੀਮਤ ਪ੍ਰੋਗਰਾਮਿੰਗ ਸਰੋਤਾਂ ਦੇ ਮੱਦੇਨਜ਼ਰ, ਇਹਨਾਂ ਫਰੇਮਵਰਕ ਦੇ ਅਧਾਰ ਤੇ ਆਪਣੇ ਆਪ ਕੋਈ ਵੀ "ਉਤਪਾਦ" ਬਣਾਉਣਾ ਕਾਫ਼ੀ ਮੁਸ਼ਕਲ ਹੈ। ਭਵਿੱਖ ਵਿੱਚ ਅਜਿਹੇ ਹੱਲ ਨੂੰ ਚਲਾਉਣਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੋਵੇਗਾ; ਖਾਸ ਤੌਰ 'ਤੇ, ਡਾਇਗਨੌਸਟਿਕ ਟੂਲ ਵਿਕਸਤ ਕਰਨੇ ਪੈਣਗੇ। ਉਦਾਹਰਨ ਲਈ, DPDK ਦੇ ਨਾਲ ਸਟੈਂਡਰਡ tcpdump ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ, ਅਤੇ ਇਹ XDP ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਵਾਇਰਾਂ ਨੂੰ ਵਾਪਸ ਭੇਜੇ ਗਏ ਪੈਕੇਟਾਂ ਨੂੰ "ਵੇਖੋ" ਨਹੀਂ ਕਰੇਗਾ। ਯੂਜ਼ਰ-ਸਪੇਸ ਵਿੱਚ ਪੈਕੇਟ ਫਾਰਵਰਡਿੰਗ ਨੂੰ ਆਉਟਪੁੱਟ ਕਰਨ ਲਈ ਨਵੀਆਂ ਤਕਨੀਕਾਂ ਬਾਰੇ ਸਾਰੀਆਂ ਗੱਲਾਂ ਦੇ ਵਿਚਕਾਰ, ਉਹਨਾਂ ਦਾ ਧਿਆਨ ਨਹੀਂ ਗਿਆ ਰਿਪੋਰਟ и ਲੇਖ ਪਾਬਲੋ ਨੀਰਾ ਆਯੂਸੋ, iptables ਮੇਨਟੇਨਰ, nftables ਵਿੱਚ ਫਲੋ ਆਫਲੋਡਿੰਗ ਦੇ ਵਿਕਾਸ ਬਾਰੇ। ਆਉ ਇਸ ਵਿਧੀ ਨੂੰ ਹੋਰ ਵਿਸਥਾਰ ਵਿੱਚ ਵੇਖੀਏ.

ਮੁੱਖ ਵਿਚਾਰ ਇਹ ਹੈ ਕਿ ਜੇਕਰ ਰਾਊਟਰ ਵਹਾਅ ਦੇ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਇੱਕ ਸੈਸ਼ਨ ਤੋਂ ਪੈਕੇਟ ਪਾਸ ਕਰਦਾ ਹੈ (ਟੀਸੀਪੀ ਸੈਸ਼ਨ ਸਥਾਪਤ ਸਥਿਤੀ ਵਿੱਚ ਚਲਾ ਗਿਆ), ਤਾਂ ਇਸ ਸੈਸ਼ਨ ਦੇ ਅਗਲੇ ਪੈਕੇਟ ਨੂੰ ਸਾਰੇ ਫਾਇਰਵਾਲ ਨਿਯਮਾਂ ਦੁਆਰਾ ਪਾਸ ਕਰਨ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਸਾਰੇ ਚੈਕ ਅਜੇ ਵੀ ਪੈਕੇਟ ਨੂੰ ਰੂਟਿੰਗ ਵਿੱਚ ਤਬਦੀਲ ਕੀਤੇ ਜਾਣ ਦੇ ਨਾਲ ਖਤਮ ਹੋ ਜਾਣਗੇ। ਅਤੇ ਸਾਨੂੰ ਅਸਲ ਵਿੱਚ ਇੱਕ ਰੂਟ ਚੁਣਨ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੈ - ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦੇ ਹਾਂ ਕਿ ਇਸ ਸੈਸ਼ਨ ਵਿੱਚ ਸਾਨੂੰ ਕਿਹੜੇ ਇੰਟਰਫੇਸ ਅਤੇ ਕਿਸ ਮੇਜ਼ਬਾਨ ਨੂੰ ਪੈਕੇਟ ਭੇਜਣ ਦੀ ਲੋੜ ਹੈ। ਇਸ ਜਾਣਕਾਰੀ ਨੂੰ ਸਟੋਰ ਕਰਨਾ ਅਤੇ ਪੈਕੇਟ ਪ੍ਰੋਸੈਸਿੰਗ ਦੇ ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ 'ਤੇ ਰੂਟਿੰਗ ਲਈ ਇਸਦੀ ਵਰਤੋਂ ਕਰਨਾ ਬਾਕੀ ਹੈ। 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