nftables ਮਾਰਕ ਅਤੇ VPN ਰਾਊਟਿੰਗ: ਕਿਹੜਾ ਨਿਯਮ ਸੱਚਮੁੱਚ ਜਿੱਤਦਾ ਹੈ

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

ਜਾਂਚ 1: ਉਹ ਨਿਯਮ ਪੜ੍ਹੋ ਜਿਸ ਨਾਲ ਕਰਨਲ ਮੇਲ ਖਾਂਦਾ ਹੈ

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

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

ਦੋ ਕਮਾਂਡ ਇਸ ਨੂੰ ਤੈਅ ਕਰਦੀਆਂ ਹਨ: ਨਿਯਮਾਂ ਦੀ ਸੂਚੀ, ਅਤੇ ਉਸ ਸਾਰਣੀ ਵਿੱਚ ਮੰਜ਼ਿਲ ਲਈ ਰੂਟ ਖੋਜ।

ਜਾਂਚ 2: ਪੈਕਟ ਮਾਰਕ ਜਾਂ ਕਨੈਕਸ਼ਨ ਮਾਰਕ

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

ਜੇ ਰਾਊਟਿੰਗ ਨਿਯਮ ਪੈਕਟ ਮਾਰਕ ’ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਪੰਧ ਵਿੱਚ ਬਾਅਦ ਨੂੰ ਕਨੈਕਸ਼ਨ ਮਾਰਕ ਬਹਾਲ ਕਰਨ ਨਾਲ ਉਸ ਫ਼ੈਸਲੇ ਲਈ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ, ਕਿਉਂਕਿ ਫ਼ੈਸਲਾ ਪਹਿਲਾਂ ਹੀ ਹੋ ਚੁੱਕਾ ਹੈ।

ਤੈਅ ਕਰੋ ਕਿ ਰਾਊਟਿੰਗ ਸਿਗਨਲ ਕਿਸ ਆਬਜੈਕਟ ਦਾ ਹੈ, ਫਿਰ ਇਸ ਨੂੰ ਉਸ ਬਿੰਦੂ ’ਤੇ ਲਾਓ ਜਿੱਥੇ ਰਾਊਟਿੰਗ ਫ਼ੈਸਲਾ ਲਿਆ ਜਾਂਦਾ ਹੈ।

ਜਾਂਚ 3: ਇਹ ਮਾਰਕ ਹੋਰ ਕੌਣ ਲਿਖਦਾ ਹੈ

WireGuard ਦੇ ਆਪਣੇ ਔਜ਼ਾਰ ਆਪਣੇ UDP ਪੈਕਟਾਂ ’ਤੇ ਮਾਰਕ ਲਾਉਂਦੇ ਹਨ ਤਾਂ ਜੋ ਐਨਕ੍ਰਿਪਟਿਡ ਟਰਾਂਸਪੋਰਟ ਉਸ ਸੁਰੰਗ ਵਿੱਚ ਵਾਪਸ ਰੂਟ ਨਾ ਹੋਵੇ ਜਿਸ ਦਾ ਇਹ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਨਿਯਮ-ਸਮੂਹ ਉਸੇ ਫੀਲਡ ਨੂੰ ਅਸੰਬੰਧਿਤ ਮੁੱਲ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਉਹ ਬਾਹਰ ਰੱਖਣਾ ਖ਼ਤਮ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸੁਰੰਗ ਦੀ ਬਾਹਰੀ ਟ੍ਰੈਫਿਕ ਆਪਣੇ ਆਪ ਵਿੱਚ ਵੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ। ਲੱਛਣ ਇਹ ਹੈ ਕਿ ਸੁਰੰਗ ਸਥਾਪਿਤ ਹੁੰਦੀ ਹੈ ਅਤੇ ਫਿਰ ਟ੍ਰੈਫਿਕ ਲੰਘਾਉਣਾ ਬੰਦ ਕਰ ਦਿੰਦੀ ਹੈ।

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

ਹੋਰ ਇੱਕ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਲੇਖਕਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ।

ਜਾਂਚ 4: ਮਾਸਕ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ ਰੱਖਦੇ ਹੋ

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

ਨਿਯਮ-ਸਮੂਹ ਦੇ ਕੋਲ ਬਿੱਟ ਵੰਡ ਦਾ ਦਸਤਾਵੇਜ਼ ਬਣਾਓ।

ਨਹੀਂ ਤਾਂ ਅਗਲਾ ਵਿਅਕਤੀ ਉਹ ਮੁੱਲ ਦੁਬਾਰਾ ਵਰਤੇਗਾ ਜਿਸ ਦਾ ਪਹਿਲਾਂ ਹੀ ਮਾਲਕ ਹੈ, ਅਤੇ ਇੱਥੋਂ ਦਾ ਟਕਰਾਅ ਰਾਊਟਿੰਗ ਬੱਗ ਵਾਂਗ ਦਿਸਦਾ ਹੈ ਜਦੋਂ ਕਿ ਇਹ ਪਤਾ-ਨਿਰਧਾਰਣ ਦਾ ਬੱਗ ਹੈ। ਪੈਕਟ ਮੈਟਾਡੇਟਾ ਬਾਰੇ nftables ਦਸਤਾਵੇਜ਼ ਮਾਰਕ ਕਾਰਵਾਈਆਂ ਦਾ ਆਪ ਵਰਣਨ ਕਰਦਾ ਹੈ।

ਜਾਂਚ 5: ਖੋਜ ਨਾਲ ਨਹੀਂ, ਅਸਲ ਫ਼ਲੋ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ

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

ਲਾਈਵ ਸੈਸ਼ਨ ਦੌਰਾਨ ਰਿਫ਼੍ਰੈਸ਼ ਜ਼ਬਰਦਸਤੀ ਕਰਨ ਲਈ ਕਨੈਕਸ਼ਨ ਅਵਸਥਾ ਫਲਸ਼ ਕਰਨ ਤੋਂ ਬਚੋ, ਕਿਉਂਕਿ ਨਵੇਂ ਅਤੇ ਮੌਜੂਦਾ ਫ਼ਲੋ ਕਾਨੂੰਨੀ ਤੌਰ ’ਤੇ ਵੱਖਰੇ ਪੰਧ ਲੈ ਸਕਦੇ ਹਨ।

ਮਾਰਕ, ਮਾਸਕ ਅਤੇ ਸਾਰਣੀ ਇੱਕ ਥਾਂ ਦਰਜ ਕਰੋ, ਫਿਰ ਅਗਲਾ ਸੋਧ ਸਮੀਖਿਆਯੋਗ ਹੋ ਜਾਂਦਾ ਹੈ।