AWS Client VPN: ਲੌਗਇਨ ਸਫਲ ਹੁੰਦਾ ਹੈ, ਪਰ ਸਬਨੈੱਟ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ

ਤੁਹਾਡਾ ਕਲਾਇੰਟ Connected ਦਿਖਾਉਂਦਾ ਹੈ, ਸਰਟੀਫਿਕੇਟ ਵੈਧ ਹੈ, ਅਤੇ ਇੰਟਰਾਨੈੱਟ ਪੰਨਾ ਫਿਰ ਵੀ ਸਮਾਂ ਖਤਮ ਹੋਣ ’ਤੇ ਰੁਕਦਾ ਹੈ। ਇਹ ਅੰਤਰ ਲਗਭਗ ਕਦੇ ਵੀ ਪ੍ਰਮਾਣਿਕਤਾ ਨਹੀਂ ਹੁੰਦਾ। AWS Client VPN ਲੌਗਇਨ ਤੋਂ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਮੰਜ਼ਿਲਾਂ ਨੂੰ ਅਧਿਕਾਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਆਮ ਤੌਰ ’ਤੇ ਦੋ ਕਾਰਨ ਹੁੰਦੇ ਹਨ: ਅਜਿਹਾ ਸਮੂਹ ਮੁੱਲ ਜੋ ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਵੱਲੋਂ ਭੇਜੇ ਮੁੱਲ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ, ਅਤੇ ਵਧੇਰੇ ਖਾਸ ਮੰਜ਼ਿਲ ਨਿਯਮ ਜੋ ਚੌੜੇ ਨਿਯਮ ਨੂੰ ਹਰਾ ਦਿੰਦਾ ਹੈ। ਕਿੱਥੇ ਵੇਖਣਾ ਹੈ ਪਤਾ ਹੋਵੇ ਤਾਂ ਦੋਵੇਂ endpoint ਸੰਰਚਨਾ ਵਿੱਚ ਦਿਸਦੇ ਹਨ।

ਲੌਗਇਨ ਸਫਲ ਹੋਇਆ; ਨਿਯਮ ਮੇਲ ਨਹੀਂ ਖਾਧਾ

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

ਇਹ ਪੁਸ਼ਟੀ ਕਰਕੇ ਸ਼ੁਰੂ ਕਰੋ ਕਿ endpoint ਕੋਲ ਉਹ ਅਧਿਕਾਰ ਨਿਯਮ ਹੈ ਜਿਸ ਦੀ ਮੰਜ਼ਿਲ ਵਿੱਚ ਫੇਲ੍ਹ ਹੋ ਰਿਹਾ ਪਤਾ ਸ਼ਾਮਲ ਹੈ। ਜੇ ਮੇਲ ਖਾਂਦਾ ਨਿਯਮ ਨਹੀਂ ਹੈ, ਤਾਂ ਕਨੈਕਸ਼ਨ ਸਹੀ ਵਿਵਹਾਰ ਕਰ ਰਿਹਾ ਹੈ; ਘਾਟ ਨੀਤੀ ਦੀ ਹੈ।

ਸਮੂਹ ਦਾ ਮੁੱਲ ਅਸਲ ਵਿੱਚ ਕਿੱਥੋਂ ਆਉਂਦਾ ਹੈ

Active Directory ਵਿੱਚ, access-group ਖੇਤਰ ਸਮੂਹ ਦਾ ਪ੍ਰਦਰਸ਼ਨ ਨਾਮ ਨਹੀਂ, ਸਗੋਂ ਉਸ ਦਾ SID ਰੱਖਦਾ ਹੈ। SAML ਫੈਡਰੇਸ਼ਨ ਵਿੱਚ, ਇਹ ਉਹ ਸਮੂਹ ID ਜਾਂ ਨਾਮ ਰੱਖਦਾ ਹੈ ਜੋ ਸੰਰਚਿਤ SAML ਸਮੂਹ ਵਿਸ਼ੇਸ਼ਤਾ ਅਸਲ ਵਿੱਚ ਲੈ ਕੇ ਜਾਂਦੀ ਹੈ। ਮੁੱਲ assertion ਜਾਂ ਡਾਇਰੈਕਟਰੀ ਖੋਜ ਤੋਂ ਕਾਪੀ ਕਰੋ, ਵਿਕੀ ਪੰਨੇ ਤੋਂ ਨਹੀਂ।

IAM ਸਮੂਹ ਇੱਕ ਵੱਖਰਾ ਨਿਯੰਤਰਣ ਤਲ ਹੈ। Client VPN endpoint ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ IAM ਸਮੂਹ ਨੂੰ ਵਰਤੋਂਕਾਰ ਦਾ VPN ਸਮੂਹ ਨਹੀਂ ਬਣਾਉਂਦੀ, ਅਤੇ access-group ਖੇਤਰ ਵਿੱਚ IAM ਸਮੂਹ ਦਾ ਨਾਮ ਪੇਸਟ ਕਰਨ ਨਾਲ ਇਹ AD SID ਜਾਂ SAML ਵਿਸ਼ੇਸ਼ਤਾ ਮੁੱਲ ਵਿੱਚ ਨਹੀਂ ਬਦਲਦਾ।

