AWS Client VPN ਦੇ ਨਿਯਮ ਸਰੋਤ 'ਤੇ ਹੁੰਦੇ ਹਨ, ਸਬਨੈੱਟ 'ਤੇ ਨਹੀਂ

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

ਸਬਨੈੱਟ ਦੀ ਥਾਂ ਰੂਟਿੰਗ ਹੈ, ਅਧਿਕਾਰ ਨਹੀਂ

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

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

Client VPN ਸੰਬੰਧ ਗਰੁੱਪ ਹੀ ਉਹ ਹੈਂਡਲ ਹੈ

ਸਬਨੈੱਟ ਨਾਲ ਜੁੜੇ AWS Client VPN endpoint ਲਈ ਦਸਤਾਵੇਜ਼ੀ ਪ੍ਰਬੰਧ ਖਾਸ ਹੈ। ਲੋੜੀਂਦਾ ਸੁਰੱਖਿਆ ਗਰੁੱਪ endpoint ਦੇ ਟੀਚਾ ਨੈੱਟਵਰਕ ਸੰਬੰਧਾਂ 'ਤੇ ਲਾਗੂ ਕਰੋ, ਫਿਰ ਉਸ Client VPN ਗਰੁੱਪ ਨੂੰ ਸਰੋਤ ਵਜੋਂ ਵਰਤ ਕੇ ਸਰੋਤ ਦੇ ਸੁਰੱਖਿਆ ਗਰੁੱਪ ਵਿੱਚ ਲੋੜੀਂਦੇ ਟ੍ਰੈਫਿਕ ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ।

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

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

ਇੱਕ ਸੰਬੰਧ ਗਰੁੱਪ ਕੀ ਵੱਖ ਨਹੀਂ ਕਰ ਸਕਦਾ

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

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

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

ਉਹ ਨਿਯਮ ਹਰ VPN ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਨਕਲ ਨਾ ਕਰੋ

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

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

ਰਾਹ 'ਤੇ ਇੱਕ NAT ਛਾਲ ਹੀ ਧਾਰਨਾ ਤੋੜਨ ਲਈ ਕਾਫ਼ੀ ਹੈ, ਅਤੇ ਨੁਕਸ ਅਜਿਹੇ ਨਿਯਮ ਵਾਂਗ ਦਿਸਦਾ ਹੈ ਜੋ ਮੌਜੂਦ ਹੈ ਪਰ ਕਦੇ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ।

ਪ੍ਰਭਾਵੀ ਸੀਮਾ ਦੀ ਸਮੀਖਿਆ ਕਰੋ

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

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

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