OpenVPN ਦਾ ਪੂਰਾ ਟਨਲ ਤੁਹਾਡਾ SSH ਸੈਸ਼ਨ ਕੱਟ ਦਿੰਦਾ ਹੈ: ਵਾਪਸੀ ਦਾ ਰਾਹ ਠੀਕ ਕਰੋ

ਜਿਸ ਮਸ਼ੀਨ ਤੱਕ ਤੁਸੀਂ SSH ਰਾਹੀਂ ਪਹੁੰਚਦੇ ਹੋ, ਉਸ ਉੱਤੇ ਪੂਰਾ-ਟਨਲ OpenVPN ਕਲਾਇੰਟ ਚਾਲੂ ਕਰਨ ਨਾਲ ਸੈਸ਼ਨ ਇੱਕ ਸਕਿੰਟ ਵਿੱਚ ਕੱਟ ਸਕਦਾ ਹੈ, ਅਤੇ ਮਸ਼ੀਨ ਕੁਝ ਵੀ ਗਲਤ ਨਹੀਂ ਕਰ ਰਹੀ। ਟਨਲ ਇਹ ਨਹੀਂ ਬਦਲਦਾ ਕਿ ਪੈਕਟ ਸਰਵਰ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚਦੇ ਹਨ; ਇਹ ਬਦਲਦਾ ਹੈ ਕਿ ਜਵਾਬ ਕਿਵੇਂ ਬਾਹਰ ਜਾਂਦੇ ਹਨ। ਜਿਵੇਂ ਹੀ ਡਿਫ਼ਾਲਟ ਰੂਟ tun0 ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਤੁਹਾਡੇ SSH ਕਲਾਇੰਟ ਨੂੰ ਜਵਾਬ ਪ੍ਰਦਾਤਾ ਦੇ ਨੈੱਟਵਰਕ ਵਿੱਚ ਚਲਾ ਜਾਂਦਾ ਹੈ, ਜਿਸਦੇ ਤੁਹਾਡੇ ਪਤੇ ਵੱਲ ਵਾਪਸ ਜਾਣ ਦਾ ਕੋਈ ਰੂਟ ਨਹੀਂ ਹੈ। ਕਨੈਕਸ਼ਨ ਲਟਕ ਜਾਂਦਾ ਹੈ, ਅਗਲੀ ਕੋਸ਼ਿਸ਼ ਸਮਾਂ ਸੀਮਾ ਪਾਰ ਕਰਦੀ ਹੈ, ਅਤੇ ਡੀਮਨ ਪੂਰਾ ਸਮਾਂ ਪੋਰਟ 22 ਉੱਤੇ ਸੁਣਦਾ ਰਹਿੰਦਾ ਹੈ।

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

ਜਵਾਬ ਗਲਤ ਦਰਵਾਜ਼ੇ ਰਾਹੀਂ ਕਿਉਂ ਨਿਕਲਦਾ ਹੈ

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

OpenVPN ਦੀ ਆਪਣੀ ਸੁਰੱਖਿਆ ਠੀਕ ਇੱਕ ਮੰਜ਼ਿਲ ਨੂੰ ਢਕਦੀ ਹੈ। 2.6 ਦੀ ਹਦਾਇਤ --redirect-gateway ਨੂੰ ਇੱਕ ਕ੍ਰਮ ਵਜੋਂ ਦੱਸਦੀ ਹੈ: ਇਹ ਟਨਲ ਤੋਂ ਪਹਿਲਾਂ ਵਰਤੇ ਗੇਟਵੇ ਰਾਹੀਂ VPN ਪੀਅਰ ਲਈ ਹੋਸਟ ਰੂਟ ਜੋੜਦੀ ਹੈ, ਤਾਂ ਜੋ ਇਨਕ੍ਰਿਪਟਿਡ ਟ੍ਰੈਫਿਕ ਆਪਣੇ ਆਪ ਵਿੱਚ ਵਾਪਸ ਨਾ ਮੁੜ ਸਕੇ, ਅਤੇ ਫਿਰ ਡਿਫ਼ਾਲਟ ਰੂਟ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਉਹ ਹੋਸਟ ਰੂਟ ਸਿਰਫ਼ ਪੀਅਰ ਲਈ ਹੈ। ਤੁਹਾਡਾ SSH ਕਲਾਇੰਟ ਬੱਸ ਇੱਕ ਹੋਰ ਇੰਟਰਨੈੱਟ ਪਤਾ ਹੈ ਅਤੇ ਕੋਈ ਛੋਟ ਨਹੀਂ ਮਿਲਦੀ।