ਕਿਸੇ ਹੋਰ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਮਿਲਦੇ-ਜੁਲਦੇ ਨਾਮ ਦਾ ਸਮੂਹ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। endpoint ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਵਿਧੀ ਅਤੇ ਉਸੇ ਸਿਸਟਮ ਵਿੱਚ ਵਰਤੋਂਕਾਰ ਦੀ ਮੈਂਬਰਸ਼ਿਪ ਜਾਂ assertion ਜਾਂਚੋ।

ਸਭ ਤੋਂ ਲੰਬਾ ਪ੍ਰੀਫਿਕਸ ਜਿੱਤਦਾ ਹੈ, 0.0.0.0/0 ਸਮੇਤ

ਅਧਿਕਾਰ ਸਭ ਤੋਂ ਲੰਬੇ ਪ੍ਰੀਫਿਕਸ ਮੇਲ ਦੁਆਰਾ ਮੁਲਾਂਕਣ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਸਾਰੀਆਂ ਮੰਜ਼ਿਲਾਂ ਦਾ ਨਿਯਮ ਪਹਿਲਾਂ ਨਹੀਂ, ਸਗੋਂ ਆਖਰ ਵਿੱਚ ਮੁਲਾਂਕਣ ਹੁੰਦਾ ਹੈ। Engineering ਲਈ 10.46.0.0/16 ਨਿਯਮ ਅਤੇ ਸਾਰਿਆਂ ਲਈ 0.0.0.0/0 ਨਿਯਮ ਸ਼ਾਮਲ ਕਰੋ, ਫਿਰ ਵੀ Engineering ਤੋਂ ਬਾਹਰਲਾ ਵਰਤੋਂਕਾਰ ਚੌੜੇ ਨਿਯਮ ਰਾਹੀਂ 10.46.20.10 ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ।

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

ਤਬਦੀਲੀਆਂ ਨੂੰ ਨਿਆਂਪੂਰਨ ਮੁਲਾਂਕਣ ਲਈ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਵੀ ਚਾਹੀਦਾ ਹੈ। ਨਿਯਮ ਸੋਧਣ ਤੋਂ ਬਾਅਦ ਕਲਾਇੰਟ ਦੁਬਾਰਾ ਜੋੜੋ, ਫਿਰ ਦੁਬਾਰਾ ਟੈਸਟ ਕਰੋ।

ਅਧਿਕਾਰ ਨੂੰ ਡੇਟਾ ਰਾਹ ਤੋਂ ਵੱਖਰਾ ਕਰੋ

ਮੇਲ ਖਾਂਦਾ ਨਿਯਮ ਰਾਹ ਨਹੀਂ ਹੈ. endpoint ਨੂੰ ਜੁੜਿਆ ਸਬਨੈੱਟ ਅਤੇ ਮੰਜ਼ਿਲ ਲਈ ਰੂਟ ਟੇਬਲ ਐਂਟਰੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਟਾਰਗੈਟ ਸਰੋਤ ਦੇ ਸੁਰੱਖਿਆ ਸਮੂਹ ਨੂੰ ਟ੍ਰੈਫਿਕ ਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਵਾਪਸੀ ਟ੍ਰੈਫਿਕ ਅਤੇ DNS ਵੀ ਕੰਮ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ।

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

ਜੇ IP ਪਤਾ ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ ਹੋਸਟਨਾਮ ਨਹੀਂ, ਤਾਂ ਅਧਿਕਾਰ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ resolver ਵੇਖੋ। ਜੇ ਕੋਈ ਰੂਟ ਪਤੇ ਨੂੰ ਨਹੀਂ ਢਕਦਾ, ਤਾਂ ਜੋੜ ਜਾਂ ਰੂਟ ਟੇਬਲ ਠੀਕ ਕਰੋ। ਜੇ ਪੈਕਟ ਆਉਂਦਾ ਹੈ ਅਤੇ ਸੇਵਾ ਇਸ ਨੂੰ ਨਹੀਂ ਮੰਨਦੀ, ਤਾਂ ਅਗਲਾ ਪੜਾਅ ਉਸ ਸੇਵਾ ਦੀ ਨੀਤੀ ਹੈ। ਅਧਿਕਾਰ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਸਾਰੇ ਵਰਤੋਂਕਾਰਾਂ ਤੱਕ ਵਧਾਉਣ ਨਾਲ ਇਹ ਲੁਕ ਜਾਂਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਪਰਤ ਅਸਲ ਵਿੱਚ ਟੁੱਟੀ ਸੀ।

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