ਕੁਝ ਸਮਾਂ ਪਹਿਲਾਂ ਮੈਨੂੰ MetalLB ਲਈ ਰੂਟਿੰਗ ਸਥਾਪਤ ਕਰਨ ਦੇ ਇੱਕ ਬਹੁਤ ਹੀ ਅਸਾਧਾਰਨ ਕੰਮ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ ਸੀ। ਸਭ ਕੁਝ ਠੀਕ ਰਹੇਗਾ, ਕਿਉਂਕਿ... ਆਮ ਤੌਰ 'ਤੇ MetalLB ਨੂੰ ਕਿਸੇ ਵਾਧੂ ਕਾਰਵਾਈਆਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ, ਪਰ ਸਾਡੇ ਮਾਮਲੇ ਵਿੱਚ ਸਾਡੇ ਕੋਲ ਇੱਕ ਬਹੁਤ ਹੀ ਸਧਾਰਨ ਨੈੱਟਵਰਕ ਸੰਰਚਨਾ ਦੇ ਨਾਲ ਇੱਕ ਕਾਫ਼ੀ ਵੱਡਾ ਕਲੱਸਟਰ ਹੈ।

ਇਸ ਲੇਖ ਵਿੱਚ ਮੈਂ ਤੁਹਾਨੂੰ ਦੱਸਾਂਗਾ ਕਿ ਤੁਹਾਡੇ ਕਲੱਸਟਰ ਦੇ ਬਾਹਰੀ ਨੈੱਟਵਰਕ ਲਈ ਸਰੋਤ-ਅਧਾਰਿਤ ਅਤੇ ਨੀਤੀ-ਆਧਾਰਿਤ ਰੂਟਿੰਗ ਨੂੰ ਕਿਵੇਂ ਸੰਰਚਿਤ ਕਰਨਾ ਹੈ।

ਮੈਂ MetalLB ਨੂੰ ਸਥਾਪਿਤ ਅਤੇ ਸੰਰਚਿਤ ਕਰਨ ਬਾਰੇ ਵਿਸਥਾਰ ਵਿੱਚ ਨਹੀਂ ਜਾਵਾਂਗਾ, ਕਿਉਂਕਿ ਮੈਂ ਮੰਨਦਾ ਹਾਂ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਕੁਝ ਅਨੁਭਵ ਹੈ। ਮੈਂ ਸਿੱਧੇ ਬਿੰਦੂ 'ਤੇ ਜਾਣ ਦਾ ਸੁਝਾਅ ਦਿੰਦਾ ਹਾਂ, ਅਰਥਾਤ ਰੂਟਿੰਗ ਸਥਾਪਤ ਕਰਨਾ. ਇਸ ਲਈ ਸਾਡੇ ਕੋਲ ਚਾਰ ਕੇਸ ਹਨ:

ਕੇਸ 1: ਜਦੋਂ ਕੋਈ ਸੰਰਚਨਾ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ

ਆਉ ਇੱਕ ਸਧਾਰਨ ਕੇਸ ਨੂੰ ਵੇਖੀਏ.

ਵਾਧੂ ਰੂਟਿੰਗ ਕੌਂਫਿਗਰੇਸ਼ਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ MetalLB ਦੁਆਰਾ ਜਾਰੀ ਕੀਤੇ ਪਤੇ ਤੁਹਾਡੇ ਨੋਡਾਂ ਦੇ ਪਤਿਆਂ ਦੇ ਸਮਾਨ ਸਬਨੈੱਟ ਵਿੱਚ ਹੁੰਦੇ ਹਨ।

ਉਦਾਹਰਨ ਲਈ, ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸਬਨੈੱਟ ਹੈ 192.168.1.0/24, ਇਸ ਵਿੱਚ ਇੱਕ ਰਾਊਟਰ ਹੈ 192.168.1.1, ਅਤੇ ਤੁਹਾਡੇ ਨੋਡ ਪਤੇ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ: 192.168.1.10-30, ਫਿਰ MetalLB ਲਈ ਤੁਸੀਂ ਰੇਂਜ ਨੂੰ ਐਡਜਸਟ ਕਰ ਸਕਦੇ ਹੋ 192.168.1.100-120 ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਉਹ ਬਿਨਾਂ ਕਿਸੇ ਵਾਧੂ ਸੰਰਚਨਾ ਦੇ ਕੰਮ ਕਰਨਗੇ।