ਇੱਕ ਪ੍ਰੀਫਿਕਸ ਗਲਤੀ ਨੂੰ ਛੇਤੀ ਬਾਹਰ ਕੱਢਣਾ ਚਾਹੀਦਾ ਹੈ। ਲੰਬਾਈ ਤੋਂ ਬਿਨਾਂ ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 ਸਿਰਫ਼ ਇੱਕ ਪਤੇ 0.0.0.0 ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਇੰਟਰਨੈੱਟ ਨਾਲ ਨਹੀਂ; ਇਹ 0.0.0.0/0 ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਅਤੇ ਜੇ ਡਿਫ਼ਾਲਟ ਲੈਣ ਨਾਲ ਟਨਲ ਦੀ ਆਪਣੀ ਆਵਾਜਾਈ ਟੁੱਟਦੀ ਹੈ, ਤਾਂ ਭੌਤਿਕ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਐਂਡਪੌਇੰਟ ਨੂੰ ਹੋਸਟ ਰੂਟ ਵਜੋਂ ਜੋੜੋ, ਪ੍ਰਦਾਤਾ ਦੇ ਅਸਲੀ ਪਤੇ ਨਾਲ।

ਤੁਰੰਤ ਹੱਲ ਲਈ ਆਪਣੇ SSH ਕਲਾਇੰਟ ਦਾ ਪਤਾ ਪਿੰਨ ਕਰੋ

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

curl -s https://ifconfig.co
ip route

ਸਰਵਰ ਉੱਤੇ, ਕਲਾਇੰਟ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਛੋਟ ਜੋੜੋ। ਇੱਥੋਂ ਦੇ ਪਤੇ ਪਲੇਸਹੋਲਡਰ ਹਨ; ਆਕਾਰ ਮਹੱਤਵਪੂਰਨ ਹੈ:

sudo ip route add 80.128.240.55 via 192.168.178.1

ਇਹ ਰਿਪੋਰਟ ਕੀਤੇ ਕੇਸ ਵਿੱਚ ਵਰਤੀ ਗਈ ਮੁਰੰਮਤ ਹੈ, ਅਤੇ ਇਹ ਤੁਰੰਤ ਕੰਮ ਕਰਦੀ ਹੈ। ਇਹ ਦੋ ਅੰਦਾਜ਼ਨ ਤਰੀਕਿਆਂ ਨਾਲ ਨਾਜ਼ੁਕ ਵੀ ਹੈ: ਰੀਬੂਟ ਉੱਤੇ ਰੂਟ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਜਿਸ ਪਲ ਤੁਹਾਡਾ ISP ਤੁਹਾਨੂੰ ਦੂਜਾ ਪਤਾ ਦਿੰਦਾ ਹੈ, ਇਹ ਗਲਤ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਸਨੂੰ ਐਮਰਜੈਂਸੀ ਉਪਾਅ ਮੰਨੋ ਅਤੇ ਜਾਣ-ਬੁੱਝ ਕੇ ਇਸਨੂੰ ਟਿਕਾਊ ਬਣਾਓ, ਨੈੱਟਵਰਕ ਯੂਨਿਟ ਜਾਂ ਡਿਸਪੈਚਰ ਹੁੱਕ ਰਾਹੀਂ, ਜਾਂ ਮੰਨ ਲਓ ਕਿ ਇਹ ਅਸਥਾਈ ਹੈ ਅਤੇ ਰਿਕਵਰੀ ਦਾ ਰਾਹ ਲਿਖ ਲਓ।

ਕਲਾਇਂਟ ਨੂਂ ਡਿਫ਼ਾਲਟ ਲੈਣ ਤੋਂ ਰੋਕੋ

ਵਧੇਰੇ ਸਾਫ਼ ਵਿਕਲਪ ਇਹ ਹੈ ਕਿ ਟਨਲ ਨੂੰ ਡਿਫ਼ਾਲਟ ਰੂਟ ਬਿਲਕੁਲ ਬਦਲਣ ਨਾ ਦਿੱਤਾ ਜਾਵੇ। route-nopull, --client ਜਾਂ --pull ਨਾਲ ਵਰਤਿਆ ਜਾਣ 'ਤੇ, ਰੂਟ, block-outside-dns ਅਤੇ DNS ਸਰਵਰ ਵਰਗੇ DHCP ਸ਼ੈਲੀ ਦੇ ਵਿਕਲਪਾਂ ਤੋਂ ਇਲਾਵਾ ਧੱਕੇ ਗਏ ਵਿਕਲਪ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ ਸਿਰਫ਼ ਲੋੜੀਂਦੇ ਪ੍ਰੀਫਿਕਸ ਜੋੜਦੇ ਹੋ। ਵਧੇਰੇ ਤੰਗ ਸਾਧਨ ਪੁਲ ਫਿਲਟਰ ਹੈ, ਜੋ ਇੱਕ ਸਮੱਸਿਆ ਵਾਲੀ ਹਦਾਇਤ ਕੱਢ ਦਿੰਦਾ ਹੈ ਅਤੇ ਬਾਕੀ ਰੱਖਦਾ ਹੈ:

route-nopull
pull-filter ignore "redirect-gateway"

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

ਵਾਪਸੀ ਦਾ ਰਾਹ ਸਰੋਤ ਜਾਂ ਕਨੈਕਸ਼ਨ ਅਨੁਸਾਰ ਵੰਡੋ

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

ip rule add from 192.168.1.11 table 128
ip route add table 128 to 192.168.1.0/24 dev eth0
ip route add table 128 default via 192.168.1.1

ਇਹ ਇਸ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਆਉਂਦੇ SSH ਕਨੈਕਸ਼ਨ ਦੇ ਜਵਾਬ ਉਸ ਪਤੇ ਤੋਂ ਜਾਂਦੇ ਹਨ ਜਿੱਥੇ ਕਲਾਇੰਟ ਜੁੜਿਆ ਸੀ। ਜਿਸ ਰਿਪੋਰਟ ਕੀਤੇ ਕੇਸ ਵਿੱਚ ਹਰ ਆਉਂਦੀ ਸੇਵਾ ਨੂੰ ਚੱਲਦਾ ਰਹਿਣਾ ਪਿਆ, ਉੱਥੇ ਠੀਕ ਇਹੀ ਆਕਾਰ ਵਰਤਿਆ ਗਿਆ ਸੀ। ਜਦੋਂ ਆਉਂਦਾ ਪਤਾ ਤੈਰਦਾ ਹੋਵੇ ਜਾਂ ਰਾਹ ਗਤੀਸ਼ੀਲ ਹੋਵੇ, ਤਾਂ ਇਸਦੀ ਥਾਂ ਕਨੈਕਸ਼ਨ ਨੂੰ ਨਿਸ਼ਾਨ ਲਗਾਓ: ਭੌਤਿਕ ਇੰਟਰਫੇਸ ਤੋਂ ਆਉਣ ਵਾਲੇ ਪਹਿਲੇ ਪੈਕਟ ਉੱਤੇ conntrack ਨਿਸ਼ਾਨ ਲਗਾਓ, OUTPUT ਵਿੱਚ ਜਵਾਬ ਪੈਕਟਾਂ ਉੱਤੇ ਇਸਦੀ ਨਕਲ ਕਰੋ, ਅਤੇ ਨਿਸ਼ਾਨ ਲੱਗੇ ਪੈਕਟਾਂ ਨੂੰ ਭੌਤਿਕ ਗੇਟਵੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲੀ ਟੇਬਲ ਰਾਹੀਂ ਰੂਟ ਕਰੋ।

iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234
iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321
ip route add default via 192.168.1.1 dev eth0 table 3412
ip rule add fwmark 4321 table 3412

ਜਾਂਚ ਦੌਰਾਨ ਕਨੈਕਸ਼ਨ ਨਿਸ਼ਾਨ, ਫਾਇਰਵਾਲ ਨਿਸ਼ਾਨ ਅਤੇ ਟੇਬਲ ਨੰਬਰ ਵੱਖਰੇ ਰੱਖੋ। ਦੋ ਭੂਮਿਕਾਵਾਂ ਲਈ ਇੱਕੋ ਨੰਬਰ ਦੁਬਾਰਾ ਵਰਤਣ ਨਾਲ ਅਜਿਹਾ ਨਿਯਮ ਬਣਦਾ ਹੈ ਜੋ ਸਹੀ ਦਿਸਦਾ ਹੈ ਅਤੇ ਗਲਤ ਪੈਕਟਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਟੇਬਲ ਦੀ ਡਿਫ਼ਾਲਟ ਐਂਟਰੀ ਨੂੰ ਆਮ ਈਥਰਨੈੱਟ ਲਿੰਕ ਉੱਤੇ LAN ਗੇਟਵੇ ਨਾਲ via ਵੀ ਚਾਹੀਦਾ ਹੈ; ਨੰਗਾ dev eth0 ਸਿਰਫ਼ ਤਦ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਇੰਟਰਫੇਸ ਪੁਆਇੰਟ-ਟੂ-ਪੁਆਇੰਟ ਹੋਵੇ ਜਾਂ ਅਗਲਾ ਹੌਪ ਕਿਸੇ ਹੋਰ ਤਰੀਕੇ ਨਾਲ ਹੱਲ ਹੋਵੇ। ਰਿਪੋਰਟ ਕੀਤਾ Jessie ਹੋਸਟ ਸੰਜੋਗ ਨਾਲ ਅਜਿਹੇ ਲਿੰਕ ਉੱਤੇ ਸੀ ਜਿੱਥੇ ਨੰਗਾ ਰੂਪ ਕੰਮ ਕਰਦਾ ਸੀ, ਜੋ ਨਕਲ ਕਰਨ ਯੋਗ ਕੋਈ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਨਿਯਮ ਨਹੀਂ ਹੈ।

ਆਪਣੇ ਆਪ ਨੂਂ ਬਾਹਰ ਤਾਲਾ ਲਾਏ ਬਿਨਾਂ ਜਾਂਚੋ

ਡਿਸਕਨੈਕਟ ਕਰਕੇ ਜਾਂਚ ਨਾ ਕਰੋ। ਪਹਿਲਾ ਸੈਸ਼ਨ ਖੁੱਲ੍ਹਾ ਰੱਖੋ, ਟਨਲ ਉੱਪਰ ਲਿਆਓ, ਅਤੇ ਕਰਨਲ ਨੂੰ ਪੁੱਛੋ ਕਿ ਤੁਹਾਡਾ ਆਪਣਾ ਪਤਾ ਕਿਹੜਾ ਰਾਹ ਲਵੇਗਾ:

ip route get 80.128.240.55

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

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