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

ਤਿੰਨ ਵੱਖਰੀਆਂ ਬਾਈਂਡਿੰਗਾਂ, ਤਿੰਨ ਵੱਖਰੇ ਅਸਰ

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

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

ਤੈਅ ਕਰੋ ਕਿ ਐਪ ਅਸਲ ਵਿੱਚ ਕੀ ਸੈੱਟ ਕਰਦੀ ਹੈ

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

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

ਨੀਤੀ ਰੂਟਿੰਗ ਸਰੋਤ ਪੜ੍ਹਦੀ ਹੈ

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

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

ਸਪਲਿਟ ਟਨਲਿੰਗ ਅਤੇ ਸਹਾਇਕ ਪ੍ਰੋਸੈਸ

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

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

ਐਪ ਦਾ ਆਪਣਾ ਰਾਹ ਪਰਖੋ

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

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

ਸੰਬੰਧਿਤ ਲੇਖ