ਤੁਸੀਂ FORWARD ਚੇਨ ਵਿੱਚ VPN ਟ੍ਰੈਫ਼ਿਕ ਲਈ ਨਿਯਮ ਜੋੜਦੇ ਹੋ, ਉਸੇ Linux ਬਾਕਸ ਤੋਂ ਬੇਨਤੀ ਚਲਾਉਂਦੇ ਹੋ, ਅਤੇ ਗਿਣਤੀ ਸਿਫ਼ਰ ਉੱਤੇ ਹੀ ਰਹਿੰਦੀ ਹੈ। ਨਿਯਮ ਸ਼ਾਇਦ ਸਹੀ ਹੈ। ਪੈਕਟ ਨੇ ਉਹ ਰਾਹ ਕਦੇ ਨਹੀਂ ਲਿਆ, ਕਿਉਂਕਿ ਮਸ਼ੀਨ ਉੱਤੇ ਹੀ ਪੈਦਾ ਹੋਈ ਬੇਨਤੀ ਨੂੰ ਇਹ ਅੱਗੇ ਨਹੀਂ ਭੇਜਦੀ। ਸਾਕਟ ਤੋਂ ਤਾਰ ਤੱਕ ਪੈਕਟ ਦਾ ਜੀਵਨ ਟਰੇਸ ਕਰਨ ਨਾਲ ਸਮਝ ਆਉਂਦਾ ਹੈ ਕਿ ਇਉਂ ਕਿਉਂ ਹੈ ਅਤੇ ਨਿਯਮ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਪਤਾ ਲਗਾਓ ਪੈਕਟ ਕਿੱਥੇ ਜਨਮਿਆ

Netfilter ਦਾ hook ਕ੍ਰਮ ਤਿੰਨ ਹਾਲਤਾਂ ਵੱਖ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਵਿੱਚ FORWARD ਆਉਂਦਾ ਹੈ:

OriginPathHook that sees it
Local processOUTPUT then POSTROUTINGOUTPUT, POSTROUTING
Addressed to a local servicePREROUTING then INPUTPREROUTING, INPUT
Received for another hostPREROUTING, FORWARD, POSTROUTINGFORWARD

ਸਥਾਨਕ ਐਪਲੀਕੇਸ਼ਨ OUTPUT ਮਾਰਗ ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਕਰਨਲ ਪਹਿਲਾਂ ਹੀ ਤੈਅ ਕਰ ਚੁੱਕਾ ਹੈ ਕਿ ਪੈਕਟ ਇੱਥੇ ਹੀ ਪੈਦਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਕਦੇ ਅੱਗੇ ਭੇਜਣ ਦਾ ਉਮੀਦਵਾਰ ਨਹੀਂ ਹੈ। ਟਨਲ ਬਣਾਉਣ ਨਾਲ ਉਹ ਵਰਗੀਕਰਨ ਨਹੀਂ ਬਦਲਦਾ; ਟਨਲ ਇੱਕ ਉਪਕਰਨ ਹੈ ਜਿਸ ਰਾਹੀਂ ਪੈਕਟ ਬਾਹਰ ਜਾ ਸਕਦਾ ਹੈ, ਸਥਾਨਕ ਆਊਟਪੁੱਟ ਨੂੰ ਟ੍ਰਾਂਜ਼ਿਟ ਬਣਾਉਣ ਵਾਲਾ ਪੜਾਅ ਨਹੀਂ।

ਦੋ ਪੈਕਟ, ਇੱਕ ਕਹਾਣੀ

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

ਤੁਹਾਡੀ ਨੀਤੀ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ, ਅਤੇ ਗਲਤ ਚੁਣਨਾ ਇੱਕ ਆਮ ਕਾਰਨ ਹੈ ਕਿ ਨਿਯਮ ਕੁਝ ਨਹੀਂ ਕਰਦਾ ਜਾਪਦਾ। ਪੀਅਰ ਦੇ ਬਾਹਰੀ ਪਤੇ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਨਿਯਮ ਹਰ ਟਨਲ ਪੈਕਟ ਨੂੰ ਇੱਕੋ ਜਿਹਾ ਦੇਖਦਾ ਹੈ, ਅੰਦਰ ਦੀ ਐਪ ਭਾਵੇਂ ਕੁਝ ਵੀ ਕਰੇ। ਅੰਦਰੂਨੀ ਮੰਜ਼ਿਲ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਨਿਯਮ ਤੁਹਾਡੇ ਲਈ ਜ਼ਰੂਰੀ ਟ੍ਰੈਫ਼ਿਕ ਦੇਖਦਾ ਹੈ, ਅਤੇ ਉਹ ਤਦ ਹੀ ਚੱਲੇਗਾ ਜਦੋਂ ਉਹ ਪੈਕਟ ਉਸ hook ਤੱਕ ਪਹੁੰਚੇਗਾ ਜਿਸ ਉੱਤੇ ਤੁਸੀਂ ਨਿਯਮ ਲਾਇਆ ਹੈ।