ਅਜਿਹਾ ਕਿਉਂ ਹੈ? ਕਿਉਂਕਿ ਤੁਹਾਡੇ ਨੋਡਾਂ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਰੂਟ ਕੌਂਫਿਗਰ ਕੀਤੇ ਹੋਏ ਹਨ:

# ip route
default via 192.168.1.1 dev eth0 onlink 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10

ਅਤੇ ਉਸੇ ਰੇਂਜ ਦੇ ਪਤੇ ਬਿਨਾਂ ਕਿਸੇ ਵਾਧੂ ਕਾਰਵਾਈਆਂ ਦੇ ਉਹਨਾਂ ਦੀ ਮੁੜ ਵਰਤੋਂ ਕਰਨਗੇ।

ਕੇਸ 2: ਜਦੋਂ ਵਾਧੂ ਅਨੁਕੂਲਤਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ

ਤੁਹਾਨੂੰ ਵਾਧੂ ਰੂਟਾਂ ਦੀ ਸੰਰਚਨਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਜਦੋਂ ਵੀ ਤੁਹਾਡੇ ਨੋਡਸ ਕੋਲ ਸੰਰਚਿਤ IP ਪਤਾ ਜਾਂ ਸਬਨੈੱਟ ਲਈ ਰੂਟ ਨਹੀਂ ਹੁੰਦਾ ਜਿਸ ਲਈ MetalLB ਪਤੇ ਜਾਰੀ ਕਰਦਾ ਹੈ।

ਮੈਂ ਥੋੜਾ ਹੋਰ ਵਿਸਥਾਰ ਵਿੱਚ ਦੱਸਾਂਗਾ. ਜਦੋਂ ਵੀ MetalLB ਕਿਸੇ ਐਡਰੈੱਸ ਨੂੰ ਆਉਟਪੁੱਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਸਦੀ ਤੁਲਨਾ ਸਧਾਰਨ ਅਸਾਈਨਮੈਂਟ ਨਾਲ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ ਜਿਵੇਂ ਕਿ:

ip addr add 10.9.8.7/32 dev lo

ਨੂੰ ਧਿਆਨ ਦੇਣਾ:

• a) ਪਤਾ ਅਗੇਤਰ ਦੇ ਨਾਲ ਦਿੱਤਾ ਗਿਆ ਹੈ /32 ਭਾਵ, ਇੱਕ ਰੂਟ ਇਸਦੇ ਲਈ ਸਬਨੈੱਟ ਵਿੱਚ ਆਪਣੇ ਆਪ ਨਹੀਂ ਜੋੜਿਆ ਜਾਵੇਗਾ (ਇਹ ਸਿਰਫ਼ ਇੱਕ ਪਤਾ ਹੈ)
• b) ਪਤਾ ਕਿਸੇ ਵੀ ਨੋਡ ਇੰਟਰਫੇਸ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ (ਉਦਾਹਰਨ ਲਈ ਲੂਪਬੈਕ)। ਇੱਥੇ ਲੀਨਕਸ ਨੈੱਟਵਰਕ ਸਟੈਕ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਾ ਜ਼ਿਕਰ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ। ਕੋਈ ਫਰਕ ਨਹੀਂ ਪੈਂਦਾ ਕਿ ਤੁਸੀਂ ਕਿਸ ਇੰਟਰਫੇਸ ਵਿੱਚ ਐਡਰੈੱਸ ਜੋੜਦੇ ਹੋ, ਕਰਨਲ ਹਮੇਸ਼ਾ arp ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰੇਗਾ ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨੂੰ ਵੀ arp ਜਵਾਬ ਭੇਜੇਗਾ, ਇਸ ਵਿਹਾਰ ਨੂੰ ਸਹੀ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ, ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕੁਬਰਨੇਟਸ ਵਰਗੇ ਗਤੀਸ਼ੀਲ ਵਾਤਾਵਰਣ ਵਿੱਚ ਕਾਫ਼ੀ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।

