EC2 ਲਈ ਸਿਰਫ਼-VPN ਨਿਯਮ: ਜੁੜਿਆ ਹਰ ਸੁਰੱਖਿਆ ਗਰੁੱਪ ਸਹਿਮਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ

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

ਨਿਯਮ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਸੇਵਾ ਲਿਖੋ

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

ਅਨੁਵਾਦ ਅਤੇ ਰੂਟਿੰਗ ਸ਼ਾਮਲ ਹੋਣ 'ਤੇ ਇਹ ਦੋਵੇਂ ਪਤੇ ਲੋਕਾਂ ਦੀ ਉਮੀਦ ਨਾਲੋਂ ਵੱਧ ਵਾਰ ਵੱਖਰੇ ਹੋ ਜਾਂਦੇ ਹਨ।

ਤਿੰਨ ਸਰੋਤ ਮਾਡਲ, ਤਿੰਨ ਵੱਖਰੇ ਨਿਯਮ

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

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

ਹਰ ਜੁੜੇ ਗਰੁੱਪ ਵਿੱਚ ਸੰਘ ਪੜ੍ਹੋ

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

AWS ਨਿਯਮ ਹਵਾਲਾ ਸੁਰੱਖਿਆ ਗਰੁੱਪਾਂ ਨੂੰ ਸਿਰਫ਼-ਆਗਿਆ ਦੇਣ ਵਾਲੇ ਵਜੋਂ ਦੱਸਦਾ ਹੈ ਅਤੇ ਕਹਿੰਦਾ ਹੈ ਕਿ ਸਾਰੇ ਜੁੜੇ ਗਰੁੱਪਾਂ ਦੇ ਨਿਯਮ ਇਕੱਠੇ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਇਹੀ ਇਸ ਅਸਫ਼ਲਤਾ ਪਿੱਛੇ ਪੂਰਾ ਤੰਤਰ ਹੈ।

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

ਇਨਕਾਰ ਦੀ ਕੰਧ ਨਾਲ ਜਵਾਬ ਨਾ ਦਿਓ

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

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

ਨਵੇਂ ਸੈਸ਼ਨ ਨਾਲ ਟੈਸਟ ਕਰੋ ਅਤੇ ਅੰਦਰ ਆਉਣ ਦਾ ਰਾਹ ਰੱਖੋ

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

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