ਕੀ ਇੱਕ WAN ਇੰਟਰਫ਼ੇਸ ਸਾਈਟ-ਟੂ-ਸਾਈਟ ਅਤੇ ਰਿਮੋਟ VPN ਦੋਵੇਂ ਸੇਵਾ ਦੇ ਸਕਦਾ ਹੈ?

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

ਤੇਜ਼ ਸਮਝਦਾਰੀ ਜਾਂਚ: ਰਾਊਟਰ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਦਾਖਲਾ ਰਿਕਾਰਡ ਲਿਖ ਕੇ ਵੇਖੋ। ਜੇ ਇੱਕ ਹੀ ਮਿਲਾਨ ਸ਼ਰਤ ਨੇ ਦੋਵੇਂ ਢਕਣੇ ਪੈਣ, ਤਾਂ ਨੀਤੀ ਪਹਿਲਾਂ ਹੀ ਅਸਪਸ਼ਟ ਹੈ, ਅਤੇ ਪਹਿਲਾ ਲੱਛਣ ਰੂਟਿੰਗ ਜਾਂ ਫਾਇਰਵਾਲ ਦੀ ਖਰਾਬੀ ਵਰਗਾ ਦਿਸੇਗਾ ਜਦੋਂ ਕਿ ਅਸਲ ਵਿੱਚ ਉਹ ਪਛਾਣ ਦੀ ਖਰਾਬੀ ਹੈ।

ਕਿਸੇ ਵੀ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਦੋ ਰਿਕਾਰਡ

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

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

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

ਪੀਅਰ ਮਿਲਾਨ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਕਿੱਥੇ ਵੱਖ ਹੁੰਦੇ ਹਨ

IOS XE 'ਤੇ IKEv2 ਪ੍ਰੋਫ਼ਾਈਲ ਉਹ ਪੈਰਾਮੀਟਰ ਲੈ ਕੇ ਜਾਂਦੀ ਹੈ ਜਿਨ੍ਹਾਂ 'ਤੇ ਗੱਲਬਾਤ ਨਹੀਂ ਹੋ ਸਕਦੀ, ਅਤੇ ਉਹ ਸ਼ਰਤਾਂ ਵੀ ਜਿਨ੍ਹਾਂ ਨਾਲ ਪੀਅਰ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸ਼ਾਖਾ ਪਾਸੇ ਅਤੇ ਘੁੰਮਦੇ ਪਾਸੇ ਦੋਵਾਂ ਨੂੰ ਆਪਣੀ-ਆਪਣੀ ਪ੍ਰੋਫ਼ਾਈਲ ਚਾਹੀਦੀ ਹੈ, ਭਾਵੇਂ ਉਹ ਇੱਕੋ ਇੰਟਰਫ਼ੇਸ 'ਤੇ ਖ਼ਤਮ ਹੋਣ ਅਤੇ ਭਾਵੇਂ ਉਹ ਇੱਕੋ ਕ੍ਰਿਪਟੋ PKI ਸਾਂਝਾ ਕਰਨ। Cisco ਨੇ ਪ੍ਰੋਫ਼ਾਈਲ, ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਮਿਲਾਨ ਦੀਆਂ ਭੂਮਿਕਾਵਾਂ ਆਪਣੀ IOS XE 17 ਲਈ IKEv2 ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਗਾਈਡ ਵਿੱਚ।

ਸ਼ਾਖਾ ਪ੍ਰੋਫ਼ਾਈਲ ਆਮ ਤੌਰ 'ਤੇ ਤੰਗ ਪਛਾਣ ਨਾਲ ਮਿਲਦੀ ਹੈ: ਦੂਰ ਦਾ ਪਤਾ, FQDN, ਜਾਂ ਸਰਟੀਫ਼ਿਕੇਟ ਵਿਸ਼ਾ। match identity remote address 198.51.100.10 255.255.255.255 ਵਰਗੀ ਇੱਕ ਲਾਈਨ ਇੱਕ ਪੀਅਰ ਨੂੰ ਪਿੰਨ ਕਰਦੀ ਹੈ, ਅਤੇ ਹਰ ਸਾਈਟ ਲਈ ਰੱਖੀ ਕੁੰਜੀ ਵਾਲੀ authentication remote pre-share ਕਾਫ਼ੀ ਹੈ। ਮਿਲਾਨ ਨੂੰ ਓਨਾ ਹੀ ਖ਼ਾਸ ਰੱਖੋ ਜਿੰਨਾ ਪੀਅਰ ਸੂਚੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਚੋਣ ਕ੍ਰਮ ਵਿੱਚ ਉੱਪਰ ਵਾਲਾ ਓਵਰਲੈਪ ਕਰਨ ਵਾਲਾ ਵਾਈਲਡਕਾਰਡ ਸ਼ਾਖਾ ਦਾ ਟਰੈਫ਼ਿਕ ਗ਼ਲਤ ਪ੍ਰੋਫ਼ਾਈਲ ਵਿੱਚ ਖਿੱਚ ਸਕਦਾ ਹੈ।

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

ਫਾਰਵਰਡਿੰਗ ਅਤੇ ਤਰਜਮੇ ਨੂੰ ਵੀ ਉਹੀ ਵੰਡ ਚਾਹੀਦੀ ਹੈ

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

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

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

ਕ੍ਰਾਸ ਹੋਈ ਨੀਤੀ ਨੂੰ ਉਜਾਗਰ ਕਰਨ ਵਾਲੇ ਕੇਸ

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

ਫਿਰ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਨਹੀਂ, ਡੇਟਾ ਪਲੇਨ ਪੁਸ਼ਟੀ ਕਰੋ। show crypto ikev2 sa ਅਤੇ show crypto ipsec sa ਦੱਸਦੇ ਹਨ ਕਿ ਕਿਹੜੀ ਪ੍ਰੋਫ਼ਾਈਲ ਅਤੇ ਕਿਹੜੇ ਸਿਲੈਕਟਰ ਹਰ ਫ਼ਲੋ ਲੈ ਗਏ, ਜਦੋਂ ਕਿ show ip nat translations ਅਤੇ ਟਨਲ ਕਾਊਂਟਰ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਵਾਪਸੀ ਮਾਰਗ ਅਤੇ ਛੋਟ ਸੱਚਮੁੱਚ ਮਿਲੇ ਜਾਂ ਨਹੀਂ। ਟਨਲ ਇੰਟਰਫ਼ੇਸ 'ਤੇ tracer ਜਾਂ ਪੈਕਟ ਕੈਪਚਰ ਚੱਕਰ ਬੰਦ ਕਰਦਾ ਹੈ।

ਹਰ ਨਤੀਜੇ ਦੇ ਕੋਲ ਦੇਖੀ ਗਈ ਪਛਾਣ, ਪੂਲ ਦਾ ਪਤਾ ਅਤੇ ਚੁਣੀ ਨੀਤੀ ਲਿਖੋ। ਹਰ ਕੇਸ ਠੀਕ ਇੱਕ ਰਿਕਾਰਡ ਨਾਲ ਮੇਲ ਖਾਵੇ ਅਤੇ ਕਿਸੇ ਵੀ ਕੇਸ ਨੂੰ ਪਾਸ ਹੋਣ ਲਈ ਅਸਥਾਈ ਛੋਟ ਨਾ ਲੱਗੇ ਤਾਂ ਦੌਰ ਪੂਰਾ ਹੁੰਦਾ ਹੈ।