IPsec ਚਾਈਲਡ SA ਚਾਲੂ ਹੈ, ਪਰ ਪੈਕਟ ਕਾਊਂਟਰ ਸਿਫ਼ਰ ਹੀ ਰਹਿੰਦੇ ਹਨ

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

ਸਿਫ਼ਰ ਕਾਊਂਟਰ ਅਸਲ ਵਿੱਚ ਕੀ ਸਿੱਧ ਕਰਦਾ ਹੈ

CHILD SA ਇੱਕ ਚੋਣਕਾਰ ਜੋੜੀ ਅਤੇ ਉਹਨਾਂ ਘੇਰਿਆਂ ਵਿੱਚ ਆਉਣ ਵਾਲੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕਰਨ ਵਾਲੀਆਂ ਚਾਬੀਆਂ ਅਤੇ SPI ਹੈ। ਇਸਨੂੰ ਸਥਾਪਿਤ ਕਰਨ ਦਾ ਮਤਲਬ ਸਿਰਫ਼ ਇਹ ਹੈ ਕਿ ਦੋਵੇਂ ਪੀਅਰ ਉਹਨਾਂ ਘੇਰਿਆਂ ਅਤੇ ਕੱਢੀਆਂ ਚਾਬੀਆਂ ਉੱਤੇ ਸਹਿਮਤ ਹੋਏ; ਕਰਨਲ ਇੱਕ ਵੀ ਪੈਕਟ ਆਏ ਬਿਨਾਂ ਇਸਨੂੰ ਘੰਟਿਆਂ ਤੱਕ ਰੱਖਦਾ ਹੈ। ਇਸ ਲਈ ਸਵਾਲ ਕਦੇ ਇਹ ਨਹੀਂ ਕਿ ਸੁਰੰਗ ਮੌਜੂਦ ਹੈ ਜਾਂ ਨਹੀਂ, ਸਗੋਂ ਇਹ ਕਿ ਤੁਹਾਡੇ ਟੈਸਟ ਨੇ ਭੇਜਿਆ ਕੋਈ ਪੈਕਟ ਦੋਵੇਂ ਪੀਅਰਾਂ ਵੱਲੋਂ ਤੈਅ ਕੀਤੇ ਘੇਰਿਆਂ ਵਿੱਚ ਪਿਆ ਜਾਂ ਨਹੀਂ। ਜੇ ਕੋਈ ਨਹੀਂ ਪਿਆ, ਕਾਊਂਟਰ ਸਿਫ਼ਰ ਹੀ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਐਸੋਸੀਏਸ਼ਨ ਆਪਣੀ ਉਮਰ ਦੇ ਅੰਤ ਵਿੱਚ ਬਿਨਾਂ ਵਰਤੇ ਮਿਟ ਜਾਂਦੀ ਹੈ।

ਇਹ ਫ਼ਰਕ ਬਦਲਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਪਹਿਲਾਂ ਕੀ ਜਾਂਚਦੇ ਹੋ। ਰੱਦ ਕੀਤਾ ਪ੍ਰਸਤਾਵ, ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਅਸਫਲਤਾ ਜਾਂ ਮਰ ਰਿਹਾ IKE SA ਸਭ ਲੌਗ ਵਿੱਚ ਜਾਂ SA ਸੂਚੀ ਵਿੱਚ ਦਿਖਦੇ ਹਨ, ਚੁੱਪ ਸਿਫ਼ਰ ਵਜੋਂ ਨਹੀਂ। ਸਾਫ਼-ਸੁਥਰੀ ਵਾਟਾਘਾਟੀ ਕਰਕੇ ਫਿਰ ਖਾਲੀ ਰਹਿਣ ਵਾਲੀ ਸੁਰੰਗ ਇਸ ਦੀ ਬਜਾਏ ਮਿਲਾਨ, ਰੂਟਿੰਗ ਜਾਂ ਟੈਸਟ ਟ੍ਰੈਫਿਕ ਦੇ ਮੂਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ।

ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਵਰਣਨ ਕਰਨ ਯੋਗ ਪ੍ਰਵਾਹ ਭੇਜੋ

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

ਸਰੋਤ ਪਤਾ ਉਹ ਮੁੱਲ ਹੈ ਜੋ ਲੋਕ ਛੱਡ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਇਹੀ ਟੈਸਟ ਸਭ ਤੋਂ ਵੱਧ ਤੋੜਦਾ ਹੈ। ਤਾਰ ਵਾਲਾ ਪਤਾ, Wi-Fi ਪਤਾ ਅਤੇ ਸੁਰੰਗ ਪਤਾ ਵਾਲਾ ਲੈਪਟਾਪ ਰੂਟ ਖੋਜ ਅਨੁਸਾਰ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਬਾਈਂਡ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਤੈਅ ਕੀਤੇ ਘੇਰੇ ਅੰਦਰ ਹੋ ਸਕਦਾ ਹੈ। ਅਜਿਹਾ ਸਾਧਨ ਵਰਤੋ ਜੋ ਸਰੋਤ ਪਿੰਨ ਕਰਨ ਦਿੰਦਾ ਹੈ, ਜਿਵੇਂ ping -I 10.1.0.5 10.2.0.9 ਜਾਂ curl --interface 10.1.0.5, ਤਾਂ ਜੋ ਪੈਕਟ ਚੁੱਪਚਾਪ ਕੋਈ ਹੋਰ ਪਤਾ ਨਾ ਚੁਣ ਸਕੇ। ਜਦੋਂ ਪਿੰਨ ਕੀਤੀ ਦੌੜ ਕਾਊਂਟਰ ਹਿਲਾਉਂਦੀ ਹੈ ਅਤੇ ਬਿਨਾਂ ਪਿੰਨ ਵਾਲੀ ਨਹੀਂ, ਤਾਂ ਤੁਸੀਂ IPsec ਦੀ ਨਹੀਂ ਸਗੋਂ ਰੂਟਿੰਗ ਦੀ ਸਮੱਸਿਆ ਲੱਭੀ ਹੈ।

ਕਿਹੜੇ ਅੰਕ ਪੜ੍ਹਨੇ ਹਨ, ਅਤੇ ਉਹ ਕਿੱਥੇ ਰਹਿੰਦੇ ਹਨ

Linux ਉੱਤੇ ip -s xfrm state ਹਰ ਐਸੋਸੀਏਸ਼ਨ ਨੂੰ lifetime current: ਲਾਈਨ ਨਾਲ ਛਾਪਦਾ ਹੈ ਜਿਸਦਾ ਬਾਈਟ ਅਤੇ ਪੈਕਟ ਜੋੜ ਸਿਰਫ਼ ਉਸ SA ਦਾ ਹੁੰਦਾ ਹੈ, ਫਿਰ ਰੀਪਲੇ ਅਤੇ ਗਲਤੀ ਗਿਣਤੀ ਲਈ stats: ਲਾਈਨ ਆਉਂਦੀ ਹੈ। strongSwan ਪੀਅਰ ਉੱਤੇ swanctl --list-sas ਸਥਾਪਿਤ ਹਰ ਚਾਈਲਡ ਲਈ ਇੱਕ in ਲਾਈਨ ਅਤੇ ਇੱਕ out ਲਾਈਨ ਛਾਪਦਾ ਹੈ, ਹਰ ਇੱਕ ਬਾਈਟ ਅਤੇ ਪੈਕਟ ਗਿਣਤੀ ਉੱਤੇ ਖ਼ਤਮ ਹੁੰਦੀ ਹੈ; ਪੁਰਾਣੇ stroke ਸਾਧਨ ਉਸੇ ਜੋੜੀ ਨੂੰ bytes_i ਅਤੇ bytes_o ਕਹਿੰਦੇ ਹਨ। ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵੱਖਰੀਆਂ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਸਮਤਲ ਰਹੀ ਦਿਸ਼ਾ ਹੀ ਖੋਜ ਹੈ। ਉਹਨਾਂ ਨੂੰ ਜੋੜਨਾ ਠੀਕ ਉਹੀ ਅਸਮਾਨਤਾ ਲੁਕਾਉਂਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਲੱਭ ਰਹੇ ਹੋ।

