ਰੂਟਿੰਗ ਟੇਬਲ ਬਨਾਮ ਅਸਲ ਲੁੱਕਅੱਪ: VPN ਟ੍ਰੈਫਿਕ ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ

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

ਟੇਬਲ ਉਮੀਦਵਾਰਾਂ ਦਾ ਸਮੂਹ ਹੈ, ਫੈਸਲਾ ਨਹੀਂ

ਹਰ ਐਂਟਰੀ ਇੱਕ ਪ੍ਰੀਫਿਕਸ ਅਤੇ ਉਸ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਟ੍ਰੈਫਿਕ ਨਾਲ ਕੀ ਕਰਨਾ ਹੈ ਦੱਸਦੀ ਹੈ: ਇਸਨੂੰ ਇੰਟਰਫੇਸ ’ਤੇ ਭੇਜੋ, ਅਗਲੇ ਹਾਪ ਨੂੰ ਦਿਓ, ਜਾਂ ਸੁੱਟ ਦਿਓ। ਉਸ ਸੂਚੀ ਵਿੱਚ ਕੁਝ ਵੀ ਇਰਾਦੇ ਅਨੁਸਾਰ ਤਰਤੀਬਬੱਧ ਨਹੀਂ ਹੈ, ਅਤੇ ਮਨੁੱਖ ਨੂੰ ਸਭ ਤੋਂ ਖਾਸ ਦਿਸਣ ਵਾਲੀ ਐਂਟਰੀ ਹਮੇਸ਼ਾ ਉਹ ਨਹੀਂ ਹੁੰਦੀ ਜੋ ਕਰਨਲ ਚੁਣਦਾ ਹੈ, ਕਿਉਂਕਿ ਚੋਣ ਸਭ ਤੋਂ ਲੰਮੇ ਪ੍ਰੀਫਿਕਸ ਮੇਲ ਦੀ ਅਤੇ ਬਰਾਬਰ ਪ੍ਰੀਫਿਕਸਾਂ ਵਿਚਕਾਰ ਮੈਟ੍ਰਿਕ ਦੀ ਪਾਲਣਾ ਕਰਦੀ ਹੈ।

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

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

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

ਲੁੱਕਅੱਪ ਪਹਿਲਾਂ ਨਿਯਮਾਂ ਵਿੱਚੋਂ, ਫਿਰ ਟੇਬਲਾਂ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ

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

ip rule show
ip route show table all | head -40
ip route show table 100

ਜੇ ਕੋਈ ਨਿਯਮ ਤੁਹਾਡੇ VPN ਪੂਲ ਵਿੱਚੋਂ ਟ੍ਰੈਫਿਕ ਨੂੰ ਟੇਬਲ 100 ’ਤੇ ਭੇਜਦਾ ਹੈ, ਤਾਂ ਮਹੱਤਵਪੂਰਨ ਟੇਬਲ 100 ਹੈ, ਅਤੇ ਮੁੱਖ ਟੇਬਲ ਇੱਕ ਜਾਲ ਹੈ। ਇਹ ਰਾਊਟਰ ’ਤੇ ਸਰੋਤ-ਅਧਾਰਿਤ ਰੂਟਿੰਗ ਦਾ ਵੀ ਮਕੈਨਿਜ਼ਮ ਹੈ: ਇੱਕੋ ਮੰਜ਼ਿਲ ਦੇ ਪੈਕਟ ਕਿੱਥੋਂ ਆਇਆ ਇਸ ’ਤੇ ਨਿਰਭਰ ਕਰਦਿਆਂ ਦੋ ਵੱਖਰੇ ਜਵਾਬ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ ਸਿਰਫ਼ ਸਰੋਤ ਆਰਗਿਊਮੈਂਟ ਵਾਲਾ ਲੁੱਕਅੱਪ ਹੀ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਲਾਗੂ ਹੁੰਦਾ ਹੈ।

IPv6 ਦੇ ਆਪਣੇ ਨਿਯਮ ਅਤੇ ਟੇਬਲ ਹਨ। ਦੋਵੇਂ ਪਰਿਵਾਰ ਚਲਾਉਣ ਵਾਲੇ ਡਿਜ਼ਾਈਨ ਨੂੰ ਦੋਵੇਂ ਲੁੱਕਅੱਪ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ਕੰਮ ਕਰਦਾ IPv4 ਜਵਾਬ v6 ਰਾਹ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ ਜੋ ਦੋਹਰੀ-ਸਟੈਕ ਕਲਾਇੰਟ ਪਸੰਦ ਕਰ ਸਕਦਾ ਹੈ।

