GET VPN ਮੈਂਬਰਾਂ ਲਈ ਸਥਿਰ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਸਰੋਤ ਚੁਣੋ

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

ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਪਤਾ ਕੀ ਪਛਾਣਦਾ ਹੈ

GDOI ਤੈਨਾਤੀ ਵਿੱਚ ਗਰੁੱਪ ਮੈਂਬਰ ਕੁੰਜੀ ਸਰਵਰ ਉੱਤੇ ਰਜਿਸਟਰ ਹੁੰਦਾ ਹੈ ਅਤੇ ਉਸ ਤੋਂ ਗਰੁੱਪ ਨੀਤੀ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ। ਸਰਵਰ ਜੋ ਪਤਾ ਦਰਜ ਕਰਦਾ ਹੈ ਉਹੀ ਉਸ ਗੱਲਬਾਤ ਲਈ ਮੈਂਬਰ ਦੀ ਪਛਾਣ ਹੈ।

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

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

ਲੂਪਬੈਕ ਆਪਣੇ ਰੂਟ ਜਿੰਨਾ ਹੀ ਚੰਗਾ ਹੈ

ਲੂਪਬੈਕ ਮੈਂਬਰ ਨੂੰ ਤਾਰਕਿਕ ਪਤਾ ਦਿੰਦਾ ਹੈ ਜੋ ਇੱਕ ਭੌਤਿਕ ਅਪਲਿੰਕ ਫੇਲ੍ਹ ਹੋਣ 'ਤੇ ਵੀ ਨਹੀਂ ਗੁੰਮਦਾ। ਕੁੰਜੀ ਸਰਵਰ ਤੱਕ ਕਈ ਰਾਹਾਂ ਵਾਲੇ ਰਾਊਟਰ ਉੱਤੇ ਇਹ ਅਸਲ ਲਾਭ ਹੈ।

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

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

ਕੰਟਰੋਲ ਅਤੇ ਸੁਰੱਖਿਅਤ ਟ੍ਰੈਫਿਕ ਵੱਖ ਰੱਖੋ

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

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

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

ਸੰਧੀ ਦੌਰਾਨ ਪਛਾਣ ਜਾਂਚੋ

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

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

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

ਸਥਿਰ ਸਰੋਤ ਕੀ ਠੀਕ ਨਹੀਂ ਕਰਦਾ

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

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

ਕੰਮ ਦਾ ਕ੍ਰਮ: ਕੰਟਰੋਲ ਰਾਹ ਦਾ ਨਾਮ ਦਿਓ, ਦੋਵਾਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਰੂਟ ਵਾਲਾ ਪਤਾ ਚੁਣੋ, ਕੁੰਜੀ ਸਰਵਰ ਦਾ ਦ੍ਰਿਸ਼ ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ ਸੁਰੱਖਿਅਤ ਟ੍ਰੈਫਿਕ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਪਰਖੋ। ਜੇ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਅਜੇ ਵੀ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ ਤਾਂ ਲੂਪਬੈਕ ਕਦੇ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ।