ਡੁਪਲੀਕੇਟ IKE ਪੈਕਟ: ਗੁੰਮ ਹੋਇਆ ਬਦਲਾਅ ਲੱਭੋ

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

ਭਰਮ: ਦੁਹਰਾਈ ਬੇਨਤੀ ਇੱਕ ਲਿੰਕ 'ਤੇ ਨੁਕਸਾਨ ਸਾਬਤ ਕਰਦੀ ਹੈ

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

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

ਮੁੜ-ਭੇਜਣਾ ਅਸਲ ਵਿੱਚ ਕੀ ਦੱਸਦਾ ਹੈ

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

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

ਵਿਹਾਰਕ ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਸਿੱਟਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਦਰਜ ਕਰੋ। ਸਥਾਨਕ ਪ੍ਰਾਪਤੀ ਪਤਾ, ਨੀਤੀ ਵੱਲੋਂ ਚੁਣਿਆ ਜਵਾਬ ਮਾਰਗ, ਪੀਅਰ ਟਿਊਪਲ ਅਤੇ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਪਛਾਣਕਰਤਾ ਇੱਕ ਥਾਂ ਲਿਖੋ, ਕਿਉਂਕਿ ਰਿਕਾਰਡ ਬਾਅਦ ਵਿੱਚ ਪੜ੍ਹੇ ਜਾਣ 'ਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਵੱਖਰੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।

ਇੱਕ ਚੇਨ ਵਜੋਂ ਚਾਰ ਨਿਰੀਖਣ ਬਿੰਦੂ

ਅਦਾਨ-ਪ੍ਰਦਾਨ ਨੂੰ ਦੇਖਣ ਲਈ ਚਾਰ ਵੱਖਰੀਆਂ ਥਾਵਾਂ ਦੀ ਬਜਾਏ ਚੇਨ ਦੀਆਂ ਚਾਰ ਕੜੀਆਂ ਵਜੋਂ ਸੋਚੋ। ਕੜੀ ਸਬੂਤ ਰੱਖਦੀ ਹੈ ਜਾਂ ਅਣਜਾਣ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਚੇਨ ਆਪਣੀ ਸਭ ਤੋਂ ਕਮਜ਼ੋਰ ਦਰਜ ਕੜੀ ਜਿੰਨੀ ਹੀ ਜਾਣਕਾਰੀ ਭਰਪੂਰ ਹੁੰਦੀ ਹੈ। ਹੇਠਲਾ ਸਾਰਣੀ ਸੂਚੀ ਹੈ: ਹਰ ਥਾਂ ਕੀ ਸਾਬਤ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ ਕੀ ਅਛੂਤਾ ਛੱਡਦੀ ਹੈ।

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

ਪਹਿਲਾ ਗੁੰਮ ਬਦਲਾਅ ਲੱਭੋ

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

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

tcpdump -ni any -vv 'udp port 500 or udp port 4500'

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

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

ਲਾਹੇਵੰਦ ਰਿਪੋਰਟ ਕੀ ਕਹਿੰਦੀ ਹੈ

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

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

ਭਰਮ ਇਹ ਹੈ ਕਿ ਇੱਕ ਡੁਪਲੀਕੇਟ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਆਪਰੇਟਰ ਦੋਸ਼ੀ ਹੈ। ਹਕੀਕਤ ਇਹ ਹੈ ਕਿ ਇੱਕ ਡੁਪਲੀਕੇਟ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਟਾਈਮਰ ਖ਼ਤਮ ਹੋਇਆ, ਅਤੇ ਜਵਾਬ ਜਵਾਬ ਦੇ ਮਾਰਗ 'ਤੇ ਹੀ ਰਹਿੰਦਾ ਹੈ।