tcpdump IPsec ਦਾ ਸਾਦਾ ਪਾਠ ਸਿਰਫ਼ ਇੱਕ ਦਿਸ਼ਾ ਵਿੱਚ ਕਿਉਂ ਦਿਖਾਉਂਦਾ ਹੈ

ਤੁਸੀਂ Linux IPsec ਗੇਟਵੇ ਦੇ ਬਾਹਰਲੇ ਇੰਟਰਫੇਸ 'ਤੇ tcpdump ਚਲਾਉਂਦੇ ਹੋ ਅਤੇ ਇੱਕੋ ਸਮੇਂ ਦੋ ਚੀਜ਼ਾਂ ਦੇਖਦੇ ਹੋ: ਆ ਰਹੇ ESP ਫ੍ਰੇਮ ਅਤੇ ਉਨ੍ਹਾਂ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਡੀਕ੍ਰਿਪਟ ਕੀਤੇ ਅੰਦਰਲੇ ਪੈਕੇਟ। ਬਾਹਰ ਜਾਂਦਿਆਂ ਸਿਰਫ਼ ESP ਦਿਖਦਾ ਹੈ। ਸੁਭਾਵਿਕ ਸਿੱਟਾ ਇਹ ਹੈ ਕਿ ਜਵਾਬ ਨਹੀਂ ਭੇਜੇ ਜਾ ਰਹੇ ਜਾਂ IPsec ਇੱਕ ਦਿਸ਼ਾ ਇਨਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ ਅਤੇ ਦੂਜੀ ਭੁੱਲ ਜਾਂਦਾ ਹੈ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਸੱਚ ਨਹੀਂ।

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

ਕੈਪਚਰ ਬਿੰਦੂ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ ਦੇਖਦੇ ਹੋ

ਆਮ ਇੰਟਰਫੇਸ 'ਤੇ AF_PACKET ਸਾਕਟ ਡਿਵਾਈਸ ਪਰਤ ਦੇ ਨੇੜੇ ਬੈਠਦਾ ਹੈ। ਹੋਸਟ ਛੱਡਣ ਵਾਲੇ ਪੈਕੇਟ ਪਹਿਲਾਂ IPsec ਆਉਟਪੁੱਟ ਪ੍ਰੋਸੈਸਿੰਗ ਵਿੱਚੋਂ ਲੰਘਦੇ ਹਨ, ਜੋ ਅੰਦਰਲੇ TCP ਹਿੱਸੇ ਨੂੰ ESP ਜਾਂ UDP-4500 ਡੇਟਾਗ੍ਰਾਮ ਵਿੱਚ ਬਦਲਦੀ ਹੈ, ਅਤੇ ਫਿਰ ਹੀ ਉਸ ਪਰਤ 'ਤੇ ਪਹੁੰਚਦੇ ਹਨ। ਆਉਣ ਵਾਲੇ ਪੈਕੇਟ ਤਾਰ ਵਿੱਚੋਂ ਆਉਂਦਿਆਂ ਹੀ, ਅਜੇ ਵੀ ਇਨਕ੍ਰਿਪਟਿਡ ਹਾਲਤ ਵਿੱਚ, ਸਾਕਟ ਵਿੱਚ ਕਾਪੀ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਡੀਕ੍ਰਿਪਟ ਕੀਤਾ ਨਤੀਜਾ ਬਾਅਦ ਵਿੱਚ ਦਿਖਦਾ ਹੈ ਜਦੋਂ ਸਟੈਕ ਉਸਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਪਹੁੰਚਾਉਂਦਾ ਹੈ ਜਾਂ ਅੱਗੇ ਭੇਜਦਾ ਹੈ।

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

ਫਿਲਟਰ ਨੂੰ ਉਸ ਪਰਤ ਨਾਲ ਮਿਲਾਓ ਜਿਸਦਾ ਤੁਹਾਡਾ ਮਤਲਬ ਹੈ