VPN ਕਲਾਇੰਟ ਕੀ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ

ਕਲਾਇੰਟ ਆਮ ਤੌਰ ’ਤੇ ਡਿਫਾਲਟ ਰੂਟ ਨਹੀਂ ਬਦਲਦੇ, ਕਿਉਂਕਿ ਇਸ ਨਾਲ ਟਨਲ ਦਾ ਆਪਣਾ ਬਾਹਰੀ ਰਾਹ ਟੁੱਟ ਜਾਵੇਗਾ। ਉਹ ਵਧੇਰੇ ਖਾਸ ਚੀਜ਼ ਸਥਾਪਿਤ ਕਰਦੇ ਹਨ ਜੋ ਪ੍ਰੀਫਿਕਸ ਲੰਬਾਈ ਨਾਲ ਜਿੱਤਦੀ ਹੈ: 0.0.0.0/1 ਅਤੇ 128.0.0.0/1 ਨੂੰ ਢਕਣ ਵਾਲੀ ਅੱਧ-ਡਿਫਾਲਟ ਜੋੜੀ ਕਲਾਸਿਕ ਚਾਲ ਹੈ, ਕਿਉਂਕਿ ਦੋਵੇਂ 0.0.0.0/0 ਤੋਂ ਲੰਮੇ ਪ੍ਰੀਫਿਕਸ ਹਨ ਅਤੇ ਇਕੱਠੇ ਪੂਰੀ ਥਾਂ ਢਕਦੇ ਹਨ। ਹੋਰ ਵਿਸ਼ੇਸ਼ ਨਿੱਜੀ ਪ੍ਰੀਫਿਕਸ ਅਤੇ ਨੀਤੀ ਨਿਯਮ ਸਥਾਪਿਤ ਕਰਦੇ ਹਨ, ਅਤੇ ਕੁਝ ਇੱਕ ਮਾਰਕ ਜੋੜਦੇ ਹਨ ਤਾਂ ਜੋ ਸਿਰਫ਼ ਚੁਣਿਆ ਟ੍ਰੈਫਿਕ ਫੜਿਆ ਜਾਵੇ।

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

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

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

ਬਾਹਰੀ ਰੂਟ ਵੀ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ

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

ਪੀਅਰ ਦਾ ਪਤਾ ਉਵੇਂ ਜਾਂਚੋ ਜਿਵੇਂ ਤੁਸੀਂ ਅੰਦਰੂਨੀ ਮੰਜ਼ਿਲ ਜਾਂਚੀ ਸੀ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਹ ਟਨਲ ਦੀ ਥਾਂ ਭੌਤਿਕ ਇੰਟਰਫੇਸ ’ਤੇ ਹੱਲ ਹੁੰਦਾ ਹੈ:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

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

ਰੂਟਿੰਗ ਆਉਟਪੁੱਟ ਤੁਹਾਨੂੰ ਕੀ ਨਹੀਂ ਦੱਸ ਸਕਦੀ

ਸਹੀ ਲੁੱਕਅੱਪ ਦਾ ਅਰਥ ਹੈ ਕਿ ਕਰਨਲ ਪੈਕਟ ਨੂੰ ਕਿਤੇ ਵਾਜਬ ਥਾਂ ’ਤੇ ਭੇਜੇਗਾ। ਇਸਦਾ ਅਰਥ ਇਹ ਨਹੀਂ ਕਿ ਫਾਇਰਵਾਲ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, IPsec ਨੀਤੀ ਇਸਨੂੰ ਢਕਦੀ ਹੈ, NAT ਨਿਯਮ ਇਸਦਾ ਤਰਜਮਾ ਕਰਦਾ ਹੈ, ਜਾਂ ਦੂਰ ਵਾਲੇ ਪਾਸੇ ਵਾਪਸੀ ਰੂਟ ਹੈ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਅਗਲਾ ਪੜਾਅ ਹੈ, ਅਤੇ strongSwan ਦੇ ਫਾਰਵਰਡਿੰਗ ਨੋਟਸ ਦੋਵੇਂ ਸਿਰਿਆਂ ’ਤੇ ਪੈਕਟ ਨੂੰ ਲੰਘਣ ਵਾਲੀ ਲੜੀ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਨ।

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

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