ਕਿਉਂ ਬਹੁਤ ਸਾਰੇ ਐਪ ਕਨੈਕਸ਼ਨ ਇੱਕ OpenVPN ਸੈਸ਼ਨ ਸਾਂਝਾ ਕਰਦੇ ਹਨ

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

ਇੱਕ ਬਾਹਰੀ ਗੱਲਬਾਤ, ਬਹੁਤ ਸਾਰੇ ਅੰਦਰੂਨੀ ਪ੍ਰਵਾਹ

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

ਕੁਝ ਵੀ ਢਹਿੰਦਾ ਨਹੀਂ। ਅੰਦਰੂਨੀ ਟਪਲ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਬਚੇ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਇਸੇ ਲਈ ਦੂਰ ਦਾ ਪਾਸਾ ਅਜੇ ਵੀ ਤਿੰਨਾਂ ਪ੍ਰਵਾਹਾਂ ਵਿੱਚ ਫ਼ਰਕ ਕਰ ਸਕਦਾ ਹੈ।

ਉਹ ਪੋਰਟ ਜੋ ਸਥਿਰ ਰਹਿੰਦਾ ਹੈ

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

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

ਦੂਰ ਦੇ ਸਿਰੇ 'ਤੇ ਡੀਕੈਪਸੂਲੇਸ਼ਨ ਕੀ ਬਦਲਦਾ ਹੈ

ਸਾਥੀ 'ਤੇ ਬਾਹਰੀ ਤਹਿ ਹਟਾ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਬਚਦਾ ਹੈ ਅੰਦਰੂਨੀ ਪੈਕਟ। ਉੱਥੋਂ ਅੱਗੇ ਫ਼ਾਰਵਰਡਿੰਗ ਅਤੇ ਪਹੁੰਚ ਨੀਤੀ ਅੰਦਰੂਨੀ ਮੰਜ਼ਿਲ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ 'ਤੇ ਲਾਗੂ ਹੁੰਦੀ ਹੈ। ਵੈੱਬ ਸਰਵਰ ਅਜੇ ਵੀ HTTPS ਕਨੈਕਸ਼ਨ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, SSH ਡੀਮਨ ਅਜੇ ਵੀ SSH ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਰਿਜ਼ੋਲਵਰ ਅਜੇ ਵੀ ਸਵਾਲ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ।

ਇਸੇ ਲਈ ਬਾਹਰੀ ਆਵਾਜਾਈ ਦੀ ਮਨਜ਼ੂਰੀ ਦੇਣ ਵਾਲਾ ਨਿਯਮ ਅੰਦਰੂਨੀ ਸੇਵਾ ਦੀ ਮਨਜ਼ੂਰੀ ਦੇਣ ਵਾਲਾ ਨਿਯਮ ਨਹੀਂ ਹੈ। ਪਹਿਲਾ ਇੱਕ ਰਾਹ ਦੱਸਦਾ ਹੈ; ਦੂਜਾ ਇੱਕ ਅਧਿਕਾਰ ਦੱਸਦਾ ਹੈ।

ਬਾਹਰੀ TCP ਦਾ ਮਤਲਬ ਇੱਕ ਪ੍ਰਵਾਹ, ਇੱਕ ਕਨੈਕਸ਼ਨ ਨਹੀਂ

ਜਦੋਂ ਬਾਹਰੀ ਆਵਾਜਾਈ UDP ਹੁੰਦੀ ਹੈ, ਹਰ ਅੰਦਰੂਨੀ ਪ੍ਰਵਾਹ ਦਾ ਭਾਗਿਆ ਸੁਤੰਤਰ ਹੁੰਦਾ ਹੈ: ਗੁੰਮਿਆ ਡੇਟਾਗ੍ਰਾਮ ਆਪਣੇ ਮੁੜ-ਭੇਜਣ ਤੱਕ ਇੱਕ ਤਬਾਦਲੇ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਬਾਹਰੀ ਆਵਾਜਾਈ TCP ਹੁੰਦੀ ਹੈ, ਸਾਰੇ ਅੰਦਰੂਨੀ ਪ੍ਰਵਾਹ ਇੱਕ ਭਰੋਸੇਯੋਗ ਬਾਈਟ ਪ੍ਰਵਾਹ ਸਾਂਝਾ ਕਰਦੇ ਹਨ।

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

ਆਪਣਾ ਸੈੱਟਅੱਪ ਸਹੀ ਢੰਗ ਨਾਲ ਬਿਆਨ ਕਰੋ

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

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