tcp port 443 ਵਰਗੀ ਸਮੀਕਰਨ ਅੰਦਰਲਾ TCP ਕਨੈਕਸ਼ਨ ਚੁਣਦੀ ਹੈ। ਬਾਹਰ ਜਾਂਦਿਆਂ ਸਾਕਟ ਨੂੰ ਪੁੱਛੇ ਜਾਣ ਤੱਕ ਉਹ ਕਨੈਕਸ਼ਨ ਪਹਿਲਾਂ ਹੀ ESP ਬਣ ਚੁੱਕਾ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਫਿਲਟਰ ਕਿਸੇ ਚੀਜ਼ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ। ਜੇ ਤੁਸੀਂ ਸੁਰੱਖਿਅਤ ਟ੍ਰੈਫਿਕ ਗਿਣਨਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਇਸ ਦੀ ਬਜਾਏ ਬਾਹਰਲੇ ਰੂਪ 'ਤੇ ਫਿਲਟਰ ਕਰੋ: ਕੱਚੇ ESP ਲਈ ਪ੍ਰੋਟੋਕਾਲ 50, ਜਾਂ NAT ਟ੍ਰਾਵਰਸਲ ਹੋਣ 'ਤੇ UDP ਪੋਰਟ 4500। ਦੋਵੇਂ ਫਿਲਟਰ ਦੋ ਧਿਰਾਂ ਵਿਚਕਾਰ ਤੁਲਨਾ ਯੋਗ ਪੈਕੇਟ ਗਿਣਤੀ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਗਿਣਨ ਦਾ ਕਾਰਨ ਵੀ ਇਹੀ ਹੁੰਦਾ ਹੈ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਅੰਦਰਲੀ ਬੇਨਤੀ ਦਾ ਜਵਾਬ ਮਿਲਿਆ ਜਾਂ ਨਹੀਂ।

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

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

ਰੂਪਾਂਤਰਣ ਤੋਂ ਪਹਿਲਾਂ ਦੇਖੋ, ਬਾਅਦ ਵਿੱਚ ਨਹੀਂ

ਜੇ ਤੁਹਾਨੂੰ ਬਾਹਰ ਜਾਂਦਾ ਸਾਦਾ ਪਾਠ ਦੇਖਣਾ ਹੈ ਤਾਂ ਨਿਰੀਖਣ ਬਿੰਦੂ ਨੂੰ ਪਹਿਲਾਂ, IPsec ਆਉਟਪੁੱਟ ਪ੍ਰੋਸੈਸਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਹਿਲਾਓ। NFLOG ਤੁਹਾਨੂੰ Netfilter ਹੁੱਕ ਦਿੰਦਾ ਹੈ ਜਿੱਥੇ ਇੱਕ ਨਿਯਮ ਚੁਣੇ ਹੋਏ ਪੈਕੇਟ ਨੂੰ ਵਰਤੋਂਕਾਰ-ਥਾਂ ਸਾਕਟ ਵਿੱਚ ਕਾਪੀ ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸਨੂੰ tcpdump ਪੜ੍ਹ ਸਕਦਾ ਹੈ। strongSwan ਦੀ ਟ੍ਰੈਫਿਕ-ਡੰਪ ਗਾਈਡ ਇਸ ਪਹੁੰਚ ਨੂੰ ਇਸੇ ਕਾਰਨ ਦਸਤਾਵੇਜ਼ੀ ਕਰਦੀ ਹੈ।

