IPsec ਗੇਟਵੇ ਤੋਂ ਪਿੰਗ ਵੱਖਰਾ ਸਰੋਤ ਪਤਾ ਵਰਤਦਾ ਹੈ
ਗੇਟਵੇ ਉੱਤੇ ਹੀ ਸ਼ੁਰੂ ਕੀਤੀ ਪਿੰਗ ਆਪਣਾ ਸਰੋਤ ਚੁਣਦੀ ਹੈ, ਅਤੇ ਉਹ ਸਰੋਤ ਨੀਤੀ ਤੇ ਵਾਪਸੀ ਮਾਰਗ ਬਦਲਦਾ ਹੈ। ਉਹ ਜਾਂਚ ਚੁਣੋ ਜੋ ਤੁਹਾਨੂੰ ਲੋੜੀਂਦਾ ਸਾਬਤ ਕਰਦੀ ਹੈ।
IPsec ਗੇਟਵੇ ਤੋਂ ਦੂਜੇ ਪਾਸੇ ਪਿੰਗ ਕਰੋ, ਕੋਈ ਜਵਾਬ ਨਾ ਮਿਲੇ ਤੇ ਸੁਰੰਗ ਟੁੱਟੀ ਹੋਈ ਮੰਨ ਲਓ, ਜਦਕਿ ਗੇਟਵੇ ਪਿੱਛੇ ਹਰ ਵਰਕਲੋਡ ਆਮ ਵਾਂਗ ਟਰੈਫਿਕ ਭੇਜ ਰਿਹਾ ਹੈ। ਇਹ ਦੋ ਨਤੀਜੇ ਵਿਰੋਧੀ ਨਹੀਂ ਹਨ। ਗੇਟਵੇ ਉੱਤੇ ਸ਼ੁਰੂ ਹੋਈ ਪਿੰਗ ਸਥਾਨਕ ਸਰੋਤ ਵਾਲਾ ਪੈਕਟ ਹੈ, ਤੇ ਗੇਟਵੇ ਆਪਣੀ ਰੂਟਿੰਗ ਸਾਰਣੀ ਵਿੱਚੋਂ ਸਰੋਤ ਪਤਾ ਚੁਣਦਾ ਹੈ। ਉਹ ਚੋਣ ਸਾਈਟ ਦੇ ਅਸਲ ਟਰੈਫਿਕ ਵੱਲੋਂ ਵਰਤੇ ਜਾਂਦੇ ਪਤਿਆਂ ਨਾਲੋਂ ਵੱਖਰੀ ਹੋ ਸਕਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਬਦਲਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਨੀਤੀ ਮੇਲ ਖਾਂਦੀ ਹੈ ਤੇ ਕਿਹੜਾ ਵਾਪਸੀ ਮਾਰਗ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਨਤੀਜੇ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਜਾਂਚ ਨੇ ਕੀ ਸਾਬਤ ਕਰਨਾ ਹੈ।
ਤਿੰਨ ਵੱਖਰੇ ਸਵਾਲ ਜਿਨ੍ਹਾਂ ਦਾ ਜਵਾਬ ਪਿੰਗ ਦੇ ਸਕਦੀ ਹੈ
ਪਹਿਲਾ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਇਸ ਹੋਸਟ ਤੋਂ ਦੂਜਾ ਪਾਸਾ ਬਿਲਕੁਲ ਪਹੁੰਚਯੋਗ ਹੈ ਜਾਂ ਨਹੀਂ। ਦੂਜਾ ਇਹ ਕਿ ਸੁਰੰਗ ਦੇ ਚੋਣਕਰਤਾ ਜਾਂ ਰੂਟ-ਆਧਾਰਿਤ ਨੀਤੀ ਕਿਸੇ ਖਾਸ ਸਰੋਤ ਤੋਂ ਟਰੈਫਿਕ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ ਜਾਂ ਨਹੀਂ। ਤੀਜਾ ਇਹ ਕਿ ਗੇਟਵੇ ਪਿੱਛੇ ਦੇ ਵਰਕਲੋਡ ਤੋਂ ਅੱਗੇ ਭੇਜਿਆ ਟਰੈਫਿਕ ਸਿਰੇ ਤੋਂ ਸਿਰੇ ਤੱਕ ਕੰਮ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਇੱਕ ਹੁਕਮ ਤਿੰਨੇ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦਾ, ਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖਰਾ ਕਰਨ ਵਾਲੀ ਚੀਜ਼ ਸਰੋਤ ਪਤਾ ਹੈ।
ਪਹਿਲਾਂ ਸਵਾਲ ਚੁਣੋ। ਨਹੀਂ ਤਾਂ ਅਸਫਲ ਪਿੰਗ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਸਿਧਾਂਤ ਦਾ ਸਬੂਤ ਬਣ ਜਾਂਦੀ ਹੈ।
ਗੇਟਵੇ ਉਹ ਪਤਾ ਕਿਉਂ ਚੁਣਦਾ ਹੈ ਜਿਸ ਦੀ ਤੁਸੀਂ ਉਮੀਦ ਨਹੀਂ ਕੀਤੀ ਸੀ
ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਮੰਜ਼ਿਲ ਨੂੰ ਪਿੰਗ ਕਰਦੇ ਹੋ, ਸਥਾਨਕ ਸਟੈਕ ਉਸ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਰੂਟ ਵਿੱਚੋਂ ਸਰੋਤ ਚੁਣਦਾ ਹੈ। ਰੂਟ-ਆਧਾਰਿਤ ਸੁਰੰਗ ਵਿੱਚ ਉਹ ਸੁਰੰਗ ਇੰਟਰਫੇਸ ਦਾ ਲਿੰਕ ਪਤਾ ਹੋ ਸਕਦਾ ਹੈ, ਜੋ ਕਈ ਸਾਈਟ ਡਿਜ਼ਾਈਨਾਂ ਵਿੱਚ ਪੁਆਇੰਟ-ਟੂ-ਪੁਆਇੰਟ ਹਾਪ ਲਈ ਚੁਣੀ ਗਈ 169.254.x.x ਜੋੜੀ ਹੈ। ਉਹ ਪਤੇ ਲਿੰਕ ਦੇ ਕੰਮ ਕਰਨ ਲਈ ਹਨ; ਦੂਜੇ ਪਾਸੇ ਉਨ੍ਹਾਂ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ-ਸਰੋਤ ਨੈੱਟਵਰਕ ਵਜੋਂ ਘੋਸ਼ਿਤ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ।
ਇਸ ਲਈ ਦੂਜੇ ਪਾਸੇ ਉਸ ਪਤੇ ਤੋਂ ਗੂੰਜ ਬੇਨਤੀ ਮਿਲ ਸਕਦੀ ਹੈ ਜਿਸ ਵੱਲ ਵਾਪਸੀ ਮਾਰਗ ਨਹੀਂ ਹੈ, ਜਾਂ ਅਜਿਹੇ ਪਤੇ ਤੋਂ ਜਿਸ ਨਾਲ ਕੋਈ ਚੋਣਕਰਤਾ ਨਹੀਂ ਮਿਲਦਾ। ਸੁਰੰਗ ਸਿਹਤਮੰਦ ਹੋ ਸਕਦੀ ਹੈ ਤੇ ਪਿੰਗ ਫਿਰ ਵੀ ਅਸਫਲ ਹੋ ਸਕਦੀ ਹੈ, ਤੇ ਇਹ ਲੇਖ ਉਸੇ ਝੂਠੇ ਨਕਾਰਾਤਮਕ ਬਾਰੇ ਹੈ।
ਸਰੋਤ ਜਾਣ-ਬੁੱਝ ਕੇ ਚੁਣੋ
ਨਿਯੰਤਰਿਤ Linux ਗੇਟਵੇ ਉੱਤੇ ਪਹਿਲਾਂ ਹੀ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਦਿੱਤਾ ਗਿਆ ਸਰੋਤ ਚੁਣੋ: ping -c 4 -I 10.30.0.1 10.40.0.20। ਇੱਥੇ ਪਤੇ ਉਦਾਹਰਨ ਲਈ ਹਨ, ਇਸ ਲਈ ਗੇਟਵੇ ਦਾ ਅਸਲ ਅੰਦਰੂਨੀ ਪਤਾ ਤੇ ਅਸਲ ਦੂਰ ਦੀ ਮੰਜ਼ਿਲ ਪਾਓ, ਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਹਾਡਾ ਚੁਣਿਆ ਸਰੋਤ ਇਸੇ ਡਿਵਾਈਸ ਦਾ ਹੈ ਤੇ ਸਾਈਟ ਨੀਤੀ ਉਸ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਦੀ ਹੈ।
ਜਾਂਚ ਲਈ ਕਿਸੇ ਵਰਕਲੋਡ ਦਾ ਪਤਾ ਉਧਾਰ ਨਾ ਲਓ। ਜਿਸ ਹੋਸਟ ਨੂੰ ਗੇਟਵੇ ਨਾਲ ਨਹੀਂ ਦਿੱਤਾ ਗਿਆ, ਉਸ ਦਾ ਰੂਪ ਧਾਰਨ ਕਰਨਾ ਅਜਿਹਾ ਨਤੀਜਾ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਕੋਈ ਦੁਬਾਰਾ ਨਹੀਂ ਬਣਾ ਸਕਦਾ, ਤੇ ਕੁਝ ਸਟੈਕਾਂ ਉੱਤੇ ਇਹ ਸੁਰੰਗ ਦੀ ਖਰਾਬੀ ਵਾਂਗ ਦਿਸਣ ਵਾਲੇ ਢੰਗ ਨਾਲ ਅਸਫਲ ਹੁੰਦਾ ਹੈ।
ਸਿਰਫ਼ ਬੇਨਤੀ ਨਹੀਂ, ਵਾਪਸੀ ਮਾਰਗ ਵੀ ਪੜ੍ਹੋ
ਜਾਂਚੋ ਕਿ ਦੂਰ ਦੀ ਮੰਜ਼ਿਲ ਉੱਤੇ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਸਰੋਤ ਪਹੁੰਚਦਾ ਹੈ, ਰਸਤੇ ਵਿੱਚ ਕੀਤੇ ਕਿਸੇ ਜਾਣ-ਬੁੱਝ ਕੇ ਅਨੁਵਾਦ ਸਮੇਤ। ਫਿਰ ਦੂਜੇ ਪਾਸੇ ਦਾ ਉਸ ਸਰੋਤ ਵੱਲ ਵਾਪਸੀ ਰੂਟ ਤੇ ਉਸ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣ ਵਾਲੇ ਚੋਣਕਰਤਾ ਜਾਂ ਨੀਤੀ ਜਾਂਚੋ। ਅਚਾਨਕ ਸਰੋਤ ਨਾਲ ਆਉਣ ਵਾਲੀ ਬੇਨਤੀ ਰੂਟਿੰਗ ਤੇ ਨੀਤੀ ਦਾ ਸਵਾਲ ਹੈ, ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਦਾ ਨਹੀਂ।
ਇੱਥੇ ਹੀ ਇੱਕ ਹੋਰ ਪਿੰਗ ਨਾਲੋਂ ਪੈਕਟ ਕੈਪਚਰ ਵੱਧ ਮਦਦ ਕਰਦਾ ਹੈ: ਇਹ ਦੂਜੇ ਪਾਸੇ ਵੱਲੋਂ ਦੇਖਿਆ ਸਰੋਤ ਦਿਖਾਉਂਦਾ ਹੈ, ਤੇ ਉਸ ਦੇ ਜਵਾਬ ਨੂੰ ਉਸੇ ਪਤੇ ਤੱਕ ਪਹੁੰਚਣਾ ਹੈ।
ਫਿਰ ਵਰਕਲੋਡ ਦੀ ਜਾਂਚ ਕਰੋ
ਫੈਸਲਾਕੁੰਨ ਜਾਂਚ ਗੇਟਵੇ ਪਿੱਛੇ ਦੇ ਆਮ ਹੋਸਟ ਤੋਂ ਦੂਰ ਦੇ ਗੇਟਵੇ ਪਿੱਛੇ ਦੇ ਆਮ ਹੋਸਟ ਤੱਕ ਪਿੰਗ ਹੈ। ਇਹ ਗੇਟਵੇ ਦੀ ਅੱਗੇ ਭੇਜਣ ਦੀ ਭੂਮਿਕਾ, ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਅਸਲ ਸਰੋਤ ਤੇ ਸੱਚਾ ਵਾਪਸੀ ਮਾਰਗ ਜਾਂਚਦੀ ਹੈ, ਤੇ ਵਰਤੋਂਕਾਰਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਪ੍ਰਵਾਹ ਇਹੀ ਹੈ।
ਆਪਣੀਆਂ ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਨਤੀਜੇ ਵੱਖਰੇ ਰੱਖੋ: ਗੇਟਵੇ ਤੋਂ ਪਹੁੰਚ, ਚੁਣੇ ਸਰੋਤ ਲਈ ਨੀਤੀ ਦੀ ਮਨਜ਼ੂਰੀ, ਤੇ ਅੱਗੇ ਭੇਜਿਆ ਟਰੈਫਿਕ। ਸਫਲਤਾਪੂਰਵਕ ਪਿੰਨ ਕੀਤੀ ਪਿੰਗ ਇਸ ਗੱਲ ਦਾ ਲਾਹੇਵੰਦ ਸਬੂਤ ਹੈ ਕਿ ਸੁਰੰਗ ਕੁਝ ਢੋਂਦੀ ਹੈ; ਇਹ ਸਬੂਤ ਨਹੀਂ ਕਿ ਹਰ ਅੱਗੇ ਭੇਜਿਆ ਪ੍ਰਵਾਹ ਕੰਮ ਕਰਦਾ ਹੈ। ਤੇ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਆਪਣੇ-ਆਪ ਚੁਣਿਆ ਗੇਟਵੇ ਸਰੋਤ ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਨਹੀਂ ਕਿ ਸਾਈਟ ਦੀ ਸੁਰੰਗ ਬੰਦ ਹੈ।
ਸਿਰਫ਼ ਇੱਕ ਨਿਦਾਨ ਜਵਾਬ ਲੈਣ ਲਈ 169.254.0.0/16 ਲਈ ਵਿਆਪਕ ਰੂਟ ਨਾ ਜੋੜੋ। ਇਹ ਭਰਮਾਉਣ ਵਾਲੀ ਜਾਂਚ ਦੇ ਬਦਲੇ ਸਥਾਈ ਰੂਟਿੰਗ ਫੈਸਲਾ ਲੈਂਦਾ ਹੈ, ਤੇ ਅਗਲਾ ਵਿਅਕਤੀ ਇਸ ਨੂੰ ਸੰਦਰਭ ਤੋਂ ਬਿਨਾਂ ਵਿਰਾਸਤ ਵਿੱਚ ਪਾਉਂਦਾ ਹੈ।