ਇਸ ਵਿਵਹਾਰ ਨੂੰ ਕਸਟਮਾਈਜ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ ਸਖਤ arp ਨੂੰ ਸਮਰੱਥ ਕਰਕੇ:

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, arp ਜਵਾਬ ਤਾਂ ਹੀ ਭੇਜੇ ਜਾਣਗੇ ਜੇਕਰ ਇੰਟਰਫੇਸ ਵਿੱਚ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਇੱਕ ਖਾਸ IP ਪਤਾ ਸ਼ਾਮਲ ਹੋਵੇ। ਇਸ ਸੈਟਿੰਗ ਦੀ ਲੋੜ ਹੈ ਜੇਕਰ ਤੁਸੀਂ MetalLB ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦੇ ਹੋ ਅਤੇ ਤੁਹਾਡੀ ਕਿਊਬ-ਪ੍ਰੌਕਸੀ IPVS ਮੋਡ ਵਿੱਚ ਚੱਲ ਰਹੀ ਹੈ।

ਹਾਲਾਂਕਿ, MetalLB arp ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਲਈ ਕਰਨਲ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਖੁਦ ਉਪਭੋਗਤਾ-ਸਪੇਸ ਵਿੱਚ ਕਰਦਾ ਹੈ, ਇਸਲਈ ਇਹ ਵਿਕਲਪ MetalLB ਦੇ ਸੰਚਾਲਨ ਨੂੰ ਪ੍ਰਭਾਵਤ ਨਹੀਂ ਕਰੇਗਾ।

ਆਉ ਆਪਣੇ ਕੰਮ ਤੇ ਵਾਪਸ ਆਓ. ਜੇਕਰ ਜਾਰੀ ਕੀਤੇ ਪਤਿਆਂ ਲਈ ਰੂਟ ਤੁਹਾਡੇ ਨੋਡਾਂ 'ਤੇ ਮੌਜੂਦ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਸਾਰੇ ਨੋਡਾਂ ਵਿੱਚ ਪਹਿਲਾਂ ਤੋਂ ਸ਼ਾਮਲ ਕਰੋ:

ip route add 10.9.8.0/24 dev eth1

ਕੇਸ 3: ਜਦੋਂ ਤੁਹਾਨੂੰ ਸਰੋਤ-ਆਧਾਰਿਤ ਰੂਟਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ

ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਵੱਖਰੇ ਗੇਟਵੇ ਰਾਹੀਂ ਪੈਕੇਟ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ ਤਾਂ ਤੁਹਾਨੂੰ ਸਰੋਤ-ਅਧਾਰਿਤ ਰੂਟਿੰਗ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੋਏਗੀ, ਨਾ ਕਿ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਸੰਰਚਨਾ ਕੀਤੀ ਗਈ, ਇਸਲਈ ਜਵਾਬ ਪੈਕਟਾਂ ਨੂੰ ਵੀ ਉਸੇ ਗੇਟਵੇ ਰਾਹੀਂ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, ਤੁਹਾਡੇ ਕੋਲ ਉਹੀ ਸਬਨੈੱਟ ਹੈ 192.168.1.0/24 ਤੁਹਾਡੇ ਨੋਡਾਂ ਨੂੰ ਸਮਰਪਿਤ ਹੈ, ਪਰ ਤੁਸੀਂ MetalLB ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਾਹਰੀ ਪਤੇ ਜਾਰੀ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ। ਮੰਨ ਲਓ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਸਬਨੈੱਟ ਤੋਂ ਕਈ ਪਤੇ ਹਨ 1.2.3.0/24 VLAN 100 ਵਿੱਚ ਸਥਿਤ ਹੈ ਅਤੇ ਤੁਸੀਂ ਇਹਨਾਂ ਦੀ ਵਰਤੋਂ ਬਾਹਰੀ ਤੌਰ 'ਤੇ Kubernetes ਸੇਵਾਵਾਂ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਲਈ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ।

ਸੰਪਰਕ ਕਰਨ 'ਤੇ ਐੱਸ 1.2.3.4 ਤੁਸੀਂ ਇਸ ਤੋਂ ਵੱਖਰੇ ਸਬਨੈੱਟ ਤੋਂ ਬੇਨਤੀਆਂ ਕਰ ਰਹੇ ਹੋਵੋਗੇ 1.2.3.0/24 ਅਤੇ ਜਵਾਬ ਦੀ ਉਡੀਕ ਕਰੋ। ਨੋਡ ਜੋ ਵਰਤਮਾਨ ਵਿੱਚ MetalLB-ਜਾਰੀ ਪਤੇ ਲਈ ਮਾਸਟਰ ਹੈ 1.2.3.4, ਰਾਊਟਰ ਤੋਂ ਪੈਕੇਟ ਪ੍ਰਾਪਤ ਕਰੇਗਾ 1.2.3.1, ਪਰ ਉਸਦੇ ਲਈ ਜਵਾਬ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਉਸੇ ਰਸਤੇ 'ਤੇ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ 1.2.3.1.