namespace ਹੱਦ ਨੂੰ ਹਿਲਾਉਂਦੇ ਹਨ

ਕੰਟੇਨਰ ਸਿਧਾਂਤ ਬਦਲੇ ਬਿਨਾਂ ਇਸ ਨੂੰ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦਾ ਹੈ। ਐਪ ਦੀ ਬੇਨਤੀ ਕੰਟੇਨਰ ਦੇ ਨੈੱਟਵਰਕ namespace ਅੰਦਰ ਸਥਾਨਕ ਆਊਟਪੁੱਟ ਹੈ। ਹੋਸਟ ਉਹ ਟ੍ਰੈਫ਼ਿਕ ਵਰਚੁਅਲ Ethernet ਇੰਟਰਫ਼ੇਸ ਉੱਤੇ ਲੈਂਦਾ ਹੈ ਅਤੇ ਅੱਗੇ ਭੇਜ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਹੋਸਟ ਉੱਤੇ FORWARD ਨਿਯਮ ਅਰਥਪੂਰਨ ਹੋ ਸਕਦਾ ਹੈ, ਭਾਵੇਂ ਬੇਨਤੀ ਪੈਦਾ ਕਰਨ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਨੇ ਹੋਸਟ ਦੀ OUTPUT ਚੇਨ ਨੂੰ ਕਦੇ ਨਹੀਂ ਛੋਹਿਆ।

hook ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਨਿਯਮ-ਸਮੂਹ ਅਤੇ ਟਨਲ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਰਹਿੰਦੇ ਹਨ। ਕੰਟੇਨਰ ਅੰਦਰ ਟਨਲ, ਹੋਸਟ ਉੱਤੇ ਟਨਲ ਅਤੇ ਕੰਟੇਨਰ ਨੂੰ ਉਸ ਰਾਹੀਂ route ਕਰਨਾ, ਅਤੇ ਵੱਖਰੇ namespace ਵਿੱਚ ਟਨਲ ਇਹ ਤਿੰਨ ਵੱਖਰੀਆਂ ਟੋਪੋਲੋਜੀਆਂ ਅਤੇ ਤਿੰਨ ਵੱਖਰੀਆਂ ਨਿਯਮ-ਥਾਵਾਂ ਹਨ। ਨਿਯਮ ਉਸ namespace ਅੰਦਰ ਪੜ੍ਹੋ ਜੋ ਉਪਕਰਨ ਦਾ ਮਾਲਕ ਹੈ, ਸਿਰਫ਼ ਡਿਫ਼ਾਲਟ ਵਿੱਚ ਨਹੀਂ।

ਪੁੱਛੋ ਕਿ ਕੀ ਤੁਹਾਨੂੰ mark ਦੀ ਲੋੜ ਹੈ

ਜੇ ਮਕਸਦ ਇੱਕ ਮੰਜ਼ਿਲ ਪ੍ਰੀਫ਼ਿਕਸ ਨੂੰ ਟਨਲ ਰਾਹੀਂ ਭੇਜਣਾ ਹੈ, ਤਾਂ ਉਸ ਪ੍ਰੀਫ਼ਿਕਸ ਲਈ route ਕਾਫ਼ੀ ਹੋ ਸਕਦਾ ਹੈ। ਪਹਿਲਾਂ ਪ੍ਰਭਾਵੀ route ਦੇਖੋ, ਸਰਵਰ ਵੱਲੋਂ ਧੱਕੀ ਹਰ ਚੀਜ਼ ਸਮੇਤ: ਰੀਡਾਇਰੈਕਟ ਕੀਤਾ ਡਿਫ਼ਾਲਟ ਤੁਹਾਡੇ ਸੋਚੇ ਸੰਖੇਪ ਨਿਯਮ ਨਾਲੋਂ ਕਿਤੇ ਵੱਧ ਟ੍ਰੈਫ਼ਿਕ VPN ਰਾਹੀਂ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਕਿੰਨਾ ਵੀ mark ਕਰੋ ਨਤੀਜਾ ਮਕਸਦ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਏਗਾ।

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