ਦੋਵੇਂ ਦ੍ਰਿਸ਼ ਪ੍ਰਤੀ ਐਸੋਸੀਏਸ਼ਨ ਹਨ, ਇਸ ਲਈ ਰੀਕੀ ਨਵੀਂ SPI ਜੋੜੀ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡਾ ਆਧਾਰ ਕੁਝ ਨਾ ਟੁੱਟਦਿਆਂ ਸਿਫ਼ਰ ਉੱਤੇ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ। ਰੀਕੀ ਟਾਈਮਰ ਚੱਲਣ ਤੋਂ ਪਹਿਲਾਂ ਤੁਸੀਂ ਜੋ SPI ਦੇਖ ਰਹੇ ਹੋ ਉਹ ਲਿਖ ਲਓ, ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਨਵੀਂ SA ਦੀ ਪੁਰਾਣੇ ਅੰਕ ਨਾਲ ਤੁਲਨਾ ਕਰੋਗੇ। ਜੇ ਬਾਹਰ ਜਾਣ ਵਾਲੀ ਦਿਸ਼ਾ ਵਧਦੀ ਹੈ ਜਦੋਂ ਕਿ ਅੰਦਰ ਆਉਣ ਵਾਲੀ ਸਮਤਲ ਰਹਿੰਦੀ ਹੈ, ਤਾਂ ਚੋਣਕਾਰ ਮਿਲ ਗਿਆ ਪਰ ਜਵਾਬ ਕਦੇ ਵਾਪਸ ਨਹੀਂ ਆਇਆ, ਜੋ ਜਾਂਚ ਨੂੰ ਪੀਅਰ ਦੀ ਫਾਰਵਰਡਿੰਗ ਅਤੇ ਉਸਦੀ ਆਪਣੀ ਨੀਤੀ ਵੱਲ ਭੇਜਦਾ ਹੈ। strongSwan ਦਾ IKEv2 ਕਨਫਿਗਰੇਸ਼ਨ ਦਸਤਾਵੇਜ਼ ਚਾਈਲਡ SA ਦੇ ਜੀਵਨ ਚੱਕਰ ਅਤੇ ਉਹਨਾਂ ਅੰਕਾਂ ਪਿੱਛੇ ਦੇ ਰੀਕੀ ਸਮੇਂ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ।

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

ਰੂਟ, ਚੋਣਕਾਰ ਅਤੇ ਪੈਕਟ ਕਿੱਥੇ ਜਨਮਿਆ

ਤਿੰਨ ਚੀਜ਼ਾਂ ਨੂੰ ਨਾਲ-ਨਾਲ ਤੋਲੋ: ਕਰਨਲ ਤੁਹਾਡੀ ਮੰਜ਼ਿਲ ਲਈ ਚੁਣਿਆ ਰੂਟ, ਟ੍ਰੈਫਿਕ ਨੂੰ ਸੁਰੰਗ ਵਿੱਚ ਭੇਜਣ ਵਾਲੀ ਨੀਤੀ, ਅਤੇ ਚਾਈਲਡ ਵੱਲੋਂ ਤੈਅ ਕੀਤੀ ਚੋਣਕਾਰ ਜੋੜੀ। ip route get 10.2.0.9 from 10.1.0.5 ਕਰਨਲ ਵੱਲੋਂ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਇੰਟਰਫੇਸ ਅਤੇ ਸਰੋਤ ਦਾ ਨਾਮ ਦੱਸਦਾ ਹੈ, ਜੋ ਅਕਸਰ ਤੁਹਾਡੇ ਮੰਨੇ ਜੋੜੀ ਨਹੀਂ ਹੁੰਦਾ। ip xfrm policy ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਸਥਾਪਿਤ ਟੈਂਪਲੇਟ ਅਤੇ ਚੋਣਕਾਰ ਦਿਖਾਉਂਦਾ ਹੈ, ਜਦੋਂ ਕਿ swanctl --list-sas ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਪੀਅਰ ਕਿਸ ਉੱਤੇ ਸਹਿਮਤ ਹੋਇਆ। ਪੈਕਟ ਨੂੰ ਭੌਤਿਕ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਬਾਹਰ ਭੇਜਣ ਵਾਲੀ ਖੋਜ ਨੀਤੀ ਤੱਕ ਪਹੁੰਚਦੀ ਹੀ ਨਹੀਂ, ਇਸ ਲਈ ਕਾਊਂਟਰ ਹਿਲ ਨਹੀਂ ਸਕਦੇ।

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

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

ਇੱਕ ਵਾਪਸ ਲਿਆ ਜਾ ਸਕਣ ਵਾਲਾ ਬਦਲਾਅ ਅਤੇ ਸਮੀਖਿਆ ਝੱਲਣ ਵਾਲੀ ਰਿਪੋਰਟ

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

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