ਕੀ ਹਾਰਡਵੇਅਰ NAT ਆਫਲੋਡ ਤੁਹਾਡੇ VPN ਰੂਟਿੰਗ ਨਿਯਮ ਤੋੜਦਾ ਹੈ?

ਹਾਰਡਵੇਅਰ NAT ਤੇਜ਼ੀ ਚਾਲੂ ਕਰਨਾ VPN ਸੈਟਅੱਪ ਨੂੰ ਤੇਜ਼ ਬਣਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹ ਵੀ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਰੂਟਿੰਗ ਨੀਤੀ ਬਿਨਾਂ ਕਿਸੇ ਗਲਤੀ ਦੇ ਕੁਝ ਪੈਕਟਾਂ 'ਤੇ ਲਾਗੂ ਹੋਣਾ ਬੰਦ ਕਰ ਦੇਵੇ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੀ ਹੁੰਦਾ ਹੈ, ਇਹ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਤੇਜ਼ ਰਸਤਾ ਕੀ ਛੱਡਦਾ ਹੈ, ਅਤੇ ਇਹ ਫਰਮਵੇਅਰ, ਕਰਨਲ ਵਰਜਨ ਅਤੇ ਵਰਤੀ ਜਾ ਰਹੀ ਤੇਜ਼ੀ ਦੀ ਕਿਸਮ ਵਿਚਕਾਰ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ। ਸੈਟਿੰਗਾਂ ਦਾ ਮੀਨੂ ਘੱਟ ਹੀ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਹੁਣੇ ਕਿਹੜੀ ਚਾਲੂ ਕੀਤੀ ਹੈ।

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

ਤਿੰਨ ਵੱਖਰੀਆਂ ਤੇਜ਼ੀਆਂ ਇੱਕੱਠੀਆਂ ਰਲਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ

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

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

ਰੁਕ ਜਾਣ ਵਾਲੀ ਗਿਣਤੀ ਘੱਟ ਹੀ ਸਾਬਤ ਕਰਦੀ ਹੈ

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

ਉਲਟ ਅਨੁਮਾਨ ਵੀ ਓਨਾ ਹੀ ਮਾੜਾ ਫੇਲ ਹੁੰਦਾ ਹੈ। ਤੇਜ਼ ਡਾਊਨਲੋਡ ਇਹ ਨਹੀਂ ਦਿਖਾਉਂਦਾ ਕਿ ਤੁਹਾਡੇ ਛੋਟ ਨਿਯਮ ਅਤੇ ਨਾਕਾਮੀ ਸੰਭਾਲ ਅਜੇ ਵੀ ਲਾਗੂ ਹਨ, ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਫਲੋ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਨੀਤੀ ਦੀ ਨਹੀਂ।

ਤਿੰਨ ਸ਼ਰਤਾਂ ਤੈਅ ਕਰਦੀਆਂ ਹਨ ਕਿ ਆਫਲੋਡ ਨੀਤੀ ਤੋੜਦਾ ਹੈ ਜਾਂ ਨਹੀਂ

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

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

ਨੀਤੀ ਦੀ ਜਾਂਚ ਕਰੋ, ਥ੍ਰੂਪੁਟ ਦੀ ਨਹੀਂ

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

nft list flowtables
conntrack -L | head -n 20
curl -sS --max-time 8 https://api.ipify.org; echo
ping -c 3 192.168.50.20

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

ਪਿਛਲੀ ਸੈਟਿੰਗ ਲਿਖ ਲਓ ਤਾਂ ਜੋ ਤਜਰਬਾ ਉਲਟਾਉਣ ਯੋਗ ਰਹੇ। ਹਰ ਜਗ੍ਹਾ ਆਫਲੋਡ ਬੰਦ ਕਰਨ ਦੀ ਆਮ ਹਦਾਇਤ ਇੱਕ ਵਰਕਅਰਾਊਂਡ ਗਿਣੀ ਜਾਂਦੀ ਹੈ, ਖੋਜ ਨਹੀਂ।