ਕਿਉਂਕਿ ਸਾਡੇ ਨੋਡ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਸੰਰਚਿਤ ਡਿਫੌਲਟ ਗੇਟਵੇ ਹੈ 192.168.1.1, ਫਿਰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਜਵਾਬ ਉਸ ਕੋਲ ਜਾਵੇਗਾ, ਅਤੇ ਨਹੀਂ 1.2.3.1, ਜਿਸ ਰਾਹੀਂ ਸਾਨੂੰ ਪੈਕੇਜ ਪ੍ਰਾਪਤ ਹੋਇਆ ਹੈ।

ਇਸ ਸਥਿਤੀ ਨਾਲ ਕਿਵੇਂ ਨਜਿੱਠਣਾ ਹੈ?

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਆਪਣੇ ਸਾਰੇ ਨੋਡਾਂ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਤਿਆਰ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਉਹ ਬਿਨਾਂ ਵਾਧੂ ਸੰਰਚਨਾ ਦੇ ਬਾਹਰੀ ਪਤਿਆਂ ਦੀ ਸੇਵਾ ਕਰਨ ਲਈ ਤਿਆਰ ਹਨ. ਭਾਵ, ਉਪਰੋਕਤ ਉਦਾਹਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਨੋਡ 'ਤੇ ਪਹਿਲਾਂ ਤੋਂ ਇੱਕ VLAN ਇੰਟਰਫੇਸ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ:

ip link add link eth0 name eth0.100 type vlan id 100
ip link set eth0.100 up

ਅਤੇ ਫਿਰ ਰੂਟ ਜੋੜੋ:

ip route add 1.2.3.0/24 dev eth0.100 table 100
ip route add default via 1.2.3.1 table 100

ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਓ ਕਿ ਅਸੀਂ ਇੱਕ ਵੱਖਰੀ ਰੂਟਿੰਗ ਟੇਬਲ ਵਿੱਚ ਰੂਟ ਜੋੜਦੇ ਹਾਂ 100 ਇਸ ਵਿੱਚ ਗੇਟਵੇ ਰਾਹੀਂ ਜਵਾਬੀ ਪੈਕੇਟ ਭੇਜਣ ਲਈ ਸਿਰਫ਼ ਦੋ ਰੂਟ ਜ਼ਰੂਰੀ ਹੋਣਗੇ 1.2.3.1, ਇੰਟਰਫੇਸ ਦੇ ਪਿੱਛੇ ਸਥਿਤ ਹੈ eth0.100.

ਹੁਣ ਸਾਨੂੰ ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ ਜੋੜਨ ਦੀ ਲੋੜ ਹੈ:

ip rule add from 1.2.3.0/24 lookup 100

ਜੋ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਕਹਿੰਦਾ ਹੈ: ਜੇਕਰ ਪੈਕੇਟ ਦਾ ਸਰੋਤ ਪਤਾ ਅੰਦਰ ਹੈ 1.2.3.0/24, ਫਿਰ ਤੁਹਾਨੂੰ ਰੂਟਿੰਗ ਟੇਬਲ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ 100. ਇਸ ਵਿੱਚ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਉਸ ਰਸਤੇ ਦਾ ਵਰਣਨ ਕੀਤਾ ਹੈ ਜੋ ਉਸਨੂੰ ਭੇਜੇਗਾ 1.2.3.1

ਕੇਸ 4: ਜਦੋਂ ਤੁਹਾਨੂੰ ਨੀਤੀ-ਆਧਾਰਿਤ ਰੂਟਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ

ਨੈੱਟਵਰਕ ਟੌਪੋਲੋਜੀ ਪਿਛਲੀ ਉਦਾਹਰਨ ਵਾਂਗ ਹੀ ਹੈ, ਪਰ ਮੰਨ ਲਓ ਕਿ ਤੁਸੀਂ ਬਾਹਰੀ ਪੂਲ ਪਤਿਆਂ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਦੇ ਯੋਗ ਵੀ ਹੋਣਾ ਚਾਹੁੰਦੇ ਹੋ 1.2.3.0/24 ਤੁਹਾਡੀਆਂ ਫਲੀਆਂ ਤੋਂ:

ਖਾਸੀਅਤ ਇਹ ਹੈ ਕਿ ਕਿਸੇ ਵੀ ਪਤੇ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਵੇਲੇ 1.2.3.0/24, ਜਵਾਬ ਪੈਕੇਟ ਨੋਡ ਨੂੰ ਹਿੱਟ ਕਰਦਾ ਹੈ ਅਤੇ ਸੀਮਾ ਵਿੱਚ ਇੱਕ ਸਰੋਤ ਪਤਾ ਹੁੰਦਾ ਹੈ 1.2.3.0/24 ਨੂੰ ਆਗਿਆਕਾਰੀ ਨਾਲ ਭੇਜਿਆ ਜਾਵੇਗਾ eth0.100, ਪਰ ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ ਕੁਬਰਨੇਟਸ ਇਸਨੂੰ ਸਾਡੇ ਪਹਿਲੇ ਪੌਡ 'ਤੇ ਰੀਡਾਇਰੈਕਟ ਕਰੇ, ਜਿਸ ਨੇ ਅਸਲ ਬੇਨਤੀ ਤਿਆਰ ਕੀਤੀ ਹੈ।

ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੋ ਗਿਆ, ਪਰ ਇਹ ਨੀਤੀ-ਆਧਾਰਿਤ ਰੂਟਿੰਗ ਦੇ ਕਾਰਨ ਸੰਭਵ ਹੋਇਆ:

ਪ੍ਰਕਿਰਿਆ ਦੀ ਬਿਹਤਰ ਸਮਝ ਲਈ, ਇੱਥੇ ਇੱਕ ਨੈੱਟਫਿਲਟਰ ਬਲਾਕ ਚਿੱਤਰ ਹੈ:

ਪਹਿਲਾਂ, ਜਿਵੇਂ ਕਿ ਪਿਛਲੀ ਉਦਾਹਰਨ ਵਿੱਚ, ਆਓ ਇੱਕ ਵਾਧੂ ਰੂਟਿੰਗ ਟੇਬਲ ਬਣਾਈਏ:

ip route add 1.2.3.0/24 dev eth0.100 table 100
ip route add default via 1.2.3.1 table 100

ਆਓ ਹੁਣ iptables ਵਿੱਚ ਕੁਝ ਨਿਯਮ ਜੋੜੀਏ:

iptables -t mangle -A PREROUTING -i eth0.100 -j CONNMARK --set-mark 0x100
iptables -t mangle -A PREROUTING  -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j RETURN
iptables -t mangle -A POSTROUTING -j CONNMARK --save-mark

ਇਹ ਨਿਯਮ ਇੰਟਰਫੇਸ ਲਈ ਆਉਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਚਿੰਨ੍ਹਿਤ ਕਰਨਗੇ eth0.100, ਸਾਰੇ ਪੈਕੇਟਾਂ ਨੂੰ ਟੈਗ ਨਾਲ ਚਿੰਨ੍ਹਿਤ ਕਰਨਾ 0x100, ਉਸੇ ਕੁਨੈਕਸ਼ਨ ਦੇ ਅੰਦਰ ਜਵਾਬਾਂ ਨੂੰ ਵੀ ਉਸੇ ਟੈਗ ਨਾਲ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਜਾਵੇਗਾ।

ਹੁਣ ਅਸੀਂ ਇੱਕ ਰੂਟਿੰਗ ਨਿਯਮ ਜੋੜ ਸਕਦੇ ਹਾਂ:

ip rule add from 1.2.3.0/24 fwmark 0x100 lookup 100

ਭਾਵ, ਸਰੋਤ ਪਤੇ ਵਾਲੇ ਸਾਰੇ ਪੈਕੇਟ 1.2.3.0/24 ਅਤੇ ਟੈਗ 0x100 ਇੱਕ ਸਾਰਣੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਰੂਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ 100.

