ਕੀ ਦੋ IPsec ਸਾਥੀਆਂ ਵਿਚਕਾਰਲੇ ਰਾਊਟਰ ਨੂੰ IPsec ਦੀ ਲੋੜ ਹੈ?

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

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

ਅੱਗੇ ਭੇਜਣਾ ਖ਼ਤਮ ਕਰਨਾ ਨਹੀਂ ਹੈ

ਟਨਲ ਮੋਡ ਵਿੱਚ ਬਾਹਰੀ IP ਹੈਡਰ ਟਨਲ ਖ਼ਤਮ ਕਰਨ ਵਾਲੇ ਯੰਤਰਾਂ ਨੂੰ ਸੰਬੋਧਿਤ ਹੁੰਦਾ ਹੈ। ਵਿਚਕਾਰਲਾ ਰਾਊਟਰ ਮੰਜ਼ਿਲ ਲੱਭ ਕੇ ਅੱਗੇ ਭੇਜਦਾ ਹੈ, ਬਿਲਕੁਲ ਕਿਸੇ ਹੋਰ ਪੈਕਟ ਵਾਂਗ, ਅਤੇ ਇਹ ਜੋ ਪੇਲੋਡ ਲੈ ਜਾਂਦਾ ਹੈ ਉਹ ਇਸ ਲਈ ਅਪਾਰਦਰਸ਼ੀ ਹੈ।

ਇਹ ਅਪਾਰਦਰਸ਼ਤਾ ਜਾਣ-ਬੁੱਝ ਕੇ ਹੈ। ਰਾਊਟਰ ਕੋਲ ਸਾਥੀ ਦਾ ਭੇਦ ਨਹੀਂ ਹੁੰਦਾ, ਇਹ ਕੋਈ ਗੱਲਬਾਤ ਨਹੀਂ ਕਰਦਾ ਅਤੇ ਇਸ ਨੂੰ ਨੀਤੀ ਡੇਟਾਬੇਸ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਇਸ ਨੂੰ ਦੂਰਲੇ ਸਿਰੇ ਤੱਕ ਮਾਰਗ ਅਤੇ ਪੈਕਟ ਅੱਗੇ ਭੇਜਣ ਦੀ ਇਜਾਜ਼ਤ ਚਾਹੀਦੀ ਹੈ।

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

ਵਿਚਕਾਰਲੇ ਯੰਤਰ ਨੂੰ ਫਿਰ ਵੀ ਕੀ ਸਹੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ

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

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

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

ਸਿਮੂਲੇਟਰ ਸਵਾਲ ਕਿਉਂ ਬਦਲਦਾ ਹੈ

ਸਿਮੂਲੇਟਰ ਛੋਟੀ ਸੁਵਿਧਾ-ਸੂਚੀ ਵਾਲਾ ਰਾਊਟਰ ਨਹੀਂ; ਇਹ ਇੱਕ ਮਾਡਲ ਹੈ ਜਿਸਦਾ ਦਸਤਾਵੇਜ਼ੀ ਉਪ-ਸਮੂਹ ਅਤੇ ਆਪਣੇ ਨਿਯਮ ਹਨ ਕਿ ਕਿਸੇ ਦਿੱਤੇ ਯੰਤਰ ਨੂੰ ਕੀ ਕਰਨ ਲਈ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। Cisco ਦੇ Packet Tracer ਆਮ ਸਵਾਲ ਸਪਸ਼ਟ ਕਹਿੰਦੇ ਹਨ ਕਿ ਯੰਤਰ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ ਸਰਲ ਕੀਤੇ ਮਾਡਲ ਹਨ।

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

ਗੈਰਹਾਜ਼ਰ ਹੁਕਮ ਤੁਹਾਡੀ ਸੰਰਚਨਾ ਦੀ ਗਲਤੀ ਨਹੀਂ ਸਗੋਂ ਮਾਡਲ ਦੀ ਸੀਮਾ ਹੋ ਸਕਦਾ ਹੈ। ਮੌਜੂਦ ਹੁਕਮ ਹਰ ਉਤਪਾਦਨ ਵਿਵਹਾਰ ਦੁਹਰਾਏ ਬਿਨਾਂ ਸਿੰਟੈਕਸ ਸਵੀਕਾਰ ਕਰ ਸਕਦਾ ਹੈ। ਕਿਸੇ ਵੀ ਦਿਸ਼ਾ ਵਿੱਚ ਸਿੱਟਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਸਥਾਪਿਤ ਸੰਸਕਰਣ ਦੀ ਯੰਤਰ ਸਹਾਇਤਾ ਵੇਖੋ।

ਪ੍ਰਯੋਗਸ਼ਾਲਾ ਲਈ ਪਾਸ ਹੋਣ ਦੀ ਸ਼ਰਤ ਲਿਖਣਾ

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

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

ਸਿਮੂਲੇਟਰ ਦਾ ਸੰਸਕਰਣ, ਚੁਣੇ ਯੰਤਰ ਅਤੇ ਸਿੱਖਣ ਦਾ ਮਕਸਦ ਟੋਪੋਲੋਜੀ ਫਾਈਲ ਨਾਲ ਰੱਖੋ। ਇਹੀ ਰਿਕਾਰਡ ਕਿਸੇ ਹੋਰ ਨੂੰ ਅਭਿਆਸ ਦੁਹਰਾਉਣ ਅਤੇ ਇਹ ਸਮਝਣ ਦਿੰਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਹਿੱਸੇ ਮਾਡਲ ਕੀਤੇ ਗਏ ਸਨ।

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