VPC ਰਿਮੋਟ ਐਕਸੈਸ ਸਵੀਕਾਰ ਕਰਨ ਲਈ ਇਨਕਾਰ ਟੈਸਟ ਲੋੜੀਂਦੇ ਹਨ

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

ਟੈਸਟਾਂ ਲਈ ਵੱਖਰੇ ਖਾਤੇ ਵਰਤੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਲੇਬਲ ਕਰੋ ਕਿ ਕੋਈ ਟੈਸਟ ਪਛਾਣ ਨੂੰ ਅਸਲ ਅਪਵਾਦ ਨਾ ਸਮਝੇ।

ਸੀਮਾ ਨੂੰ ਉਮੀਦ ਕੀਤੇ ਨਤੀਜਿਆਂ ਵਜੋਂ ਲਿਖੋ

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

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

ਮਾਰਗ ਮਨਜ਼ੂਰੀ ਨਹੀਂ ਹੈ

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

ਇਸੇ ਲਈ ਇਨਕਾਰ ਟੈਸਟ ਸਰਵਰ ਪਾਸੇ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦੇ ਹਨ: ਉਹ ਨਤੀਜੇ ਕਲਾਇੰਟ ਸੋਧ ਕੇ ਬਦਲੇ ਨਹੀਂ ਜਾ ਸਕਦੇ।

ਨਿਯੰਤਰਣ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਸਰੋਤ ਵੇਖਦਾ ਹੈ?

ਨਿਯੰਤਰਣ ਜਿਸ ਸਰੋਤ ਪਤੇ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ ਉਹ ਗੇਟਵੇ ਦੀ ਬਣਾਵਟ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। EC2 ਉੱਤੇ ਹੋਸਟ ਕੀਤਾ ਗੇਟਵੇ ਰਾਊਟ ਕੀਤਾ ਪੂਲ ਅੱਗੇ ਭੇਜ ਸਕਦਾ ਹੈ, ਉਸਨੂੰ ਆਪਣੇ ਪਤੇ ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ NAT ਤੋਂ ਬਾਅਦ ਵੱਖਰਾ ਪਤਾ ਪੇਸ਼ ਕਰ ਸਕਦਾ ਹੈ; ਪ੍ਰਬੰਧਿਤ Client VPN ਸਬਨੈੱਟ ਨਾਲ ਜੁੜਦਾ ਹੈ ਅਤੇ ਆਪਣਾ ਮਾਡਲ ਅਪਣਾਉਂਦਾ ਹੈ। ਸੁਰੱਖਿਆ ਸਮੂਹ ਅਤੇ ਨੈੱਟਵਰਕ ACL ਉਸ ਪ੍ਰਕਿਰਿਆ ਤੋਂ ਬਾਅਦ ਆਉਣ ਵਾਲੀ ਚੀਜ਼ ਵੇਖਦੇ ਹਨ। ਗਲਤ ਸਰੋਤ ਧਾਰਨਾ ਸਾਹਮਣੇ ਨਿਯਮ ਦੀ ਜਾਂਚ ਕਰਨਾ ਸਹੀ ਦਿਸਣ ਵਾਲੀ ਅਤੇ ਗਲਤ ਟ੍ਰੈਫਿਕ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲੀ ਸੀਮਾ ਬਣਾਉਣ ਦਾ ਆਮ ਤਰੀਕਾ ਹੈ।

ਹਰ ਨਤੀਜੇ ਨੂੰ ਸਭ ਤੋਂ ਛੋਟੀ ਲਾਭਦਾਇਕ ਘਟਨਾ ਨਾਲ ਜੋੜੋ: ਪਛਾਣ ਅਤੇ ਸੈਸ਼ਨ, ਸਰੋਤ, ਕਾਰਵਾਈ, ਸਮਾਂ ਅਤੇ ਫ਼ੈਸਲਾ। CloudTrail API ਕਾਲ, VPC ਫਲੋ ਰਿਕਾਰਡ ਅਤੇ VPN ਸੈਸ਼ਨ ਲੌਗ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਇਕੱਲਾ ਐਪਲੀਕੇਸ਼ਨ ਆਡਿਟ ਨਹੀਂ ਹੈ।

ਪਛਾਣ ਵਾਪਸ ਲਵੋ ਅਤੇ ਦੁਬਾਰਾ ਪਰਖ ਕਰੋ

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

ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਪੈਚਿੰਗ, ਰਿਕਵਰੀ ਜਾਂ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਦੇ ਜੀਵਨ ਚੱਕਰ ਦੇ ਕੰਮ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ। ਇਹ ਇੱਕ ਤੰਗ ਵਾਅਦੇ ਨੂੰ ਮਾਪਣਯੋਗ ਬਣਾਉਂਦਾ ਹੈ: ਸਹੀ ਲੋਕ ਸਹੀ ਸੇਵਾਵਾਂ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਨੇੜਲੇ ਮਾਰਗ, ਖਾਤੇ ਅਤੇ ਪ੍ਰਬੰਧਨ ਸਤਹਾਂ ਅਨੁਦਾਨ ਤੋਂ ਬਾਹਰ ਰਹਿੰਦੀਆਂ ਹਨ।

ਸਾਰਣੀ ਨੂੰ ਤੈਨਾਤੀ ਨਾਲ ਰੱਖੋ ਅਤੇ ਗੇਟਵੇ ਬਦਲਣ 'ਤੇ ਦੁਬਾਰਾ ਚਲਾਓ। ਟੈਸਟ ਸਸਤੇ ਹਨ; ਉਹਨਾਂ ਪਿੱਛੇ ਦੀਆਂ ਧਾਰਨਾਵਾਂ ਨਹੀਂ।