VPN ਲਈ ਕਲਾਊਡ ਸੁਰੱਖਿਆ ਸਮੂਹ: ਸੁਣਨ ਵਾਲਾ ਖੋਲ੍ਹੋ, ਸਭ ਕੁਝ ਨਹੀਂ

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

ਨਿਯਮ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਨਾਮ ਦੱਸੋ

ਨਿਯਮ ਭਾਵ ਪ੍ਰੋਟੋਕੋਲ, ਪੋਰਟ ਰੇਂਜ ਅਤੇ ਸਰੋਤ। WireGuard UDP 'ਤੇ ਸੁਣਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ 51820. OpenVPN ਆਮ ਤੌਰ 'ਤੇ UDP ਜਾਂ TCP 1194 ਹੁੰਦਾ ਹੈ, ਇਹ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਕਿਵੇਂ ਸੰਰਚਿਤ ਹੈ। IPsec ਨੂੰ UDP 500 ਅਤੇ 4500 'ਤੇ IKE ਵਟਾਂਦਰਾ ਅਤੇ ਨਾਲ ਹੀ ESP ਪ੍ਰੋਟੋਕੋਲ ਵੀ ਚਾਹੀਦਾ ਹੈ, ਜੋ ਪੋਰਟ ਨਹੀਂ ਬਲਕਿ ਪ੍ਰੋਟੋਕੋਲ ਨੰਬਰ ਹੈ। ਬਾਕੀ ਨਿਯਮ TCP ਹਨ ਇਸ ਲਈ TCP ਮੰਨ ਲੈਣਾ ਉਹ ਨਿਯਮ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਸਹੀ ਦਿਸਦਾ ਹੈ ਪਰ ਕਿਸੇ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ।

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

ਸਰੋਤ ਨੂੰ ਪੂਰੇ ਇੰਟਰਨੈੱਟ ਦੀ ਥਾਂ ਉਸ ਕਲਾਇਟ ਰੇਂਜ ਤੱਕ ਸੀਮਿਤ ਕਰੋ ਜਿਸ ਦੀ ਡਿਜ਼ਾਈਨ ਆਗਿਆ ਦਿੰਦਾ ਹੈ।

ਸੁਰੱਖਿਆ ਸਮੂਹ ਸਟੇਟਫੁਲ ਹਨ; ਸਬਨੈੱਟ ACL ਨਹੀਂ

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

ਚੱਲ ਰਹੇ ਐਂਡਪੁਆਇੰਟ ਨਾਲ ਕਿਹੜੀ ਨੀਤੀ ਜੁੜੀ ਹੈ ਇਹ ਵੀ ਪੱਕਾ ਕਰੋ, ਕਿਉਂਕਿ ਇੱਕ ਇੰਸਟੈਂਸ ਵਿੱਚ ਇੱਕ ਤੋਂ ਵੱਧ ਸਮੂਹ ਹੋ ਸਕਦੇ ਹਨ ਅਤੇ ਨਾ ਜੁੜੇ ਸਮੂਹ ਦਾ ਨਿਯਮ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।

ਪ੍ਰਭਾਵੀ ਨੀਤੀ ਜੁੜੇ ਹੋਇਆਂ ਦਾ ਸੰਘ ਹੈ, ਤੁਹਾਡੇ ਦੁਆਰਾ ਸੰਪਾਦਿਤ ਫਾਈਲ ਨਹੀਂ।

ਹੋਸਟ ਫਾਇਰਵਾਲ ਵੱਖਰੀ ਸੀਮਾ ਹੈ

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

ਜੇ ਹੋਸਟ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਦਾ ਫਾਇਰਵਾਲ ਫਰੰਟਐਂਡ ਵਰਤਦਾ ਹੈ, ਤਾਂ ਪ੍ਰੋਫਾਈਲ ਨਾਮ ਦੀ ਥਾਂ ਅਧਾਰ ਨਿਯਮਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਕਿਉਂਕਿ ਪ੍ਰੋਫਾਈਲ ਸਰਗਰਮ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਪੋਰਟ ਬੰਦ ਹੋਵੇ।

ਇੰਟਰਫੇਸ 'ਤੇ ਕੈਪਚਰ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਸੀਮਾ ਨੇ ਪੈਕਟ ਡੇਗਿਆ।

ਸੁਣਨ ਵਾਲੇ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣਾ ਕਲਾਇਟਾਂ ਨੂੰ ਰੂਟ ਕਰਨਾ ਨਹੀਂ ਹੈ

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

ਇੱਥੇ ਹੀ ਕੰਮ ਕਰਨ ਵਾਲਾ ਹੈਂਡਸ਼ੇਕ ਅਤੇ ਟੁੱਟਿਆ ਡੇਟਾ ਮਾਰਗ ਵੱਖ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇਸ ਲਈ ਟਨਲ ਦੀ ਸਥਿਤੀ ਤੰਦਰੁਸਤ ਦਿਸ ਸਕਦੀ ਹੈ ਜਦੋਂ ਕਿ ਕੁਝ ਵੀ ਲੋਡ ਨਹੀਂ ਹੁੰਦਾ।

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

ਵਾਪਸੀ ਦਾ ਰਾਹ ਰੱਖੋ, ਫਿਰ ਨਿਯਮ ਤੰਗ ਕਰੋ

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

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

ਜੁੜਾਅ ਦਾ ਵੀ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰੋ, ਨਹੀਂ ਤਾਂ ਬਦਲਵਾਂ ਇੰਟਰਫੇਸ ਚੁੱਪਚਾਪ ਨੀਤੀ ਗੁਆ ਦੇਵੇਗਾ।