VPN ਚਾਲੂ ਹੋਣ ’ਤੇ ਕਲਾਊਡ ਫਾਇਰਵਾਲ ਕਿਹੜਾ ਪਤਾ ਦੇਖਦਾ ਹੈ
ਪੂਰਾ ਟਨਲ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਨੂੰ ਦਿਖਣ ਵਾਲਾ ਸਰੋਤ ਪਤਾ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਮਨਜ਼ੂਰੀ ਸੂਚੀ, ਨਿੱਜੀ ਮਾਰਗ ਜਾਂ ਸਪਲਿਟ ਟਨਲ ਬਦਲੋ, ਪ੍ਰਮਾਣ-ਪੱਤਰ ਨਹੀਂ।
VPN ਜੁੜਨ ਤੋਂ ਪਹਿਲਾਂ ਕੰਮ ਕਰਨ ਵਾਲਾ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਫੇਲ੍ਹ ਹੋਣ ਵਾਲਾ ਡੇਟਾਬੇਸ ਘੱਟ ਹੀ ਪ੍ਰਮਾਣ ਦੀ ਸਮੱਸਿਆ ਹੁੰਦਾ ਹੈ। ਕਲਾਊਡ ਫਾਇਰਵਾਲ ਸਰੋਤ ਪਤਿਆਂ ਦਾ ਮੇਲ ਕਰਦੇ ਹਨ, ਅਤੇ ਪੂਰਾ ਟਨਲ ਉਹੀ ਪਤਾ ਬਦਲ ਦਿੰਦਾ ਹੈ ਜਿਸਦਾ ਉਹ ਮੇਲ ਕਰ ਰਹੇ ਸਨ। ਤੁਹਾਡਾ ਲੈਪਟਾਪ ਕੀ ਭੇਜਦਾ ਹੈ ਅਤੇ ਸਰਵਰ ਕੀ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਵਿਚਕਾਰਲਾ ਫਰਕ ਹੀ ਪੂਰੀ ਬੱਗ ਹੈ, ਅਤੇ ਇਹ ਇੱਕ ਹੀ ਕਦਮ ਵਿੱਚ ਮਾਪਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਸਰੋਤ ਪਤਾ ਕੀ ਬਣਦਾ ਹੈ
ਪੂਰੇ ਟਨਲ ਵਿੱਚ ਹਰ ਪੈਕੇਟ VPN ਗੇਟਵੇ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਸਰਵਰ ਤੁਹਾਡੇ ਘਰ ਦੇ ਕਨੈਕਸ਼ਨ ਦੀ ਥਾਂ ਗੇਟਵੇ ਦਾ ਆਊਟਬਾਊਂਡ ਪਤਾ ਦੇਖਦਾ ਹੈ। ਜੇ ਮਾਰਗ ਵਿੱਚ ਫਾਰਵਰਡ ਪ੍ਰੌਕਸੀ ਹੈ, ਤਾਂ ਉਸਦਾ ਪਤਾ ਪਹੁੰਚਦਾ ਹੈ। ਦੋਵੇਂ ਜਾਇਜ਼ ਸਰੋਤ ਹਨ, ਅਤੇ ਤੁਹਾਡੇ ਮੂਲ ਨਿਯਮ ਵਾਲਾ ਪਤਾ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਨਹੀਂ।
Azure SQL ਦੇ ਸਰਵਰ-ਪੱਧਰੀ ਅਤੇ ਡੇਟਾਬੇਸ-ਪੱਧਰੀ ਫਾਇਰਵਾਲ ਨਿਯਮ ਉਸ ਕਲਾਇੰਟ ਪਤੇ ਦਾ ਮੇਲ ਕਰਦੇ ਹਨ ਜੋ ਲਾਜ਼ੀਕਲ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਅਤੇ ਪੂਰੇ ਟਨਲ ਤੋਂ ਬਾਅਦ ਉਹੀ ਆਊਟਬਾਊਂਡ ਪਤਾ ਹੁੰਦਾ ਹੈ। ਇੱਕੋ ਪਤੇ ਦੀ ਮਨਜ਼ੂਰੀ ਦੇਣ ਵਾਲਾ AWS ਸੁਰੱਖਿਆ ਸਮੂਹ ਵੀ ਇਸੇ ਤਰ੍ਹਾਂ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ। ਪੈਕੇਟ ਪ੍ਰਮਾਣਿਕਤਾ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਸੁੱਟ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਮਿਲਣ ਵਾਲੀ ਗਲਤੀ ਇਜਾਜ਼ਤ ਦੀ ਸਮੱਸਿਆ ਦੀ ਥਾਂ ਨੈੱਟਵਰਕ ਫੇਲ੍ਹ ਹੋਣ ਵਰਗੀ ਲੱਗਦੀ ਹੈ। ਲੋਕ ਪਾਸਵਰਡ ਰੀਸੈਟ ਕਰਨ ਲੱਗਣ ਦਾ ਕਾਰਨ ਬਿਲਕੁਲ ਇਹੀ ਹੈ।
ਮਨਜ਼ੂਰੀ ਸੂਚੀ ਕਿੱਥੇ ਤੈਅ ਹੁੰਦੀ ਹੈ
ਫੇਲ੍ਹ ਹੋ ਰਹੇ ਮਾਰਗ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਨਿਯਮ ਪੜ੍ਹੋ, ਉਹ ਨਿਯਮ ਨਹੀਂ ਜੋ ਤੁਹਾਨੂੰ ਯਾਦ ਹੈ ਕਿ ਤੁਸੀਂ ਬਣਾਇਆ ਸੀ। ਇਸਦਾ ਦਾਇਰਾ, ਪੋਰਟ, ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ ਇਹ ਕਿ ਕਿਸੇ ਵੀ ਪਛਾਣ ਜਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਇਸਦਾ ਮੁਲਾਂਕਣ ਹੁੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਨੂੰ ਨੋਟ ਕਰੋ।
ਫਿਰ ਤੈਅ ਕਰੋ ਕਿ ਕਿਹੜੀ ਪਰਤ ਇਸ ਫੈਸਲੇ ਦੀ ਜਾਇਜ਼ ਮਾਲਕ ਹੈ। ਪਤੇ ਦਾ ਨਿਯਮ ਦੱਸਦਾ ਹੈ ਕਿ ਟ੍ਰੈਫਿਕ ਕਿੱਥੋਂ ਆਉਂਦਾ ਹੈ। ਨਿੱਜੀ ਐਂਡਪੌਇੰਟ ਦੱਸਦਾ ਹੈ ਕਿ ਸੇਵਾ ਨਿੱਜੀ ਮਾਰਗ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਹੈ ਜਾਂ ਨਹੀਂ। ਸਪਲਿਟ-ਟਨਲ ਅਪਵਾਦ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਮੰਜ਼ਿਲਾਂ ਟਨਲ ਨੂੰ ਬਾਈਪਾਸ ਕਰਦੀਆਂ ਹਨ। ਇਹ ਅਦਲ-ਬਦਲ ਨਹੀਂ ਹੋ ਸਕਦੇ, ਅਤੇ ਟਨਲ ਬਦਲਣ ’ਤੇ ਹਰ ਇੱਕ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ।
ਤਿੰਨ ਮੁਰੰਮਤਾਂ, ਤਿੰਨ ਪਰਤਾਂ
ਹੇਠਾਂ ਦਿੱਤਾ ਹਰ ਵਿਕਲਪ ਵੱਖਰੇ ਕਾਰਨ ਨਾਲ ਪ੍ਰਵਾਹ ਠੀਕ ਕਰਦਾ ਹੈ, ਅਤੇ ਗਲਤ ਚੁਣਨ ’ਤੇ ਅਜਿਹਾ ਕਨੈਕਸ਼ਨ ਬਣਦਾ ਹੈ ਜੋ ਅਗਲੀ ਗੇਟਵੇ ਤਬਦੀਲੀ ਤੱਕ ਕੰਮ ਕਰਦਾ ਹੈ।
| Repair | Layer it changes | What it does not fix |
|---|---|---|
| Add the egress address to the rule | Source address matching | Nothing about routing, and it breaks when the egress moves |
| Use a private endpoint | Whether the service is reached privately | A client that still resolves the public name |
| Add a split-tunnel exception | Which flows bypass the tunnel | An expired credential or a wrong password |
ਆਊਟਬਾਊਂਡ ਪਤਾ ਜੋੜਨਾ ਸਭ ਤੋਂ ਛੋਟੀ ਤਬਦੀਲੀ ਅਤੇ ਸਭ ਤੋਂ ਨਾਜ਼ੁਕ ਹੈ, ਕਿਉਂਕਿ ਨਵਾਂ ਗੇਟਵੇ ਜਾਂ ਵੱਖਰਾ ਖੇਤਰ ਇਸਨੂੰ ਚੁੱਪਚਾਪ ਅਵੈਧ ਕਰ ਦਿੰਦਾ ਹੈ। ਟਨਲ ਦੀ ਪਰਿਭਾਸ਼ਾ ਕੋਲ ਪਤਾ ਦਰਜ ਕਰੋ ਤਾਂ ਜੋ ਦੋਵੇਂ ਇਕੱਠੇ ਚੱਲਣ। ਅਸਥਾਈ ਚੌੜੀ ਰੇਂਜ ਇੱਕ ਨਿਦਾਨ ਹੈ, ਮੁਰੰਮਤ ਨਹੀਂ; ਇਸਨੂੰ ਉਵੇਂ ਹੀ ਛੱਡਣਾ ਹੀ ਅੰਦਰੂਨੀ ਸੇਵਾਵਾਂ ਦੇ ਖੁੱਲ੍ਹੇ ਰਹਿਣ ਦਾ ਰਾਹ ਹੈ।
ਪ੍ਰਬੰਧਿਤ ਪਲੇਟਫਾਰਮ ਟਨਲ ਵਿੱਚ ਕਿਉਂ ਸ਼ਾਮਲ ਨਹੀਂ ਹੋ ਸਕਦਾ
Heroku, AppHarbor ਜਾਂ CloudBees ਵਰਗੇ ਐਪਲੀਕੇਸ਼ਨ ਪਲੇਟਫਾਰਮ ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਅਜਿਹੇ ਵਾਤਾਵਰਣ ਵਿੱਚ ਚਲਾਉਂਦੇ ਹਨ ਜਿੱਥੇ tun ਜਾਂ tap ਡਿਵਾਈਸ ਨਹੀਂ ਹੈ ਅਤੇ ਇੱਕ ਬਣਾਉਣ ਦਾ ਅਧਿਕਾਰ ਵੀ ਨਹੀਂ। ਉਨ੍ਹਾਂ ਦਾ ਇਨਬਾਊਂਡ ਮਾਡਲ HTTP ਹੈ, ਕੋਈ ਵੀ ਸੁਣਨ ਵਾਲਾ ਸੌਕਟ ਨਹੀਂ। VPN ਬਾਇਨਰੀ ਲਿਆਉਣ ਵਾਲਾ buildpack ਵੀ ਇੰਟਰਫੇਸ ਰੱਖਣ ਦੀ ਥਾਂ ਨਹੀਂ ਲੱਭਦਾ। ਕੰਮ ਕਰਨ ਵਾਲੇ ਨਮੂਨੇ ਹਨ ਡੇਟਾਬੇਸ ਵੱਲੋਂ ਮਨਜ਼ੂਰ ਕੀਤਾ ਜਾ ਸਕਣ ਵਾਲਾ ਸਥਿਰ ਆਊਟਬਾਊਂਡ ਪਤਾ, ਪਲੇਟਫਾਰਮ ਵੱਲੋਂ ਦਿੱਤਾ ਨਿੱਜੀ ਕਨੈਕਸ਼ਨ ਉਤਪਾਦ, ਜਾਂ DMZ ਵਿੱਚ HTTPS ਰਾਹੀਂ ਪਹੁੰਚਣ ਵਾਲੀ ਪ੍ਰੌਕਸੀ।
ਉਹ ਪ੍ਰੌਕਸੀ ਆਪਣੇ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਲੌਗਿੰਗ ਵਾਲਾ ਪਹੁੰਚ ਮਾਰਗ ਹੈ। ਇਹ ਪਲੇਟਫਾਰਮ ਨੂੰ ਤੁਹਾਡੇ VPN ਦਾ ਮੈਂਬਰ ਨਹੀਂ ਬਣਾਉਂਦੀ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਵਰਣਨ ਕਰਨ ਨਾਲ ਅਜਿਹੇ ਨਿਯਮ ਬਣਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਕੋਈ ਜਾਂਚ ਨਹੀਂ ਕਰ ਸਕਦਾ।
ਫੇਲ੍ਹ ਹੋਏ ਕਲਾਇੰਟ ਤੋਂ ਪੁਸ਼ਟੀ ਕਰੋ
ਦੁਬਾਰਾ ਜੁੜੋ ਅਤੇ ਕਲਾਇੰਟ ਦਾ ਠੀਕ ਮਾਰਗ ਦੁਹਰਾਓ। ਸੇਵਾ ਜੋ ਸਰੋਤ ਪਤਾ ਦਰਜ ਕਰਦੀ ਹੈ, ਕਲਾਇੰਟ ਜੋ ਡੇਟਾਬੇਸ ਨਾਮ ਲਈ ਰੂਟ ਚੁਣਦਾ ਹੈ, ਅਤੇ ਅਸਲ ਕਵੈਰੀ ਦਾ ਨਤੀਜਾ ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਜਾਂਚੋ। ਗੇਟਵੇ ਤੋਂ ਕੀਤਾ ਟੈਸਟ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਗੇਟਵੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਜੋ ਕਦੇ ਸ਼ੱਕ ਵਿੱਚ ਨਹੀਂ ਸੀ। ਜੇ ਕਨੈਕਸ਼ਨ ਹੁਣ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦਾ ਹੈ ਅਤੇ ਕਵੈਰੀ ਅਜੇ ਵੀ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਬਚੀ ਸਮੱਸਿਆ ਡੇਟਾਬੇਸ ਇਜਾਜ਼ਤ ਹੈ।
ਟਨਲ ਬਦਲਣ ’ਤੇ ਹਰ ਵਾਰ ਇਨ੍ਹਾਂ ਨਿਯਮਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ। ਬਦਲਿਆ ਗੇਟਵੇ ਜਾਂ ਨਵੀਂ ਆਊਟਬਾਊਂਡ ਰੇਂਜ ਐਪਲੀਕੇਸ਼ਨ ਕੌਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਕੋਈ ਵੀ ਬਦਲਾਅ ਕੀਤੇ ਬਿਨਾਂ ਮਾਰਗ ਤੋੜ ਦਿੰਦੀ ਹੈ।