Android ਦਾ ਇੱਕ-VPN ਨਿਯਮ ਹੋਸਟ ਕੀਤੇ SSH ਸਰਵਰ ਨੂੰ ਨਹੀਂ ਰੋਕਦਾ

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

ਇੱਕ-VPN ਨਿਯਮ ਅਸਲ ਵਿੱਚ ਕੀ ਸੀਮਿਤ ਕਰਦਾ ਹੈ

VpnService ਇੱਕ-ਸਲਾਟ ਸਰੋਤ ਹੈ। ਜਦੋਂ ਕੋਈ ਐਪ ਟਨਲ ਸਥਾਪਿਤ ਕਰਦੀ ਹੈ ਤਾਂ ਉਹ ਡਿਵਾਈਸ ਦਾ VPN ਬਣ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਦੂਜੀ ਐਪ ਜੋ ਟਨਲ ਸਥਾਪਿਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ, ਪਹਿਲੀ ਦੇ ਹਟਣ ਤੱਕ ਰੱਦ ਕਰ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਟਨਲ ਦੀ ਮਾਲਕੀ ਦਾ ਨਿਯਮ ਹੈ, ਅਤੇ ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਦੋ VPN ਕਲਾਇੰਟ ਇੱਕੋ ਸਮੇਂ ਕਿਉਂ ਨਹੀਂ ਚੱਲ ਸਕਦੇ।

ਇਹ ਸੁਣਨ ਵਾਲੇ ਸਾਕਟਾਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। SSH ਸਰਵਰ VpnService ਨੂੰ ਕਾਲ ਨਹੀਂ ਕਰਦਾ, ਪੈਕਟ ਨਹੀਂ ਰੋਕਦਾ ਅਤੇ ਉਸ ਸਲਾਟ ਲਈ ਮੁਕਾਬਲਾ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਇੱਕ ਪੋਰਟ ਬਾਈਂਡ ਕਰਦਾ ਹੈ ਅਤੇ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਜੋ VPN ਬਿਲਕੁਲ ਨਾ ਹੋਣ 'ਤੇ ਵੀ ਉਹੀ ਕਰਦਾ। ਇਸ ਲਈ ਇਹ ਮਿੱਥ ਟਨਲ ਪ੍ਰਦਾਤਾਵਾਂ ਦੀ ਹੱਦ ਨੂੰ ਨੈੱਟਵਰਕ ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਹੱਦ ਨਾਲ ਮਿਲਾ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਦੋਹਾਂ ਦਾ ਆਪਸ ਵਿੱਚ ਕੋਈ ਸੰਬੰਧ ਨਹੀਂ।

ਲਿਸਨਰ ਇੱਕ ਮੰਜ਼ਿਲ ਹੈ, ਟਨਲ ਦਾ ਹਿੱਸਾ ਨਹੀਂ

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

ਬਾਈਂਡਿੰਗ ਨਿਯਮ ਆਮ SSH ਸੰਰਚਨਾ ਹਨ: ਸੁਣਨ ਵਾਲਾ ਪਤਾ ਅਤੇ ਪੋਰਟ, ਅਤੇ ਕੌਣ ਪ੍ਰਮਾਣਿਤ ਕਰ ਸਕਦਾ ਹੈ। Android 'ਤੇ ਉਹ ਸੈਟਿੰਗਾਂ ਐਪ ਦੀ ਆਪਣੀ ਸੰਰਚਨਾ ਵਿੱਚ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਐਪ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦੇ ਮਾਲਕ ਨੂੰ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਾਲੇ ਪੋਰਟ ਵਰਤਣ ਦੀ ਆਗਿਆ ਨਹੀਂ ਹੋ ਸਕਦੀ, ਇਸ ਲਈ root ਵਜੋਂ ਪੋਰਟ 22 ਬਾਈਂਡ ਕਰਨ ਦੀ ਡੈਸਕਟਾਪ ਆਦਤ ਬਿਨਾਂ ਬਦਲਾਅ ਦੇ ਨਹੀਂ ਜਾਂਦੀ।

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

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

ਜਵਾਬ ਮਾਰਗ ਹੀ ਆਮ ਤੌਰ 'ਤੇ ਟੁੱਟਣ ਦੀ ਥਾਂ ਹੈ

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

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

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

VPN ਨੂੰ ਬਾਈਪਾਸ ਕਰਨਾ ਆਉਂਦੀ ਸੇਵਾ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦਾ

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

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

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

ਇੱਕ ਸਮੇਂ ਇੱਕ ਦਿਸ਼ਾ ਦੀ ਜਾਂਚ ਕਰੋ

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

adb shell ip -br addr
adb shell ip route get 10.90.0.9
nc -vz 10.90.0.4 2222

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

ਡੀਬੱਗ ਕਰਦੇ ਸਮੇਂ ਹੋਸਟ-ਕੀ ਪਰਖ ਅਤੇ ਖਾਤਾ ਪਾਬੰਦੀਆਂ ਨੂੰ ਅਟੱਲ ਰੱਖੋ। ਲਿਸਨਰ ਅਤੇ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਸੀਮਿਤ ਕਰਨਾ ਹੀ ਪਹੁੰਚਯੋਗ ਸਰਵਰ ਨੂੰ ਸਵੀਕਾਰਯੋਗ ਬਣਾਉਂਦਾ ਹੈ; ਕਨੈਕਸ਼ਨ ਚੱਲੇ ਇਸ ਲਈ ਉਹਨਾਂ ਨੂੰ ਢਿੱਲਾ ਕਰਨਾ ਇੱਕ ਸਮੱਸਿਆ ਨੂੰ ਹੋਰ ਮਾੜੀ ਨਾਲ ਬਦਲਦਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ Android ਅਮਲ ਉਹੀ ਸੰਰਚਨਾ ਨਾਮ ਅਪਣਾਉਂਦਾ ਹੈ ਤਾਂ OpenSSH ਸਰਵਰ ਸੰਦਰਭ ਸੁਣਨ ਅਤੇ ਪਹੁੰਚ ਨਿਯੰਤਰਣਾਂ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ।