ਸਿਰਫ਼ IPv6 ਕਨੈਕਸ਼ਨ, IPv4 ਸੇਵਾ: SOCKS ਪ੍ਰੌਕਸੀ ਨੂੰ ਪੁਲ ਬਣਨ ਦਿਓ

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

ਦੋ ਸਾਕਟ, ਦੋ ਪਤਾ ਪਰਿਵਾਰ

SOCKS5 ਬੇਨਤੀ ਮੰਜ਼ਿਲ ਨੂੰ ਤਿੰਨ ਰੂਪਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ ਨਾਮ ਦਿੰਦੀ ਹੈ: ਸ਼ਬਦੀ v4 ਪਤਾ, ਸ਼ਬਦੀ v6 ਪਤਾ, ਜਾਂ ਪ੍ਰੌਕਸੀ ਵੱਲੋਂ ਹੱਲ ਕਰਨ ਵਾਲਾ ਨਾਮ। ਬੇਨਤੀ ਦੱਸਦੀ ਹੈ ਕਿ ਪ੍ਰੌਕਸੀ ਨੂੰ ਕਿੱਥੇ ਜੁੜਨਾ ਚਾਹੀਦਾ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ ਕਲਾਇੰਟ-ਤੋਂ-ਪ੍ਰੌਕਸੀ ਕਨੈਕਸ਼ਨ ਕਿਹੋ ਜਿਹਾ ਦਿਸਦਾ ਹੈ।

ਇਹਨਾਂ ਪਤਾ ਕਿਸਮਾਂ ਨੂੰ ਇੱਕ ਸੁਨੇਹੇ ਅੰਦਰ ਤਿੰਨ ਸੁਤੰਤਰ ਚੋਣਾਂ ਵਜੋਂ ਪੜ੍ਹੋ। IPv6 ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਪ੍ਰੌਕਸੀ IPv4 ਮੰਜ਼ਿਲ ਦਾ ਸਾਕਟ ਖੋਲ੍ਹ ਸਕਦੀ ਹੈ ਜਦੋਂ ਉਸ ਕੋਲ ਕੰਮ ਕਰਨ ਵਾਲਾ IPv4 ਆਉਟਗੋਇੰਗ ਹੋਵੇ ਅਤੇ ਉਸ ਦੀ ਨੀਤੀ ਬੇਨਤੀ ਦੀ ਆਗਿਆ ਦੇਵੇ। SOCKS5 ਵਿਸ਼ੇਸ਼ਣ ਕਲਾਇੰਟ ਦੇ ਆਵਾਜਾਈ ਦਾ ਕੋਈ ਜ਼ਿਕਰ ਕੀਤੇ ਬਿਨਾਂ ਹੀ ਇਹਨਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ।

ਨਿਯੰਤਰਿਤ SSH ਉਦਾਹਰਨ

ਇੱਕ SSH ਹੋਸਟ ਲਓ ਜਿਸ ਨੂੰ ਵਰਤਣ ਦੀ ਤੁਹਾਨੂੰ ਆਗਿਆ ਹੈ, ਜੋ IPv6 'ਤੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ ਆਪ ਹੀ ਸਿਰਫ਼ v4 'ਤੇ ਮੌਜੂਦ HTTPS ਸੇਵਾ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। OpenSSH ਦੀ ਗਤੀਸ਼ੀਲ ਫਾਰਵਰਡਿੰਗ ਲੌਗਇਨ ਸੈਸ਼ਨ v6 ਰਾਹੀਂ ਚੱਲਦੇ ਸਮੇਂ ਤੁਹਾਡੀ ਮਸ਼ੀਨ 'ਤੇ ਸਥਾਨਕ SOCKS ਸਰੋਤਾ ਰੱਖਦੀ ਹੈ।

ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]

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

ਸੈਸ਼ਨ ਚੱਲਦੇ ਸਮੇਂ ਬੇਨਤੀ ਇਸ ਤਰ੍ਹਾਂ ਦਿਸਦੀ ਹੈ:

curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/

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

ਮੰਜ਼ਿਲ ਅਸਲ ਵਿੱਚ ਕੀ ਦੇਖਦੀ ਹੈ

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

ਰੀਲੇ ਉਹ ਥਾਂ ਵੀ ਹੈ ਜਿੱਥੇ ਗੱਲਬਾਤ ਦੇ ਦੋਵੇਂ ਅੱਧ ਦਿਸਦੇ ਹਨ, ਜੋ ਨਿਦਾਨ ਵੇਲੇ ਲਾਹੇਵੰਦ ਗੁਣ ਹੈ ਅਤੇ ਨੀਤੀ ਤੋਂ ਬਿਨਾਂ ਰੀਲੇ ਸਾਂਝੀ ਕੀਤੀ ਜਾਵੇ ਤਾਂ ਭਾਰ ਹੈ।

ਇਹ DNS64 ਜਾਂ NAT64 ਨਹੀਂ ਹੈ

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

ਦੋਵੇਂ ਕਾਰਜਵਿਧੀਆਂ ਇੱਕੋ ਨੈੱਟਵਰਕ ਵਿੱਚ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਜੋ ਸਭ ਤੋਂ ਨੇੜੇ ਸੁਣਾਈ ਦੇਵੇ ਉਸ ਦੀ ਥਾਂ ਜੋ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਜਾਂਚਿਆ ਹੈ ਉਸ ਦਾ ਵਰਣਨ ਕਰੋ।

ਵਾਅਦਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦਾਇਰਾ ਜਾਣੋ

OpenSSH ਦੀ ਗਤੀਸ਼ੀਲ ਫਾਰਵਰਡਿੰਗ TCP ਕਨੈਕਸ਼ਨ ਲੈ ਜਾਂਦੀ ਹੈ, ਮਨਮਾਨੀ IP ਟ੍ਰੈਫਿਕ ਨਹੀਂ, ਇਸ ਲਈ UDP, ICMP ਅਤੇ ਪ੍ਰੌਕਸੀ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਵਾਲੇ ਕਿਸੇ ਵੀ ਪ੍ਰੋਟੋਕਾਲ ਲਈ ਵੱਖਰਾ ਸਮਰਥਿਤ ਡਿਜ਼ਾਈਨ ਚਾਹੀਦਾ ਹੈ। SSH ਹੋਸਟ-ਕੁੰਜੀ ਜਾਂਚ, ਸਰਵਰ ਦੇ ਫਾਰਵਰਡਿੰਗ ਪਾਬੰਦੀਆਂ ਅਤੇ HTTPS ਸਰਟੀਫਿਕੇਟ ਜਾਂਚ ਬਣਾਈ ਰੱਖੋ, ਕਿਉਂਕਿ ਪ੍ਰੌਕਸੀ ਇੱਕ ਵਾਧੂ ਭਰੋਸੇਯੋਗ ਭਾਗੀਦਾਰ ਹੈ, ਪਛਾਣ ਜਾਂਚ ਕਮਜ਼ੋਰ ਕਰਨ ਦਾ ਕਾਰਨ ਨਹੀਂ। ਜੇ ਟੀਚਾ VPN ਦੀ ਬਾਹਰੀ ਆਵਾਜਾਈ ਪ੍ਰੌਕਸੀ ਰਾਹੀਂ ਲੈ ਜਾਣਾ ਹੈ, ਤਾਂ ਇਹ ਮੰਨਣ ਦੀ ਥਾਂ ਕਿ ਕੋਈ ਵੀ SOCKS ਸਰੋਤਾ ਇਸ ਨੂੰ ਰੀਲੇ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂਚੋ ਕਿ ਦੋਵੇਂ ਸਿਰੇ ਉਸ ਆਵਾਜਾਈ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ।

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