ਕੀ ਟ੍ਰੈਫਿਕ ਸੱਚਮੁੱਚ VPN ਰਾਹੀਂ ਜਾ ਰਿਹਾ ਹੈ? ਇਸਨੂੰ ਕਿਵੇਂ ਤਸਦੀਕ ਕਰੀਏ
ਰੂਟ ਖੋਜ, ਪਹਿਲੀ ਛਾਲ, ਭੌਤਿਕ ਅਡੈਪਟਰ 'ਤੇ ਕੈਪਚਰ ਅਤੇ ਬਾਹਰੋਂ ਪਤਾ ਜਾਂਚ — ਹਰ ਇੱਕ ਸਵਾਲ ਦੇ ਵੱਖਰੇ ਹਿੱਸੇ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।
ਸਿਸਟਮ ਟ੍ਰੇ ਦੇ ਆਈਕਨ ਤੋਂ ਦੋ ਖਰਾਬੀਆਂ ਇੱਕੋ ਜਿਹੀਆਂ ਦਿਸਦੀਆਂ ਹਨ: ਸੁਰੰਗ ਵਿੱਚ ਵੜਨ ਵਾਲਾ ਟ੍ਰੈਫਿਕ ਅਤੇ ਉਸਨੂੰ ਚੁੱਪਚਾਪ ਟਾਲ ਕੇ ਜਾਣ ਵਾਲਾ ਟ੍ਰੈਫਿਕ। ਕਲਾਇੰਟ ਦੋਵਾਂ ਹਾਲਾਤਾਂ ਵਿੱਚ Connected ਦਿਖਾਉਂਦਾ ਹੈ, ਕਿਉਂਕਿ Connected ਦਾ ਮਤਲਬ ਸਿਰਫ਼ ਇਹ ਹੈ ਕਿ ਸੁਰੰਗ ਦਾ ਇੰਟਰਫ਼ੇਸ ਮੌਜੂਦ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਨੇ ਆਪਣੇ ਚਾਹੇ ਰੂਟ ਇੰਸਟਾਲ ਕੀਤੇ ਹਨ। ਕੀ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਇੱਕ ਪੈਕਟ ਨੇ ਉਹ ਰੂਟ ਵਰਤੇ, ਇਹ ਵੱਖਰਾ ਸਵਾਲ ਹੈ, ਜਿਸਦਾ ਜਵਾਬ ਸਟੈਕ ਵਿੱਚ ਕਿਤੇ ਹੋਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਚਾਰ ਮਾਪ ਇਸਦਾ ਵੱਡਾ ਹਿੱਸਾ ਹੱਲ ਕਰਦੇ ਹਨ — ਰੂਟ ਖੋਜ, ਪਹਿਲੀ ਛਾਲ, ਭੌਤਿਕ ਅਡੈਪਟਰ 'ਤੇ ਕੈਪਚਰ ਅਤੇ ਬਾਹਰੋਂ ਨਿਰੀਖਣ — ਅਤੇ ਸਰਵਰ ਦਾ ਆਪਣਾ ਸੈਸ਼ਨ ਦ੍ਰਿਸ਼ ਬਾਕੀ ਢੱਕਦਾ ਹੈ।
ਉਸ ਰੂਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜਿਸ ਰਾਹੀਂ ਪੈਕਟ ਜਾਵੇਗਾ
ਰੂਟਿੰਗ ਟੇਬਲ ਹੀ ਫੈਸਲਾ ਹੈ, ਇਸ ਲਈ ਪੂਰੀ ਪੜ੍ਹ ਕੇ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਇੱਕ ਮੰਜ਼ਿਲ ਬਾਰੇ ਪੁੱਛੋ। Linux 'ਤੇ, ip route get ਕਰਨਲ ਵੱਲੋਂ ਚੁਣਿਆ ਇੰਟਰਫ਼ੇਸ ਅਤੇ ਸਰੋਤ ਪਤਾ ਦੱਸਦਾ ਹੈ:
ip route get 203.0.113.10
ip route get 10.20.5.7Windows 'ਤੇ, Find-NetRoute -RemoteIPAddress 203.0.113.10 route print -4 ਨਾਲੋਂ ਵਧੇਰੇ ਲਾਹੇਵੰਦ ਹੈ, ਉਸੇ ਕਾਰਨ: ਇਹ ਜਿੱਤਣ ਵਾਲਾ ਰੂਟ ਦੱਸਦਾ ਹੈ, ਮੌਜੂਦ ਸਾਰੇ ਰੂਟ ਨਹੀਂ। ਫਿਰ ਵੀ ਇਸਦੀ 0.0.0.0 ਕਤਾਰ ਲਈ ਟੇਬਲ ਇੱਕ ਵਾਰ ਪੜ੍ਹੋ। ਉੱਥੇ /1 ਜੋੜੀ ਹੋਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਪੂਰੀ ਸੁਰੰਗ ਵਾਲੇ ਕਲਾਇੰਟ ਨੇ ਡਿਫ਼ਾਲਟ ਰੂਟ ਮੁੜ ਲਿਖਿਆ ਹੈ: OpenVPN ਦਾ redirect-gateway def1 ਵਿਕਲਪ ਸੁਰੰਗ ਰਾਹੀਂ 0.0.0.0/1 ਅਤੇ 128.0.0.0/1 ਇੰਸਟਾਲ ਕਰਦਾ ਹੈ, ਜੋ ਭੌਤਿਕ ਡਿਫ਼ਾਲਟ ਨੂੰ ਮਿਟਾਏ ਬਿਨਾਂ ਸਭ ਤੋਂ ਲੰਬੀ ਪ੍ਰੀਫ਼ਿਕਸ ਮੇਲ 'ਚ ਮੌਜੂਦ 0.0.0.0/0 ਨੂੰ ਹਰਾਉਂਦਾ ਹੈ। ਇਸੇ ਲਈ ਦੋ ਡਿਫ਼ਾਲਟ ਰੂਟ ਇਕੱਠੇ ਰਹਿ ਸਕਦੇ ਹਨ, ਜਦਕਿ ਸਭ ਕੁਝ ਹਾਲੇ ਵੀ ਸੁਰੰਗ ਵਿੱਚ ਜਾਂਦਾ ਹੈ।
ਦੋ ਵੇਰਵੇ ਟੇਬਲ ਨੂੰ ਝੂਠਾ ਬਣਾਉਂਦੇ ਹਨ। ਪਹਿਲਾ, ਡਿਫ਼ਾਲਟ ਰੂਟਾਂ ਦੀ ਗਿਣਤੀ ਨਹੀਂ, ਮੇਲ ਖਾਣ ਵਾਲਾ ਪ੍ਰੀਫ਼ਿਕਸ ਵੇਖੋ, ਕਿਉਂਕਿ ਇੰਟਰਫ਼ੇਸ ਮੈਟ੍ਰਿਕ ਜਾਂ /1 ਜੋੜੀ ਜੇਤੂ ਤੈਅ ਕਰਦੀ ਹੈ। ਦੂਜਾ, ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਕਨੈਕਸ਼ਨ ਉਹੀ ਰਾਹ ਰੱਖਦਾ ਹੈ ਜਿਸ ਨਾਲ ਸਥਾਪਿਤ ਹੋਇਆ ਸੀ; ਸੁਰੰਗ ਉੱਠਣ ਮਗਰੋਂ ਖੁੱਲ੍ਹਾ ਸੈਸ਼ਨ ਰੀਸੈਟ ਹੋਣ ਤੱਕ ਪੁਰਾਣਾ ਰੂਟ ਵਰਤ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਦੁਬਾਰਾ ਜੁੜਨਾ ਰੂਟਿੰਗ ਸਮੱਸਿਆ ਠੀਕ ਕਰਦਾ ਜਾਪਦਾ ਹੈ। ਚੱਲ ਰਿਹਾ ਕਲਾਇੰਟ — ps ax | grep openvpn — ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਹੋਈ।
ਇੱਕ ਅੰਦਰੂਨੀ ਅਤੇ ਇੱਕ ਜਨਤਕ ਨਾਮ ਟ੍ਰੈਕ ਕਰੋ
ਰੂਟ ਖੋਜ ਇਰਾਦਾ ਦਿਖਾਉਂਦੀ ਹੈ; ਰਾਹ ਡਿਲੀਵਰੀ ਦਿਖਾਉਂਦਾ ਹੈ। ਜੁੜੇ ਹੋਣ ਵੇਲੇ ਅੰਦਰੂਨੀ ਹੋਣਾ ਲਾਜ਼ਮੀ ਨਾਮ ਅਤੇ ਨਾ ਹੋਣਾ ਚਾਹੀਦਾ ਨਾਮ ਟ੍ਰੈਕ ਕਰੋ ਅਤੇ ਪਹਿਲੀ ਛਾਲ ਦੀ ਤੁਲਨਾ ਕਰੋ:
traceroute intranet.corp.example
traceroute 1.1.1.1ਦੋਵਾਂ ਲਈ ਇੱਕੋ ਪਹਿਲੀ ਛਾਲ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅੰਦਰੂਨੀ ਨਾਮ ਕਦੇ ਸੁਰੰਗ ਵਿੱਚ ਨਹੀਂ ਵੜਿਆ ਅਤੇ ਖਰਾਬੀ ਉਸ ਤੋਂ ਉੱਪਰ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਜਨਤਕ ਪਤੇ ਵਿੱਚ ਹੱਲ ਹੁੰਦਾ ਨਾਮ ਜਾਂ ਕਦੇ ਨਾ ਲੱਗਿਆ ਰੂਟ। ਅੰਦਰੂਨੀ ਟ੍ਰੈਫਿਕ 10.8.0.1 ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ ਅਤੇ ਜਨਤਕ 192.168.1.1 ਰਾਹੀਂ, ਤਾਂ ਵੱਖਰੀ ਸੁਰੰਗ ਉਹੀ ਕਰ ਰਹੀ ਹੈ ਜਿਸ ਲਈ ਉਹ ਸੈੱਟ ਕੀਤੀ ਗਈ ਸੀ। VPN ਗੇਟਵੇ ਤੱਕ ਪਹੁੰਚ ਕੇ ਸਿਰਫ਼ ਟਾਈਮਆਊਟ ਵਾਪਸ ਕਰਨ ਵਾਲਾ ਟ੍ਰੇਸ ਆਮ ਤੌਰ 'ਤੇ ਵਾਪਸੀ ਰਾਹ ਜਾਂ ਸਰਵਰ ਫਾਇਰਵਾਲ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਗੁੰਮ ਫਾਰਵਰਡ ਰੂਟ ਨਹੀਂ।
ਫਿਲਟਰ ਕੀਤਾ ICMP ਇਸ ਜਾਂਚ ਨੂੰ ਝੂਠਾ ਬਣਾਉਂਦਾ ਹੈ: ਦੋਵਾਂ ਟ੍ਰੇਸਾਂ 'ਤੇ ਤਾਰੇ ਮਰੀ ਸੁਰੰਗ ਵਰਗੇ ਦਿਸਦੇ ਹਨ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਫਾਇਰਵਾਲ ਹੁੰਦਾ ਹੈ। ਜਿੱਥੇ ਹੋ ਸਕੇ TCP ਪੋਰਟ ਜਾਂਚੋ — Linux 'ਤੇ traceroute -T -p 443 — ਅਤੇ ਯਾਦ ਰੱਖੋ ਟ੍ਰੇਸ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਕਿਹੜੇ ਰਿਜ਼ੌਲਵਰ ਨੇ ਜਵਾਬ ਦਿੱਤਾ: ਨਾਮ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਹੱਲ ਹੋ ਕੇ ਵੀ ਸੁਰੰਗ ਰਾਹੀਂ ਪਹੁੰਚਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਸੁਰੰਗ 'ਤੇ ਨਹੀਂ, ਭੌਤਿਕ ਅਡੈਪਟਰ 'ਤੇ ਕੈਪਚਰ ਕਰੋ
ਭੌਤਿਕ ਲਿੰਕ ਹੀ ਇੱਕੋ-ਇੱਕ ਥਾਂ ਹੈ ਜੋ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਨੈੱਟਵਰਕ ਅਸਲ ਵਿੱਚ ਕੀ ਵੇਖਦਾ ਹੈ। ਸੁਰੰਗ ਉੱਪਰ ਹੋਣ 'ਤੇ ਦਫ਼ਤਰ ਜਾਣ ਵਾਲਾ ਸੈਸ਼ਨ VPN ਸਰਵਰ ਨੂੰ ਸੰਬੋਧਿਤ ਇਨਕ੍ਰਿਪਟਿਡ ਪੇਲੋਡ ਵਜੋਂ ਦਿਸਣਾ ਚਾਹੀਦਾ ਹੈ, 10.20.5.7 ਨਾਲ ਕਨੈਕਸ਼ਨ ਵਜੋਂ ਨਹੀਂ:
sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5ਪਹਿਲਾ ਫਿਲਟਰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਬਾਹਰ ਜਾਂਦੀ ਨਾਮ ਹੱਲ ਨੂੰ ਫੜਦਾ ਹੈ, ਜੋ ਸਭ ਤੋਂ ਆਮ ਅਤੇ ਸਭ ਤੋਂ ਖ਼ਾਮੋਸ਼ ਲੀਕ ਹੈ — ਪੰਨਾ ਫਿਰ ਵੀ ਲੋਡ ਹੁੰਦਾ ਹੈ, ਰਿਜ਼ੌਲਵਰ ਨੇ ਸਿਰਫ਼ ਕੁਐਰੀ ਵੇਖੀ। ਦੂਜਾ ਸੁਰੰਗ ਦੇ ਅੰਦਰ ਹੀ ਹੋਣਾ ਚਾਹੀਦਾ ਅੰਦਰੂਨੀ ਪਤੇ ਵੱਲ ਸਾਧਾਰਨ ਟ੍ਰੈਫਿਕ ਫੜਦਾ ਹੈ। Windows 'ਤੇ, pktmon ਬਿਨਾਂ ਡਰਾਈਵਰ ਉਹੀ ਕੰਮ ਕਰਦਾ ਹੈ: pktmon filter add -p 53, ਫਿਰ pktmon start --capture --pkt-size 128, ਫਿਰ pktmon stop ਅਤੇ pktmon format pktmon.etl -o capture.txt। ਇਹ ਫਲੈਗ Windows ਬਿਲਡਾਂ ਵਿੱਚ ਥੋੜ੍ਹਾ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਸਿੰਟੈਕਸ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ pktmon filter add /? ਵੇਖੋ।
ਲੀਕ ਲੱਭਣ ਲਈ ਭੌਤਿਕ ਇੰਟਰਫ਼ੇਸ 'ਤੇ ਕੈਪਚਰ ਕਰੋ; ਸੁਰੰਗ 'ਤੇ ਕੈਪਚਰ ਉਹ ਪੈਕਟ ਰੱਖਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਮੰਨਦੇ ਹੋ ਉੱਥੇ ਹਨ, ਅਤੇ ਸਰਵਰ 'ਤੇ ਇਹ ਅਣਪੜ੍ਹੇ ਬਾਹਰੀ ਪੈਕਟ ਰੱਖਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦਾ ਸਰੋਤ ਗੇਟਵੇ ਹੈ। ਕਿਸੇ ਵੀ ਇੰਟਰਫ਼ੇਸ ਦੇ ਬਾਈਟ ਕਾਊਂਟਰ ਪੈਕਟਾਂ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਨ, ਪ੍ਰੋਗਰਾਮਾਂ ਦਾ ਨਹੀਂ; ਟ੍ਰੈਫਿਕ ਨੂੰ ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਜੋੜਨ ਲਈ ਸਾਕਟਾਂ ਨੂੰ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨਾਲ ਮੈਪ ਕਰਨ ਵਾਲਾ ਮਾਨੀਟਰ ਚਾਹੀਦਾ ਹੈ।
ਬਾਹਰੀ ਸੇਵਾ ਨੂੰ ਪੁੱਛੋ, ਫਿਰ ਹਰ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਦੁਬਾਰਾ ਪੁੱਛੋ
ਬਾਹਰ ਨਿਕਲਣਾ ਸਾਬਤ ਕਰਨ ਵਾਲੀ ਇੱਕੋ-ਇੱਕ ਜਾਂਚ ਬਾਹਰੋਂ ਆਇਆ ਜਵਾਬ ਹੈ: ਆਪਣੇ ਵੇਖੇ ਸਰੋਤ ਪਤੇ ਨੂੰ ਵਾਪਸ ਦੇਣ ਵਾਲੀ ਸੇਵਾ। ਇਸਨੂੰ ਸ਼ੈੱਲ ਤੋਂ ਚਲਾਓ, ਜਿੱਥੇ ਇੰਟਰਫ਼ੇਸ ਚੁਣ ਸਕਦੇ ਹੋ, ਅਤੇ ਦੋ ਵਾਰ ਚਲਾਓ:
sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ipਵੱਖਰੇ ਜਵਾਬ ਦੋਵਾਂ ਰਾਹਾਂ ਦਾ ਸਬੂਤ ਅਤੇ ਖ਼ਾਸ ਐਪਲੀਕੇਸ਼ਨ ਜਾਂਚਣ ਦਾ ਤਰੀਕਾ ਦਿੰਦੇ ਹਨ: ਇਸਨੂੰ ਬਾਈਂਡ ਕਰੋ, ਜਾਂ ਇੱਕ ਰੂਟ ਵਾਲੇ ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ ਵਿੱਚ ਚਲਾਓ, ਅਤੇ ਵੇਖੋ ਦੂਰ ਵਾਲਾ ਸਿਰਾ ਕਿਹੜਾ ਪਤਾ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ। ਇੱਕੋ ਜਿਹੇ ਜਵਾਬ ਹੀ ਦਿਲਚਸਪ ਖਰਾਬੀ ਹਨ: ਜਾਂ ਬਾਈਂਡਿੰਗ ਨੇ ਅਸਰ ਨਹੀਂ ਕੀਤਾ, ਜਾਂ ਹੋਸਟ ਅਤੇ ਦੂਰ ਵਾਲੇ ਸਿਰੇ ਵਿਚਕਾਰ ਕੁਝ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਸਰੋਤ ਪਤਾ ਮੁੜ ਲਿਖਦਾ ਹੈ। Windows 'ਤੇ, curl --interface ਅਡੈਪਟਰ ਦਾ ਨਾਮ ਨਹੀਂ, ਪਤਾ ਮੰਗਦਾ ਹੈ।
VPN ਪਤਾ ਦੱਸਣ ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ ਉਸ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਸਾਬਤ ਕਰਦਾ ਹੈ। ਮੇਲ ਕਲਾਇੰਟ, ਪੈਕੇਜ ਮੈਨੇਜਰ, ਬੈਕਅੱਪ ਏਜੰਟ ਜਾਂ ਦੂਜੀ ਬ੍ਰਾਊਜ਼ਰ ਪ੍ਰੋਫ਼ਾਈਲ ਹਰ ਇੱਕ ਵੱਖਰਾ ਰਾਹ ਲੈ ਸਕਦੇ ਹਨ, ਖ਼ਾਸਕਰ ਜਦੋਂ ਪ੍ਰੌਕਸੀ ਸੈਟਿੰਗ ਜਾਂ ਵੱਖਰੀ ਸੁਰੰਗ ਦਾ ਰੂਟ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਢੱਕਦਾ ਹੈ। ਪਤਾ ਬਦਲਣਾ ਆਪਣੇ ਆਪ ਵਿੱਚ ਲੀਕ ਦਾ ਸਬੂਤ ਨਹੀਂ: ਲੋਡ ਬੈਲੰਸਰ ਵੇਖੇ ਏਗ੍ਰੈਸ ਅਨੁਸਾਰ ਵੱਖਰਾ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਪੰਨਾ ਨਹੀਂ, ਰਿਕਾਰਡ ਕੀਤਾ ਸਰੋਤ ਪਤਾ ਤੁਲਨਾ ਕਰੋ।
ਪੀਅਰ ਦੀ ਪੁਸ਼ਟੀ ਲਈ ਸਰਵਰ ਦ੍ਰਿਸ਼ ਵਰਤੋ
ਸਰਵਰ ਦੂਜੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਪੀਅਰ ਜੁੜਿਆ ਹੈ ਕਿ ਨਹੀਂ, ਕਿੰਨਾ ਢੋਇਆ ਅਤੇ ਸੈਸ਼ਨ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਹੋਇਆ ਕਿ ਨਹੀਂ। ਸਰਵਰ 'ਤੇ ਪੀਅਰ ਸਰਗਰਮ ਹੋਵੇ ਜਦਕਿ ਕਲਾਇੰਟ ਦੇ ਕਾਊਂਟਰ ਮੁਸ਼ਕਿਲ ਨਾਲ ਹਿੱਲਣ, ਤਾਂ ਕਲਾਇੰਟ ਟੇਬਲ ਕੁਝ ਵੀ ਕਹੇ, ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਟ੍ਰੈਫਿਕ ਸੁਰੰਗ ਵਿੱਚ ਨਹੀਂ ਜਾ ਰਿਹਾ। ਅਤੇ ਜੋ ਪੀਅਰ ਕੁਝ ਵੀ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਦੱਸਣ ਵਾਲੇ ਉਪਭੋਗਤਾ ਲਈ ਬਹੁਤ ਡੇਟਾ ਭੇਜ ਰਿਹਾ ਹੈ, ਉਹ ਵੱਖਰੀ ਜਾਂਚ ਹੈ।
ਇੱਥੇ ਦੋ ਜਾਲ ਹਨ। ਮਾਸਕਰੇਡ ਸੁਰੰਗ ਹਰ ਪ੍ਰਵਾਹ ਨੂੰ ਗੇਟਵੇ ਤੋਂ ਆਇਆ ਜਿਹਾ ਦਿਖਾਉਂਦੀ ਹੈ, ਇਸ ਲਈ ਲਾਗ ਅਤੇ ਪ੍ਰਤੀ-ਕਲਾਇੰਟ ਹਿਸਾਬ ਇੱਕੋ ਪਤੇ 'ਤੇ ਸਿਮਟ ਜਾਂਦੇ ਹਨ। ਅਤੇ ਕਲਾਇੰਟ ਨੂੰ ਸਥਾਨਕ ਹੋਸਟ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਕੋਈ VPN ਰਾਹੀਂ ਫ਼ਾਈਲਾਂ ਕਾਪੀ ਕਰ ਰਿਹਾ ਹੈ ਕਿ ਨਹੀਂ ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਸਰਵਰ 'ਤੇ ਫ਼ਾਈਲ-ਸ਼ੇਅਰਿੰਗ ਟ੍ਰੈਫਿਕ ਜਾਂ ਸਰਵਰ 'ਤੇ ਹੋਸਟ ਆਡਿਟ ਦਿੰਦਾ ਹੈ — ਸੁਰੰਗ ਵੇਖਣ ਨਾਲ ਸਿਰੇ ਅਤੇ ਮਾਤਰਾ ਮਿਲਦੀ ਹੈ, ਫ਼ਾਈਲ ਨਾਮ ਨਹੀਂ।
ਡਿਜ਼ਾਈਨ ਫੈਸਲੇ ਨੂੰ ਲੀਕ ਤੋਂ ਵੱਖਰਾ ਕਰੋ
ਸੁਰੰਗ ਤੋਂ ਬਾਹਰ ਸਭ ਕੁਝ ਲੀਕ ਨਹੀਂ। ਲਿੰਕ-ਸਥਾਨਕ ਅਤੇ ਪ੍ਰਸਾਰਣ ਟ੍ਰੈਫਿਕ ਡਿਜ਼ਾਈਨ ਅਨੁਸਾਰ ਸਥਾਨਕ ਰਹਿੰਦਾ ਹੈ, ਮਲਟੀਕਾਸਟ ਨਾਲ ਲੱਭਿਆ ਪ੍ਰਿੰਟਰ LAN 'ਤੇ ਐਲਾਨ ਜਾਰੀ ਰੱਖਦਾ ਹੈ, ਅਤੇ DHCP ਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਬਾਹਰ ਜਾਣਾ ਪੈਂਦਾ ਹੈ। ਖ਼ਾਸ ਇੰਟਰਫ਼ੇਸ ਨਾਲ ਬੱਝੀ ਐਪਲੀਕੇਸ਼ਨ ਜਾਣ-ਬੁੱਝ ਕੇ ਰੂਟਿੰਗ ਟੇਬਲ ਟਾਲਦੀ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਫਾਇਰਵਾਲ ਨਿਯਮ, ਨੇਮਸਪੇਸ ਜਾਂ ਨੀਤੀ ਰੂਟ ਹੀ ਬਦਲਦੇ ਹਨ।
IPv6 ਨੂੰ ਚੈੱਕਲਿਸਟ ਵਿੱਚ ਆਪਣੀ ਵੱਖਰੀ ਕਤਾਰ ਮਿਲਣੀ ਚਾਹੀਦੀ ਹੈ। ਸਿਰਫ਼ IPv4 ਢੋਣ ਵਾਲੀ ਸੁਰੰਗ ਦੋਹਰੇ-ਸਟੈਕ ਹੋਸਟ ਨੂੰ ਦੂਜਾ ਵਰਤੋਂਯੋਗ ਰਾਹ ਛੱਡਦੀ ਹੈ, ਅਤੇ ਦੋਹਰਾ-ਸਟੈਕ ਮੰਜ਼ਿਲ ਉਸਨੂੰ ਤਰਜੀਹ ਦੇਵੇਗੀ — DNS ਸਮੇਤ, ਜੇ ਰਿਜ਼ੌਲਵਰ IPv6 ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਹੋਵੇ। IPv4 ਨਤੀਜੇ ਨੂੰ ਪੂਰਾ ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ ਅਡੈਪਟਰ 'ਤੇ IPv6 ਬੰਦ ਕਰੋ ਜਾਂ ਸੁਰੰਗ ਇਸਨੂੰ ਢੋਂਦੀ ਹੈ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
ਜਦੋਂ ਜਾਂਚਾਂ ਨਹੀਂ ਮਿਲਦੀਆਂ, ਤਾਂ ਫ਼ਰਕ ਹੀ ਆਮ ਤੌਰ 'ਤੇ ਖਰਾਬੀ ਦਾ ਨਾਮ ਦੱਸਦਾ ਹੈ:
| What you see | What it means | Next step |
|---|---|---|
| The route picks tun0 but the capture shows cleartext to 10.20.5.7 | Something bypassed the table: a bound app, a policy route or a session older than the tunnel | Reset the flow, check the app bind, check the ip rule list |
| The route picks eth0 for an internal name | The name resolves to a public address, or the route was never installed | Compare the resolved address with the routes the server pushes |
| The capture shows DNS to the LAN resolver | Resolver leak: data is tunneled, lookups are not | Point the resolver inside, or push it from the server |
| All four checks agree and one app still fails | Path selection is fine; suspect MTU, a per-app proxy or the far end | Test the same destination from a known-good client |
ਕੰਮ ਕਰਨ ਵਾਲਾ ਕ੍ਰਮ: ਜੁੜਨ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਰੂਟਿੰਗ ਟੇਬਲ ਸੰਭਾਲੋ, ਇੱਕ ਅੰਦਰੂਨੀ ਅਤੇ ਇੱਕ ਜਨਤਕ ਨਾਮ ਟ੍ਰੈਕ ਕਰੋ, ਭੌਤਿਕ ਅਡੈਪਟਰ 'ਤੇ DNS ਕੈਪਚਰ ਕਰੋ, ਖ਼ਾਸ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਸ਼ੈੱਲ ਤੋਂ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਪਤਾ ਵਾਪਸ ਲਵੋ, ਫਿਰ ਮਾਤਰਾ ਲਈ ਸਰਵਰ ਪੜ੍ਹੋ। ਪਹਿਲੇ ਚਾਰ ਮਿਲ ਜਾਣ ਤਾਂ ਸੁਰੰਗ ਉਹੀ ਢੋ ਰਹੀ ਹੈ ਜੋ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਅਤੇ ਬਾਕੀ ਸਮੱਸਿਆ ਉਸ ਤੋਂ ਉੱਪਰ ਹੈ। ਦੋ ਨਾ ਮਿਲਣ ਤਾਂ ਨਾ ਮਿਲਣ ਵਾਲੀ ਜੋੜੀ ਹੀ ਖਰਾਬੀ ਹੈ, ਆਈਕਨ ਨਹੀਂ।