iptables ਵਿੱਚ ਬਰਾਬਰ ਦੀ ਚੀਜ਼ mangle OUTPUT ਬਣਤਰ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਉਹੀ ਸ਼ਰਤ ਲਾਗੂ ਹੈ: mark ਹੋਣ ਤੋਂ ਬਾਅਦ route ਫ਼ੈਸਲਾ ਦੁਬਾਰਾ ਦੇਖਣਾ ਪਵੇਗਾ। ਫਿਰ ਨੀਤੀ-ਨਿਯਮ ਨੇ mark ਵਰਤਣਾ ਅਤੇ ਕੰਮ ਦੀ route ਵਾਲੀ ਸਾਰਣੀ ਵੱਲ ਸੰਕੇਤ ਕਰਨਾ ਹੈ। conntrack mark ਲਾਉਣਾ ਤੀਜਾ, ਵੱਖਰਾ ਓਪਰੇਸ਼ਨ ਹੈ; ਇਹ ਪ੍ਰਵਾਹ ਉੱਤੇ ਮੁੱਲ ਰੱਖਦਾ ਹੈ ਅਤੇ ਉਹ ਮੁੱਲ ਆਪਣੇ ਆਪ ਮੌਜੂਦਾ ਪੈਕਟ ਉੱਤੇ ਨਹੀਂ ਰੱਖਦਾ ਤਾਂ ਜੋ route ਪੜ੍ਹ ਸਕੇ।

ਖੋਜ ਅਤੇ ਗਿਣਤੀ ਇਕੱਠੇ ਜਾਂਚੋ

nft list ruleset
ip route get 198.51.100.25
ip route get 198.51.100.25 mark 0x1

ਪਤਾ ਅਤੇ mark ਉਦਾਹਰਨ ਹਨ, ਅਤੇ ਦੋਵੇਂ route ਸਵਾਲ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ। ਦੂਜਾ ਪੁੱਛਦਾ ਹੈ ਕਿ ਜੇ ਪੈਕਟ ਉੱਤੇ ਉਹ mark ਹੁੰਦਾ ਤਾਂ ਕਰਨਲ ਕੀ ਕਰਦਾ; ਇਹ ਨਹੀਂ ਦਿਖਾਉਂਦਾ ਕਿ ਤੁਹਾਡਾ ਨਿਯਮ-ਸਮੂਹ mark ਦਿੰਦਾ ਹੈ। ਇਸ ਨੂੰ ਪਰਿਕਲਪਨਾ-ਪਰਖ ਮੰਨੋ, ਨੀਤੀ ਦੇ ਕੰਮ ਕਰਨ ਦਾ ਸਬੂਤ ਨਹੀਂ।

ਫਿਰ ਇੱਕ ਨਿਰਦੋਸ਼ ਬੇਨਤੀ ਚਲਾਓ ਅਤੇ ਇਕੱਠੇ ਦੋ ਚੀਜ਼ਾਂ ਦੇਖੋ: ਤੁਹਾਡੇ ਚੁਣੇ hook ਉੱਤੇ ਗਿਣਤੀ, ਅਤੇ ਪੈਕਟ ਨੇ ਅਸਲ ਵਿੱਚ ਜੋ ਨਿਕਾਸ ਲਿਆ। ਜੇ ਗਿਣਤੀ ਵਧੇ ਅਤੇ ਪੈਕਟ ਕਿਤੇ ਹੋਰੋਂ ਨਿਕਲੇ, ਤਾਂ mark ਜਾਂ ਸਾਰਣੀ ਗਲਤ ਹੈ। ਜੇ ਦੋਵੇਂ ਨਾ ਵਧਣ, ਤਾਂ ਪੈਕਟ ਉਸ hook ਤੱਕ ਪਹੁੰਚਦਾ ਹੀ ਨਹੀਂ, ਅਤੇ ਅਗਲਾ ਸਵਾਲ namespace ਜਾਂ ਮਾਰਗ ਹੈ।

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

ਸੰਬੰਧਿਤ ਲੇਖ