ਪੂਰੀ ਮਸ਼ੀਨ ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਐਪ ਨੂੰ VPN ਰਾਹੀਂ ਕਿਵੇਂ ਰੂਟ ਕਰੀਏ
ਕੋਈ ਵੀ ਬਿਨਾਂ ਪ੍ਰਬੰਧ ਵਾਲਾ ਡੈਸਕਟਾਪ ਪ੍ਰਤੀ-ਪ੍ਰਕਿਰਿਆ VPN ਸਵਿੱਚ ਨਹੀਂ ਦਿੰਦਾ। ਟ੍ਰੈਫਿਕ ਚੁਣਨ ਵਾਲੀ ਪਰਤ ਆਪ ਚੁਣੋ: ਬਾਈਂਡ ਕੀਤਾ ਸਾਕਟ, UID ਨਿਯਮ, ਫਾਇਰਵਾਲ ਪ੍ਰੋਫਾਈਲ ਜਾਂ SOCKS ਹੌਪ।
VPN ਕਲਾਇੰਟ ਜੁੜਦਾ ਹੈ, ਬ੍ਰਾਊਜ਼ਰ ਚੱਲਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਨੂੰ ਸੱਚਮੁੱਚ ਲੋੜੀਂਦਾ ਉਹ ਇੱਕ ਹੁਕਮ ਅਜੇ ਵੀ ਤੁਹਾਡੇ ਘਰ ਦੇ ਕਨੈਕਸ਼ਨ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ। ਜਾਂ ਉਲਟਾ ਹੁੰਦਾ ਹੈ: ਟਨਲ ਡਿਫ਼ਾਲਟ ਰੂਟ ਫੜ ਲੈਂਦਾ ਹੈ ਅਤੇ ਸਥਾਨਕ ਫਾਈਲ ਸਰਵਰ ਡੈਸਕਟਾਪ ਤੋਂ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ। ਮੈਨੂੰ ਇਹ ਇੱਕ ਬਿਲਡ ਏਜੰਟ ਨਾਲ ਹੋਇਆ, ਜਿਸਨੂੰ ਅੰਦਰੂਨੀ ਆਰਟੀਫੈਕਟ ਮਿਰਰ ਤੱਕ ਪਹੁੰਚਣਾ ਸੀ ਜਦੋਂ ਕਿ ਹੋਸਟ ਦਾ ਬਾਕੀ ਹਿੱਸਾ ਦਫ਼ਤਰ ਦੇ LAN ਉੱਤੇ ਹੀ ਰਿਹਾ, ਅਤੇ ਕਲਾਇੰਟ ਨੇ ਠੀਕ ਦੋ ਚੋਣਾਂ ਦਿੱਤੀਆਂ, ਸਾਰਾ ਟ੍ਰੈਫਿਕ ਜਾਂ ਕੁਝ ਵੀ ਨਹੀਂ। ਦੋਵੇਂ ਪਾਸਿਓਂ ਬੇਨਤੀ ਇੱਕੋ ਹੀ ਹੈ, ਇਹ ਪ੍ਰੋਗਰਾਮ ਅਤੇ ਪੂਰੀ ਮਸ਼ੀਨ ਨਹੀਂ, ਅਤੇ ਬਹੁਤੇ ਕਲਾਇੰਟਾਂ ਕੋਲ ਇਸ ਲਈ ਚੈੱਕ ਬਾਕਸ ਨਹੀਂ, ਕਿਉਂਕਿ ਰੂਟ ਟੇਬਲ ਕਦੇ ਨਹੀਂ ਜਾਣਦੀ ਕਿ ਪ੍ਰੋਗਰਾਮ ਕੀ ਹੁੰਦਾ ਹੈ।
ਰੂਟ ਟੇਬਲ ਤੁਹਾਡਾ ਪ੍ਰੋਗਰਾਮ ਕਿਉਂ ਨਹੀਂ ਵੇਖ ਸਕਦੀ
ਜਦੋਂ ਕੋਈ ਪ੍ਰਕਿਰਿਆ ਪੈਕੇਟ ਭੇਜਦੀ ਹੈ, ਸਟੈਕ ਰੂਟ ਟੇਬਲ ਵਿੱਚ ਮੰਜ਼ਿਲ ਦਾ ਪਤਾ ਲੱਭਦਾ ਹੈ। ਨਾ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਦਾ ਨਾਂ ਅਤੇ ਨਾ ਪੋਰਟ ਉਸ ਲੱਭਤ ਵਿੱਚ ਆਉਂਦਾ ਹੈ। ਡੋਮੇਨ ਨਾਂ ਇਸੇ ਕਾਰਨ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ: ਟਨਲ ਟ੍ਰੈਫਿਕ ਨੂੰ ਇੱਕ ਪਤੇ ਤੱਕ ਲੈ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਨਾਂ ਪਤੇ ਵਿੱਚ ਹੱਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਕਰਨਲ ਕੋਲ ਬਚਿਆ ਇਕੋ ਲੀਵਰ ਰੂਟਿੰਗ ਹੁੰਦਾ ਹੈ। ਇਸੇ ਲਈ “ਸਿਰਫ਼ ਇਸ ਸਾਈਟ ਲਈ VPN” ਦਾ ਮਤਲਬ ਪ੍ਰੌਕਸੀ ਅਤੇ “ਸਿਰਫ਼ ਇਸ ਪ੍ਰੋਗਰਾਮ ਲਈ VPN” ਦਾ ਮਤਲਬ ਥੋੜ੍ਹੇ ਜਿਹੇ ਕਾਰਜਵਿਧੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਬਣ ਜਾਂਦਾ ਹੈ।
| Mechanism | What selects | Covers | On tunnel drop |
|---|---|---|---|
| Socket bind | source address | a client you control | connections fail |
| UID rule (Linux) | owning user | every process of one account | connections fail |
| Firewall profile (Windows) | adapter profile | one program | fails closed |
| Network namespace | namespace membership | everything started inside | connections fail |
| SOCKS hop | app proxy setting | one app or one browser profile | connections fail |
ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਪ੍ਰਤੀ-ਪ੍ਰਕਿਰਿਆ ਰੂਟ ਨਹੀਂ। ਹਰ ਇੱਕ ਫੈਸਲੇ ਨੂੰ ਉਸ ਪਰਤ ਵੱਲ ਭੇਜਦਾ ਹੈ ਜੋ ਪ੍ਰੋਗਰਾਮ, ਵਰਤੋਂਕਾਰ ਜਾਂ ਐਪ ਦੀ ਆਪਣੀ ਸੰਰਚਨਾ ਵੇਖ ਸਕਦੀ ਹੈ।
ਇੱਕੋ ਮੰਜ਼ਿਲ ਅਜੇ ਵੀ ਰੂਟ ਹੈ, ਪ੍ਰੋਗਰਾਮ ਨਿਯਮ ਨਹੀਂ। macOS ਉੱਤੇ ਆਮ ਤਰੀਕਾ ਹੈ “ਸਾਰਾ ਟ੍ਰੈਫਿਕ VPN ਰਾਹੀਂ ਭੇਜੋ” ਦਾ ਨਿਸ਼ਾਨ ਹਟਾਉਣਾ ਅਤੇ ਹੋਸਟ ਰੂਟ ਜੋੜਨਾ: sudo route add -host internal-tuner.example -interface ppp0, ਫਿਰ sudo route delete -host internal-tuner.example -interface ppp0 ਨਾਲ ਮੁੜ ਹਟਾਇਆ ਜਾਂਦਾ ਹੈ। ਪਹਿਲਾਂ ifconfig ਤੋਂ ਇੰਟਰਫ਼ੇਸ ਦਾ ਨਾਂ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ppp0 ਸਿਰਫ਼ ਇੱਕ ਉਦਾਹਰਨ ਹੈ। ਹੋਸਟ ਰੂਟ ਵਿੱਚ ਵਾਈਲਡਕਾਰਡ ਨਹੀਂ ਚੱਲਦੇ, ਇਸ ਲਈ ਕਈ ਨਾਵਾਂ ਨਾਲ ਗੱਲ ਕਰਨ ਵਾਲੀ ਸੇਵਾ ਨੂੰ ਹਰ ਨਾਂ ਲਈ ਇੱਕ ਐਂਟਰੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਇਹ ਨਿਯਮ ਮਸ਼ੀਨ ਦੀ ਹਰ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ, ਸਿਰਫ਼ ਤੁਹਾਡੇ ਦਿਮਾਗ਼ ਵਾਲੀ ਨੂੰ ਨਹੀਂ।
ਸਾਕਟ ਨੂੰ ਟਨਲ ਪਤੇ ਨਾਲ ਬਾਈਂਡ ਕਰੋ
ਜਦੋਂ ਤੁਸੀਂ ਕਲਾਇੰਟ ਕੰਟਰੋਲ ਕਰਦੇ ਹੋ, ਬਾਈਂਡਿੰਗ ਸਭ ਤੋਂ ਸਸਤਾ ਚੋਣਕਾਰ ਹੈ। ਟਨਲ ਦੇ ਸਥਾਨਕ ਪਤੇ ਨਾਲ ਬਾਈਂਡ ਕੀਤਾ ਸਾਕਟ ਉਸੇ ਇੰਟਰਫ਼ੇਸ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ ਜਿੰਨਾ ਚਿਰ ਮੰਜ਼ਿਲ ਦਾ ਰੂਟ ਉੱਥੇ ਮੌਜੂਦ ਹੈ, ਅਤੇ ਮਸ਼ੀਨ ਉੱਤੇ ਬਾਕੀ ਸਭ ਆਪਣਾ ਆਮ ਰਾਹ ਰੱਖਦਾ ਹੈ। ਬਾਰੀਕ ਗੱਲ ਇਹ ਹੈ ਕਿ ਬਾਈਂਡ ਸਰੋਤ ਪਤਾ ਚੁਣਦਾ ਹੈ ਪਰ ਰੂਟ ਟੇਬਲ ਅਜੇ ਵੀ ਨਿਕਾਸ ਚੁਣਦੀ ਹੈ। ਸਿਰਫ਼ ਬਾਈਂਡ ਟਨਲ ਵਿੱਚ ਰੂਟ ਰਹਿਤ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਭੇਜਦਾ, ਅਤੇ ਇਹੀ “ਮੈਂ ਬਾਈਂਡ ਕੀਤਾ ਪਰ ਇਹ ਅਜੇ ਵੀ ਗਲਤ ਰਾਹ ਜਾਂਦਾ ਹੈ” ਵਾਲੀਆਂ ਬਹੁਤੀਆਂ ਰਿਪੋਰਟਾਂ ਪਿੱਛੇ ਗਲਤੀ ਹੈ।
import socket
s = socket.socket()
s.bind(("10.8.0.2", 0))
s.connect(("build.internal.example", 443))ਉੱਚ-ਪੱਧਰੀ ਸਾਧਨ ਇਹੀ ਵਿਚਾਰ ਦਿਖਾਉਂਦੇ ਹਨ: curl --interface 10.8.0.2, PHP ਦਾ CURLOPT_INTERFACE, ਅਤੇ Python ਦੇ HTTP ਕਲਾਇੰਟਾਂ ਵਿੱਚ source_address ਦਲੀਲ। ਪਤਾ ਟਨਲ ਦਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇੱਥੇ ਟਾਈਪਿੰਗ ਦੀ ਗਲਤੀ ਰੂਟ ਦੀ ਸ਼ਿਕਾਇਤ ਨਹੀਂ, ਆਮ ਕਨੈਕਸ਼ਨ ਗਲਤੀ ਵਜੋਂ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ। ਪਤੇ ਦੀ ਥਾਂ ਡਿਵਾਈਸ ਨਾਂ ਨਾਲ ਬਾਈਂਡ ਕਰਨਾ Linux ਦਾ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਹੈ ਅਤੇ Windows ਜਾਂ macOS ਵਿੱਚ ਨਹੀਂ ਜਾਂਦਾ, ਇਸ ਲਈ ਪੋਰਟੇਬਲ ਸਕ੍ਰਿਪਟਾਂ ਪਤਾ ਭੇਜਦੀਆਂ ਹਨ।
Linux: ਪ੍ਰੋਗਰਾਮ ਦਾ ਨਾਂ ਨਹੀਂ, ਮਾਲਕ ਮਿਲਾਓ
ਕਰਨਲ ਸਾਕਟ ਦੇ ਮਾਲਕ ਵਰਤੋਂਕਾਰ ਨਾਲ ਮਿਲਾ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਸਮਰਪਿਤ ਖਾਤਾ ਹੀ ਚੋਣਕਾਰ ਬਣ ਜਾਂਦਾ ਹੈ।
ip rule add uidrange 1001-1001 lookup 100
ip route add default dev tun0 table 100ਇਹ ਤਦ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜੇ ਟਨਲ ਪਹਿਲਾਂ ਹੀ ਡਿਫ਼ਾਲਟ ਰੂਟ ਨਹੀਂ। ਕਲਾਇੰਟ ਨੂੰ --route-nopull ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਜਾਂ --pull-filter ignore "redirect-gateway" ਵਰਤ ਕੇ ਧੱਕੇ ਗਏ ਰੀਡਾਇਰੈਕਟ ਨੂੰ OpenVPN 2.4 ਅਤੇ ਬਾਅਦ ਦੇ ਸੰਸਕਰਣਾਂ ਉੱਤੇ ਫਿਲਟਰ ਕਰੋ, ਫਿਰ ਟੇਬਲ ਐਂਟਰੀ ਆਪ ਜੋੜੋ। ਨਹੀਂ ਤਾਂ ਦੋਵੇਂ ਡਿਫ਼ਾਲਟ ਹੁੰਦੇ ਹਨ ਅਤੇ ਘੱਟ ਤਰਜੀਹ ਵਾਲਾ ਜਿੱਤਦਾ ਹੈ। ਇਸਦਾ ਜਾਣ-ਬੁੱਝ ਕੇ ਕੀਤਾ ਸੰਸਕਰਣ ਡਿਫ਼ਾਲਟ ਰੂਟ ਨੂੰ ਟਨਲ ਗੇਟਵੇ ਵੱਲ ਮੋੜਨਾ, ਜਾਂ ਡਿਸਕਨੈਕਟ ਸਕ੍ਰਿਪਟ ਤੋਂ ਕਰਨਾ ਹੈ: ਟਨਲ ਡਿੱਗਣ ਵੇਲੇ ਇਹ ਟ੍ਰੈਫਿਕ ਨੂੰ ਇੰਟਰਨੈੱਟ ਤੋਂ ਦੂਰ ਰੱਖਦਾ ਹੈ, ਪਰ ਉਹ ਕਿੱਲ ਸਵਿੱਚ ਹੈ, ਚੋਣਕਾਰ ਨਹੀਂ, ਅਤੇ ਕੋਈ ਹਟਾਏ ਬਿਨਾਂ ਉਹ ਰਹਿੰਦਾ ਹੈ।
ਵਧੇਰੇ ਮਜ਼ਬੂਤ ਸੰਸਕਰਣ ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ ਹੈ। ਇਸਨੂੰ ਬਣਾਓ, ਕਲਾਇੰਟ ਅੰਦਰ ਚਲਾਓ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ip netns exec ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਨੇਮਸਪੇਸ ਤੋਂ ਬਾਹਰ ਕੋਈ ਟਨਲ ਇੰਟਰਫ਼ੇਸ ਨਹੀਂ ਵੇਖਦਾ, ਇਸ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਹਾਦਸਾਵਸ਼ ਹੋਸਟ ਰੂਟ ਉੱਤੇ ਵਾਪਸ ਨਹੀਂ ਡਿੱਗ ਸਕਦੀ। ਲਾਗਤ ਅਸਲੀ ਹੈ: ਨੇਮਸਪੇਸ ਨੂੰ ਭੌਤਿਕ ਨੈੱਟਵਰਕ ਤੱਕ ਪਹੁੰਚਣ ਲਈ veth ਜੋੜੀ ਅਤੇ ਆਪਣੀ ਰਿਜ਼ੌਲਵਰ ਫਾਈਲ ਚਾਹੀਦੀ ਹੈ, ਕਿਉਂਕਿ ਮਾਊਂਟ ਨੇਮਸਪੇਸ ਹੋਸਟ ਦੀਆਂ ਰਿਜ਼ੌਲਿਊਸ਼ਨ ਸੈਟਿੰਗਾਂ ਸਾਂਝੀਆਂ ਨਹੀਂ ਕਰਦਾ।
ਦੋ ਫੇਲ੍ਹ ਮੋਡ ਬਹੁਤੀਆਂ ਲੀਕਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦੇ ਹਨ। ਨਾਂ ਹੱਲ ਅਜੇ ਵੀ ਹੋਸਟ ਦੇ ਰਿਜ਼ੌਲਵਰ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ TCP ਕਨੈਕਸ਼ਨ ਅੰਦਰ ਜਾਣ ਵੇਲੇ ਵੀ ਕਵੈਰੀ ਟਨਲ ਤੋਂ ਬਾਹਰ ਜਾਂਦੀ ਹੈ। ਅਤੇ IPv6 ਲਈ ਆਪਣਾ ip -6 rule ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ v4 ਨਿਯਮ ਇਸਨੂੰ ਨਹੀਂ ਢਕਦਾ।
Windows ਅਤੇ macOS: ਫਾਇਰਵਾਲ ਦਾ ਦਾਇਰਾ ਤੈਅ ਕਰੋ ਜਾਂ ਪ੍ਰੌਕਸੀ ਦਿਓ
Windows ਵਿੱਚ ਵੀ ਪ੍ਰਤੀ-ਐਪਲੀਕੇਸ਼ਨ ਰੂਟ ਚੋਣਕਾਰ ਨਹੀਂ, ਪਰ ਇਸਦੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਪ੍ਰੋਫਾਈਲ ਤੱਕ ਸੀਮਤ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਅਤੇ VPN ਐਡਾਪਟਰ ਨੂੰ ਜਨਤਕ ਵਜੋਂ ਸ਼੍ਰੇਣੀਬੱਧ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਘਰ ਦਾ LAN ਨਿੱਜੀ ਰਹਿੰਦਾ ਹੈ। ਨਿੱਜੀ ਅਤੇ ਡੋਮੇਨ ਪ੍ਰੋਫਾਈਲਾਂ ਉੱਤੇ ਪ੍ਰੋਗਰਾਮ ਲਈ ਬਾਹਰੀ ਬਲਾਕ ਨਿਯਮ ਬਣਾਓ, ਜਨਤਕ ਖੁੱਲ੍ਹਾ ਛੱਡੋ, ਫਿਰ ਐਪਲੀਕੇਸ਼ਨ ਸਿਰਫ਼ ਟਨਲ ਰਾਹੀਂ ਨੈੱਟਵਰਕ ਤੱਕ ਪਹੁੰਚ ਸਕਦੀ ਹੈ। ਪਹਿਲਾਂ ਕਨੈਕਸ਼ਨ ਦੀ ਨੈੱਟਵਰਕ ਸ਼੍ਰੇਣੀ ਤੈਅ ਕਰੋ, ਫਿਰ ਫਾਇਰਵਾਲ ਦੇ ਮਾਨੀਟਰ ਪੈਨਲ ਵਿੱਚ ਨਿਯਮ ਮਿਲਿਆ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਇਹ ਰੂਟ ਨਹੀਂ, ਬਲਾਕ ਹੈ: ਟਨਲ ਡਿੱਗਣ ਵੇਲੇ ਇਹ ਬੰਦ ਹੋ ਕੇ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਫਾਇਰਵਾਲ ਨੂੰ ਅਣਡਿੱਠ ਕਰਨ ਵਾਲੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਇਹ ਰੋਕ ਨਹੀਂ ਸਕਦਾ।
macOS ਉਹੀ ਤਰਕ ਵੱਖਰੇ ਸਾਧਨਾਂ ਨਾਲ ਅਪਣਾਉਂਦਾ ਹੈ। SSH ਰਾਹੀਂ ਪਹੁੰਚਣ ਵਾਲਾ SOCKS ਸਰੋਤਾ ਸਭ ਤੋਂ ਘੱਟ ਦਖ਼ਲ ਵਾਲਾ ਬਦਲ ਹੈ, ਕਿਉਂਕਿ ssh -D 1080 user@host ਇੱਕ ਸਥਾਨਕ ਪੋਰਟ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਇਸਨੂੰ ਵਰਤਣ ਲਈ ਸੈੱਟ ਐਪਲੀਕੇਸ਼ਨਾਂ ਹੀ ਉਹ ਰਾਹ ਲੈਂਦੀਆਂ ਹਨ। pf ਨਿਯਮ ਵਰਤੋਂਕਾਰ ਜਾਂ ਸਮੂਹ ਅਨੁਸਾਰ ਪ੍ਰੋਗਰਾਮ ਬਲਾਕ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਉਸ ਪ੍ਰੋਗਰਾਮ ਲਈ ਇਕੱਲਾ ਟਨਲ ਨਹੀਂ ਚੁਣ ਸਕਦਾ। Tunnelblick ਡੋਮੇਨ ਅਨੁਸਾਰ ਫਿਲਟਰ ਕਰ ਹੀ ਨਹੀਂ ਸਕਦਾ, ਕਿਉਂਕਿ ਰੂਟ ਪਤਿਆਂ ਉੱਤੇ ਚੱਲਦੇ ਹਨ; OpenConnect ਵਰਤੋਂਕਾਰ ਸਰਵਰ ਵੱਲੋਂ ਬਹੁਤ ਚੌੜੀ ਪ੍ਰੀਫਿਕਸ ਸੂਚੀ ਧੱਕੇ ਜਾਣ ਵੇਲੇ vpn-slice ਵੱਲ ਜਾਂਦੇ ਹਨ।
ਪਲੇਟਫਾਰਮ ਸਾਧਨਾਂ ਵੱਲੋਂ ਛੱਡੀ ਗਈ ਥਾਂ ਦੋ ਹੱਲ ਭਰਦੇ ਹਨ। ਡੋਮੇਨ ਅਨੁਸਾਰ ਪ੍ਰੌਕਸੀ ਬਦਲਣ ਵਾਲੇ ਬ੍ਰਾਊਜ਼ਰ ਐਕਸਟੈਂਸ਼ਨ “ਸਿਰਫ਼ ਇਹ ਸਾਈਟ” ਲਈ ਵਿਹਾਰਕ ਜਵਾਬ ਹਨ, ਕਿਉਂਕਿ ਉਹ ਐਪਲੀਕੇਸ਼ਨ ਪਰਤ ਉੱਤੇ ਕੰਮ ਕਰਦੇ ਹਨ ਜਿੱਥੇ ਨਾਂ ਅਜੇ ਵੀ ਮੌਜੂਦ ਹਨ; ਉਹ ਇੱਕ ਬ੍ਰਾਊਜ਼ਰ ਹੀ ਢਕਦੇ ਹਨ, ਹੋਰ ਕੁਝ ਨਹੀਂ। ਸਖ਼ਤ ਤਰੀਕਾ ਹੈ ਵਿਕਰੇਤਾ ਦਾ ਕਲਾਇੰਟ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਅੰਦਰ ਚਲਾਉਣਾ ਤਾਂ ਕਿ ਮਹਿਮਾਨ ਰੂਟ ਬਦਲਣ ਦਾ ਮਾਲਕ ਹੋਵੇ ਅਤੇ ਹੋਸਟ ਆਪਣਾ ਰਾਹ ਰੱਖੇ, ਪਰ ਦੋ ਨੈੱਟਵਰਕ ਸਟੈਕ ਸੰਭਾਲਣ ਦੀ ਲਾਗਤ ਪੈਂਦੀ ਹੈ।
ਬਾਈਂਡ ਬਦਲ ਨਾ ਵਾਲੇ ਸਾਧਨਾਂ ਲਈ SOCKS ਹੌਪ
ਬਹੁਤੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ HTTP ਜਾਂ SOCKS ਪ੍ਰੌਕਸੀ ਵੱਲ ਮੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਭਾਵੇਂ ਉਹਨਾਂ ਨੂੰ ਇੰਟਰਫ਼ੇਸਾਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਪਤਾ। SSH ਕਲਾਇੰਟ ਸਰਵਰ ਵੱਲ ਕੋਈ ਬਦਲਾਅ ਕੀਤੇ ਬਿਨਾਂ ਇੱਕ ਦਿੰਦਾ ਹੈ:
ssh -N -D 127.0.0.1:9999 [email protected]ਉਸ ਪੋਰਟ ਨੂੰ ਵਰਤਣ ਲਈ ਸੈੱਟ ਹਰ ਚੀਜ਼ ਬਾਸਟੀਅਨ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਬਾਕੀ ਡੈਸਕਟਾਪ ਆਪਣਾ ਆਮ ਕਨੈਕਸ਼ਨ ਰੱਖਦਾ ਹੈ। ਟਨਲ ਪਤੇ ਨਾਲ ਬਾਈਂਡ ਸਥਾਨਕ 3proxy ਇੰਸਟੈਂਸ SSH ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਪੋਰਟ ਲਈ ਇਹੀ ਕਰਦਾ ਹੈ, ਅਤੇ stunnel TLS ਵਿੱਚ ਲਿੱਪਿਆ ਇੱਕੋ ਪੋਰਟ ਢਕਦਾ ਹੈ। ਹੱਦਾਂ ਵਿਹਾਰਕ ਹਨ: ਪ੍ਰੌਕਸੀ ਸਿਰਫ਼ ਉਹ ਪ੍ਰੋਟੋਕੋਲ ਢੋਂਦਾ ਹੈ ਜੋ ਇਸਨੂੰ ਵਰਤਣਾ ਜਾਣਦੇ ਹਨ, UDP ਲਈ SOCKS5 UDP ਐਸੋਸੀਏਸ਼ਨ ਚਾਹੀਦੀ ਹੈ ਜੋ ਬਹੁਤੇ ਕਲਾਇੰਟਾਂ ਦੀ “SOCKS5” ਸੈਟਿੰਗ ਚਾਲੂ ਨਹੀਂ ਕਰਦੀ, ਅਤੇ DNS ਪ੍ਰੌਕਸੀ ਨੇ ਹੀ ਹੱਲ ਕਰਨਾ ਹੈ (curl ਵਿੱਚ socks5h) ਨਹੀਂ ਤਾਂ ਨਾਂ ਸਥਾਨਕ ਰਿਜ਼ੌਲਵਰ ਤੱਕ ਲੀਕ ਹੁੰਦਾ ਹੈ।
ਸਰੋਤੇ ਨੂੰ ਲੂਪਬੈਕ ਉੱਤੇ ਹੀ ਰੱਖੋ ਜਦੋਂ ਤੱਕ ਹੋਰ ਮਸ਼ੀਨ ਨੂੰ ਇਸਦੀ ਲੋੜ ਨਹੀਂ।
ਸਥਿਤੀ ਸੁਨੇਹੇ ਨਾਲ ਨਹੀਂ, ਕੈਪਚਰ ਨਾਲ ਰਾਹ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ
ਐਪਲੀਕੇਸ਼ਨ ਸਥਿਤੀ ਵਿੰਡੋਆਂ ਸੈਟਿੰਗ ਦਾ ਵਰਣਨ ਕਰਦੀਆਂ ਹਨ, ਪੈਕੇਟ ਦਾ ਨਹੀਂ। ਦੋਵੇਂ ਇੰਟਰਫ਼ੇਸਾਂ ਉੱਤੇ ਕੈਪਚਰ ਕਰੋ ਅਤੇ ਤੁਲਨਾ ਕਰੋ:
tcpdump -i any -n port 443
ss -tnp | grep 443ਜੇ ਕਨੈਕਸ਼ਨ ਭੌਤਿਕ ਇੰਟਰਫ਼ੇਸ ਉੱਤੇ ਟਨਲ ਵਾਲੀ ਮੇਲ ਖਾਂਦੀ ਐਂਟਰੀ ਤੋਂ ਬਿਨਾਂ ਦਿਖਦਾ ਹੈ, ਤਾਂ ਕਲਾਇੰਟ ਕੁਝ ਵੀ ਰਿਪੋਰਟ ਕਰੇ, ਚੋਣਕਾਰ ਲਾਗੂ ਨਹੀਂ। IPv6 ਅਤੇ ਰਿਜ਼ੌਲਵਰ ਨੂੰ ਵੱਖਰੇ ਜਾਂਚੋ, ਅਤੇ ਸਹਾਇਕ ਪ੍ਰਕਿਰਿਆ ਜਾਂ ਵਿਰਾਸਤੀ ਸਿਸਟਮ ਪ੍ਰੌਕਸੀ ਵਰਗਾ ਦੂਜਾ ਰਾਹ ਵੀ ਜਾਂਚੋ।
ਫਿਰ ਲੋੜ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੱਦ ਚੁਣੋ: ਇੱਕ ਸਾਈਟ ਲਈ ਪ੍ਰੌਕਸੀ ਕਾਫ਼ੀ ਹੈ, ਇੱਕ ਖਾਤੇ ਲਈ UID ਨਿਯਮ ਕਾਫ਼ੀ ਹੈ, ਕਨੈਕਸ਼ਨ ਬੰਦ ਹੋ ਕੇ ਫੇਲ੍ਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੋਵੇ ਤਾਂ ਫਾਇਰਵਾਲ ਪ੍ਰੋਫਾਈਲ ਕਾਫ਼ੀ ਹੈ, ਅਤੇ ਬਾਹਰਲੇ ਸਭ ਤੋਂ ਟਨਲ ਲੁਕਾਉਣ ਦਾ ਇਕੋ ਬਦਲ ਨੇਮਸਪੇਸ ਹੈ।