ਨੀਤੀ ਮੇਲ ਨਿਯਮ ਨੂੰ ਸਿਰਫ਼ ਉਸ ਟ੍ਰੈਫਿਕ ਤੱਕ ਸੀਮਿਤ ਕਰਦਾ ਹੈ ਜੋ ਸੁਰੰਗ ਵਿੱਚ ਦਾਖਲ ਹੋਣ ਵਾਲਾ ਹੈ। -m policy --pol ipsec --dir out ਹੀ ਨਿਯਮ ਨੂੰ ਖਾਸ ਬਣਾਉਂਦਾ ਹੈ, ਡੱਬੇ ਦੇ ਭੇਜੇ ਹਰ ਪੈਕੇਟ ਨੂੰ ਲੌਗ ਕਰਨ ਦੀ ਬਜਾਏ। ਫਿਰ ਲੌਗ ਸਮੂਹ ਨੂੰ ਸੀਮਿਤ ਕੈਪਚਰ ਨਾਲ ਪੜ੍ਹੋ: ਥੋੜ੍ਹੀ ਸਨੈਪਸ਼ਾਟ ਗਿਣਤੀ ਅਤੇ ਆਕਾਰ ਸੀਮਾ ਨਿਦਾਨ ਨੂੰ ਟ੍ਰੈਫਿਕ ਆਰਕਾਈਵ ਬਣਨ ਤੋਂ ਰੋਕਦੀਆਂ ਹਨ। ਸੀਮਿਤ ਕੈਪਚਰ ਸਮੀਖਿਅਕ ਨੂੰ ਸੌਂਪਣਾ ਵੀ ਸੌਖਾ ਹੈ, ਅਸੰਬੰਧਿਤ ਪੇਲੋਡ ਖਿੱਚਣ ਦੀ ਲੋੜ ਨਹੀਂ। ਕਿੰਨਾ ਆਇਆ ਦੇਖਣ ਤੋਂ ਬਾਅਦ ਨਹੀਂ, ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਗਿਣਤੀ ਤੈਅ ਕਰੋ।

iptables -I OUTPUT 1 -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
tcpdump -ni nflog:5 -s 128 -c 20 'host 10.83.0.44 and tcp port 8443'

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

ਨਿਰੀਖਣ ਕੀ ਸਾਬਤ ਕਰਦਾ ਹੈ

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

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

ਇੱਕ ਹੋਰ ਜਾਲ: ਇਸ ਸੰਦਰਭ ਵਿੱਚ «ਸਾਦਾ ਪਾਠ» ਦਾ ਮਤਲਬ IPsec ਇਨਕ੍ਰਿਪਸ਼ਨ ਪਰਤ ਤੋਂ ਬਾਹਰ। ਅੰਦਰਲੇ HTTPS ਸੈਸ਼ਨ ਦਾ ਅਜੇ ਵੀ ਆਪਣਾ TLS ਹੁੰਦਾ ਹੈ। ਡੀਕੈਪਸੁਲੇਟ ਕੀਤੇ ਪੈਕੇਟ ਨੂੰ ਫੜਨ ਨਾਲ ਐਪਲੀਕੇਸ਼ਨ ਦਾ TLS ਡੀਕ੍ਰਿਪਟ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਉੱਥੇ ਪੜ੍ਹਨ ਯੋਗ HTTP ਦਿਖਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਸ਼ੁਰੂ ਤੋਂ ਹੀ HTTPS ਨਹੀਂ ਵਰਤ ਰਹੀ ਸੀ।

ਸਾਫ਼ ਕਰੋ ਅਤੇ ਦੋਵੇਂ ਸਿਰੇ ਤੁਲਨਾ ਕਰੋ

ਨਿਰੀਖਣ ਮੁੱਕਣ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਤੁਸੀਂ ਪਾਇਆ ਠੀਕ ਉਹੀ ਨਿਯਮ, ਉਸਦੇ ਮਾਲਕ ਅਨੁਸਾਰ, ਹਟਾ ਦਿਓ। ਲੌਗਿੰਗ ਨਿਯਮ ਛੱਡਣ ਨਾਲ ਹਰ ਮੇਲ ਖਾਂਦੇ ਪੈਕੇਟ 'ਤੇ CPU ਖਰਚ ਹੁੰਦਾ ਹੈ ਅਤੇ ਚੁੱਪਚਾਪ ਡੇਟਾ ਰੱਖਣ ਦੀ ਸਮੱਸਿਆ ਪੈਦਾ ਹੁੰਦੀ ਹੈ। ਆਪਣੀ ਨਾ ਹੋਣ ਵਾਲੀ ਲੜੀ ਫਲਸ਼ ਕਰਨ ਦੀ ਬਜਾਏ -D ਨਾਲ ਨਿਯਮ ਦੁਹਰਾ ਕੇ ਮਿਟਾਓ।

iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5

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