ਨੀਤੀ ਰਾਊਟਿੰਗ ਬਨਾਮ SOCKS: ਕਿਹੜੀ ਪਰਤ ਅਸਲ ਵਿੱਚ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਪ੍ਰੌਕਸੀ ਕਰਦੀ ਹੈ

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

ਰਾਊਟਿੰਗ, DNAT ਅਤੇ SOCKS ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਬਦਲਦੇ ਹਨ

ਨੀਤੀ ਰੂਟ ਪਰਤ 3 ਦੇ ਫ਼ੈਸਲੇ ਨੂੰ ਮੁੜ ਲਿਖਦਾ ਹੈ। ਇੱਕ ਕਲਾਇੰਟ ਦਾ ਟ੍ਰੈਫ਼ਿਕ ਚੁਣੇ ਗਏ ਅਗਲੇ ਹੌਪ ਵੱਲ ਭੇਜਣ ਲਈ ਦੋ ਲਾਈਨਾਂ ਕਾਫ਼ੀ ਹਨ:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

ਇਸ ਤੋਂ ਬਾਅਦ ਕਰਨਲ ਪੈਕੇਟ 10.50.0.2 ਨੂੰ ਸੌਂਪਦਾ ਹੈ, ਅਤੇ ਮੂਲ ਮੰਜ਼ਿਲ ਅਜੇ ਵੀ IP ਹੈਡਰ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ। ਜੇ 10.50.0.2 ਰਾਊਟਰ ਹੈ ਤਾਂ ਇਹ ਪੈਕੇਟ ਅੱਗੇ ਭੇਜਦਾ ਹੈ। ਜੇ ਇਹ 1080 'ਤੇ SOCKS ਡੈਮਨ ਵਾਲਾ ਹੋਸਟ ਹੈ, ਤਾਂ ਪੈਕੇਟ ਕਿਸੇ ਅਜਿਹੀ ਚੀਜ਼ ਵੱਲ ਨਹੀਂ ਹੈ ਜੋ ਇਸਨੂੰ ਸਵੀਕਾਰ ਕਰ ਸਕੇ, ਅਤੇ ਪੋਰਟ 1080 'ਤੇ DNAT ਵੀ ਮਦਦ ਨਹੀਂ ਕਰਦਾ, ਕਿਉਂਕਿ ਬਦਲਿਆ ਹੋਇਆ ਪੈਕੇਟ ਅਜੇ ਵੀ SOCKS ਸੁਆਗਤ ਦੀ ਥਾਂ ਮੂਲ ਐਪਲੀਕੇਸ਼ਨ ਪੇਲੋਡ ਲੈ ਕੇ ਚੱਲਦਾ ਹੈ।

SOCKS5 ਇੱਕ ਵਰਜ਼ਨ ਬਾਈਟ, ਢੰਗਾਂ ਦੀ ਸੂਚੀ, ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਅਦਲਾ-ਬਦਲੀ ਅਤੇ ਮੰਜ਼ਿਲ ਦਾ ਨਾਮ ਲੈਣ ਵਾਲੀ ਬੇਨਤੀ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਉਹ ਐਪਲੀਕੇਸ਼ਨ ਡੇਟਾ ਹੈ। ਕੋਈ ਰਾਊਟਿੰਗ ਐਂਟਰੀ ਜਾਂ netfilter ਟਾਰਗਿਟ ਇਸਨੂੰ ਪੈਦਾ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਇੱਕ ਲਾਈਨ ਵਿੱਚ ਤੁਲਨਾ ਇਹ ਹੈ: ਰਾਊਟਿੰਗ ਰਾਹ ਚੁਣਦੀ ਹੈ, SOCKS ਸਰਵਰ ਨੂੰ ਦੂਜਾ ਕਨੈਕਸ਼ਨ ਬਣਾਉਣ ਲਈ ਕਹਿੰਦਾ ਹੈ।

ਪਹਿਲਾ ਕੇਸ: ਐਪਲੀਕੇਸ਼ਨ ਆਪ SOCKS ਬੋਲ ਸਕਦੀ ਹੈ

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

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

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

ਦੂਜਾ ਕੇਸ: ਉਹ ਅਡਾਪਟਰ ਜੋ IP ਪ੍ਰਵਾਹਾਂ ਨੂੰ ਪ੍ਰੌਕਸੀ ਸੈਸ਼ਨਾਂ ਵਿੱਚ ਬਦਲਦਾ ਹੈ

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

ਪੂਰੇ ਸਬਨੈੱਟ ਨੂੰ ਇਸਦੇ ਭਰੋਸੇ ਛੱਡਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸਦਾ ਦਸਤਾਵੇਜ਼ ਪੜ੍ਹੋ। ਕਈ ਅਡਾਪਟਰ TCP ਚੰਗੀ ਤਰ੍ਹਾਂ ਢੋਂਦੇ ਹਨ ਅਤੇ UDP ਨੂੰ ਸਿਰਫ਼ SOCKS5 UDP ਐਸੋਸੀਏਸ਼ਨ ਰਾਹੀਂ ਸੰਭਾਲਦੇ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ICMP ਨੂੰ ਪ੍ਰੌਕਸੀ ਟ੍ਰੈਫ਼ਿਕ ਵਿੱਚ ਨਹੀਂ ਬਦਲਦਾ, ਇਸ ਲਈ ਸਫਲ ping ਪ੍ਰੌਕਸੀ ਰਾਹ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ। DNS ਦੂਜਾ ਜਾਲ ਹੈ: ਜੇ ਅਡਾਪਟਰ ਨਾਮ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਹੱਲ ਕਰਦਾ ਹੈ, ਤਾਂ ਸਿਰਫ਼-ਅੰਦਰੂਨੀ ਰਿਕਾਰਡ ਗਲਤ ਜਵਾਬ ਵਿੱਚ, ਜਾਂ ਬਿਲਕੁਲ ਕੁਝ ਨਹੀਂ ਵਿੱਚ ਹੱਲ ਹੁੰਦੇ ਹਨ।

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

ਤੀਜਾ ਕੇਸ: ਹੋਸਟ ਅਸਲ ਵਿੱਚ ਰਾਊਟ ਕੀਤਾ ਗੇਟਵੇ ਹੈ

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

ਤਿੰਨੇ ਕੇਸ ਛੇਤੀ ਵੱਖ ਹੋ ਜਾਂਦੇ ਹਨ। ਜਾਂਚੋ ਕਿ ਅਸਲ ਵਿੱਚ ਕੌਣ ਸੁਣ ਰਿਹਾ ਹੈ, ਫਿਰ ਹੋਸਟ ਤੱਕ ਪਹੁੰਚਣ ਵਾਲੇ ਪਹਿਲੇ ਬਾਈਟ ਵੇਖੋ:

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

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

ਚਾਰ ਸਵਾਲਾਂ ਨਾਲ ਪਰਤ ਚੁਣੋ

ਕੀ ਪ੍ਰੋਗਰਾਮ ਵਿੱਚ ਪ੍ਰੌਕਸੀ ਸੈਟਿੰਗ ਹੈ? ਇਸਦੀ ਵਰਤੋਂ ਕਰੋ ਅਤੇ ਉੱਥੇ ਹੀ ਰੁਕੋ। ਕੀ ਟ੍ਰੈਫ਼ਿਕ ਵਿੱਚ ਅਜਿਹਾ UDP ਜਾਂ ICMP ਹੈ ਜੋ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ? ICMP ਨੂੰ ਸਿਰਫ਼ ਰਾਊਟ ਕੀਤਾ ਜਾਂ NAT ਗੇਟਵੇ ਢੋਂਦਾ ਹੈ, ਅਤੇ UDP ਨੂੰ ਦੋਵੇਂ ਸਿਰਿਆਂ ਵੱਲੋਂ ਸਮਰਥਿਤ SOCKS5 ਐਸੋਸੀਏਸ਼ਨ ਚਾਹੀਦਾ ਹੈ। ਕੀ ਮਸ਼ੀਨ ਦੀ ਹਰ ਪ੍ਰਕਿਰਿਆ, ਉਹ ਵੀ ਜੋ ਤੁਸੀਂ ਸੰਰਚਿਤ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਢਕੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ? ਤਾਂ ਤੁਹਾਨੂੰ ਅਜਿਹਾ ਅਡਾਪਟਰ ਚਾਹੀਦਾ ਹੈ ਜੋ ਇੰਟਰਫ਼ੇਸ ਦਾ ਮਾਲਕ ਹੋਵੇ ਅਤੇ ਪ੍ਰਵਾਹ ਖ਼ਤਮ ਕਰੇ। ਕੀ ਤੁਸੀਂ ਇਸਦੀ ਰਾਊਟਿੰਗ, DNS ਅਤੇ ਲੂਪ-ਰੋਕਥਾਮ ਅਪਵਾਦ ਵੀ ਸੰਭਾਲ ਸਕਦੇ ਹੋ? ਨਹੀਂ ਤਾਂ ਸਾਧਾਰਨ ਗੇਟਵੇ ਚਲਾਉਣਾ ਘੱਟ ਖ਼ਰਚੀਲਾ ਹੋਵੇਗਾ।

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