ਇਸ ਤਰ੍ਹਾਂ, ਕਿਸੇ ਹੋਰ ਇੰਟਰਫੇਸ 'ਤੇ ਪ੍ਰਾਪਤ ਕੀਤੇ ਹੋਰ ਪੈਕੇਟ ਇਸ ਨਿਯਮ ਦੇ ਅਧੀਨ ਨਹੀਂ ਹਨ, ਜੋ ਉਹਨਾਂ ਨੂੰ ਮਿਆਰੀ ਕੁਬਰਨੇਟਸ ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਰੂਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗਾ।

ਇੱਕ ਹੋਰ ਚੀਜ਼ ਹੈ, ਲੀਨਕਸ ਵਿੱਚ ਇੱਕ ਅਖੌਤੀ ਰਿਵਰਸ ਪਾਥ ਫਿਲਟਰ ਹੈ, ਜੋ ਸਾਰੀ ਚੀਜ਼ ਨੂੰ ਵਿਗਾੜਦਾ ਹੈ; ਇਹ ਇੱਕ ਸਧਾਰਨ ਜਾਂਚ ਕਰਦਾ ਹੈ: ਸਾਰੇ ਆਉਣ ਵਾਲੇ ਪੈਕੇਟਾਂ ਲਈ, ਇਹ ਭੇਜਣ ਵਾਲੇ ਪਤੇ ਦੇ ਨਾਲ ਪੈਕੇਟ ਦਾ ਸਰੋਤ ਪਤਾ ਬਦਲਦਾ ਹੈ ਅਤੇ ਜਾਂਚ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਪੈਕੇਟ ਉਸੇ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਛੱਡ ਸਕਦਾ ਹੈ ਜਿਸ 'ਤੇ ਇਹ ਪ੍ਰਾਪਤ ਕੀਤਾ ਗਿਆ ਸੀ, ਜੇਕਰ ਨਹੀਂ, ਤਾਂ ਇਹ ਇਸਨੂੰ ਫਿਲਟਰ ਕਰ ਦੇਵੇਗਾ।

ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਸਾਡੇ ਕੇਸ ਵਿੱਚ ਇਹ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ, ਪਰ ਅਸੀਂ ਇਸਨੂੰ ਅਯੋਗ ਕਰ ਸਕਦੇ ਹਾਂ:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth0.100/rp_filter

ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਓ ਕਿ ਪਹਿਲੀ ਕਮਾਂਡ rp_filter ਦੇ ਗਲੋਬਲ ਵਿਵਹਾਰ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੀ ਹੈ; ਜੇਕਰ ਇਹ ਅਯੋਗ ਨਹੀਂ ਹੈ, ਤਾਂ ਦੂਜੀ ਕਮਾਂਡ ਦਾ ਕੋਈ ਪ੍ਰਭਾਵ ਨਹੀਂ ਹੋਵੇਗਾ। ਹਾਲਾਂਕਿ, ਬਾਕੀ ਇੰਟਰਫੇਸ rp_filter ਸਮਰਥਿਤ ਰਹਿਣਗੇ।

ਫਿਲਟਰ ਦੇ ਸੰਚਾਲਨ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੀਮਤ ਨਾ ਕਰਨ ਲਈ, ਅਸੀਂ netfilter ਲਈ rp_filter ਲਾਗੂਕਰਨ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਾਂ। rpfilter ਨੂੰ ਇੱਕ iptables ਮੋਡੀਊਲ ਵਜੋਂ ਵਰਤਣਾ, ਤੁਸੀਂ ਕਾਫ਼ੀ ਲਚਕਦਾਰ ਨਿਯਮਾਂ ਨੂੰ ਸੰਰਚਿਤ ਕਰ ਸਕਦੇ ਹੋ, ਉਦਾਹਰਨ ਲਈ:

iptables -t raw -A PREROUTING -i eth0.100 -d 1.2.3.0/24 -j RETURN
iptables -t raw -A PREROUTING -i eth0.100 -m rpfilter --invert -j DROP

ਇੰਟਰਫੇਸ 'ਤੇ rp_filter ਨੂੰ ਸਮਰੱਥ ਬਣਾਓ eth0.100 ਨੂੰ ਛੱਡ ਕੇ ਸਾਰੇ ਪਤਿਆਂ ਲਈ 1.2.3.0/24.

ਸਰੋਤ: www.habr.com