VPN ਉੱਤੇ SQL: ਸਿੱਧਾ ਕਲਾਇੰਟ ਜਾਂ ਅੰਦਰੂਨੀ ਵਰਕਸਟੇਸ਼ਨ?
VPN ਲੈਪਟਾਪ ਤੋਂ ਸਿੱਧਾ SQL ਅਤੇ ਪ੍ਰਬੰਧਿਤ ਵਰਕਸਟੇਸ਼ਨ ਉੱਤੇ SSMS ਦੋ ਵੱਖਰੇ ਭਰੋਸੇ ਦੇ ਰਾਹ ਹਨ। ਹਰ ਇੱਕ ਜੋ ਸਰੋਤ ਪਤਾ ਅਤੇ ਇਜਾਜ਼ਤਾਂ ਬਣਾਉਂਦਾ ਹੈ, ਉਨ੍ਹਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ।
ਟੀਮਾਂ ਆਪਣੇ ਲੈਪਟਾਪਾਂ ਉੱਤੇ SSMS ਚਾਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਤੇਜ਼ ਹੱਲ SQL ਪੋਰਟ ਨੂੰ VPN ਪੂਲ ਉੱਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨਾ ਹੈ। ਹੌਲੀ ਜਵਾਬ ਪੁੱਛਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਪ੍ਰਕਿਰਿਆ ਕਿੱਥੇ ਚੱਲਣੀ ਚਾਹੀਦੀ ਹੈ, ਕਿਉਂਕਿ ਸਿੱਧੀ ਪਹੁੰਚ ਅਤੇ ਅੰਦਰੂਨੀ ਵਰਕਸਟੇਸ਼ਨ ਵੱਖਰੇ ਸਰੋਤ ਪਤੇ, ਐਂਡਪੌਇੰਟ ਭਰੋਸਾ ਅਤੇ ਡੇਟਾ ਰਾਹ ਬਣਾਉਂਦੇ ਹਨ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਆਪਣੇ ਆਪ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਕੱਲੀ VPN ਮੈਂਬਰਸ਼ਿਪ ਕੁਝ ਵੀ ਤੈਅ ਨਹੀਂ ਕਰਦੀ। ਇਜਾਜ਼ਤ ਨਿਯਮ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਡਿਜ਼ਾਈਨਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ।
ਦੋ ਰਾਹ, ਦੋ ਸਰੋਤ ਪਤੇ
ਸਿੱਧੀ ਪਹੁੰਚ ਵਿੱਚ ਲੈਪਟਾਪ ਕਲਾਇੰਟ ਸੰਰਚਨਾ ਲੈ ਕੇ ਚੱਲਦਾ ਹੈ ਅਤੇ ਆਪ ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਦਾ ਹੈ। ਦੂਰਸਥ ਵਰਕਸਟੇਸ਼ਨ ਵਿੱਚ ਲੈਪਟਾਪ ਡੈਸਕਟਾਪ ਸੈਸ਼ਨ ਖੋਲ੍ਹਦਾ ਹੈ, ਅਤੇ ਵਰਕਸਟੇਸ਼ਨ ਆਪਣੇ ਪਤੇ ਤੋਂ SQL ਕਨੈਕਸ਼ਨ ਬਣਾਉਂਦਾ ਹੈ। ਇਸ ਲਈ ਪਹਿਲੇ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਡੇਟਾਬੇਸ VPN ਪੂਲ ਜਾਂ ਅਨੁਵਾਦਿਤ ਗੇਟਵੇ ਦੇਖਦਾ ਹੈ, ਅਤੇ ਦੂਜੇ ਵਿੱਚ ਵਰਕਸਟੇਸ਼ਨ ਦਾ ਪਤਾ ਦੇਖਦਾ ਹੈ। ਇਹੀ ਅੰਤਰ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਫਾਇਰਵਾਲ ਨਿਯਮ ਅਤੇ ਕਿਹੜੀ SQL ਇਜਾਜ਼ਤ ਅਸਲ ਵਿੱਚ ਲਾਗੂ ਹੁੰਦੀ ਹੈ।
ਲੈਪਟਾਪ ਅਜੇ ਵੀ ਦੂਰਸਥ ਸੈਸ਼ਨ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਵਰਕਸਟੇਸ਼ਨ ਵਰਤੋਂਕਾਰ ਪ੍ਰਮਾਣਿਕਤਾ ਜਾਂ ਸੈਸ਼ਨ ਨੀਤੀ ਦਾ ਬਦਲ ਨਹੀਂ ਹੈ।
ਜਾਂਚੋ ਕਿ ਡੇਟਾਬੇਸ ਅਸਲ ਵਿੱਚ ਕੀ ਦੇਖਦਾ ਹੈ
ਸਰੋਤ ਪਤਾ ਮਾਪਣ ਦੀ ਚੀਜ਼ ਹੈ, ਚਿੱਤਰ ਤੋਂ ਅਨੁਮਾਨ ਲਾਉਣ ਦੀ ਨਹੀਂ। ਇਸਨੂੰ ਸਰਗਰਮ ਕਨੈਕਸ਼ਨ ਦੇ ਸਰਵਰ ਪਾਸਿਓਂ ਪੜ੍ਹੋ।
Test-NetConnection sql.example.com -Port 1433
sqlcmd -S tcp:sql.example.com,1433 -N -d appdb -Q "select SUSER_SNAME() as login_name, DB_NAME() as db"ਕਨੈਕਟੀਵਿਟੀ ਟੈਸਟ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਸਰੋਤਾ ਉਸ ਨੈੱਟਵਰਕ ਤੋਂ TCP ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਕਵੈਰੀ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਸੈਸ਼ਨ ਕਿਹੜੇ ਲੌਗਇਨ ਅਤੇ ਡੇਟਾਬੇਸ ਤੱਕ ਪਹੁੰਚਿਆ। ਸਰਵਰ ਵੱਲੋਂ ਦਰਜ ਪਤਾ ਦੇਖਣ ਲਈ ਮੌਜੂਦਾ ਸੈਸ਼ਨ ਲਈ sys.dm_exec_connections ਦੀ ਕਵੈਰੀ ਕਰੋ, ਜੋ ਕਿਸੇ ਵੀ ਅਨੁਵਾਦ ਤੋਂ ਬਾਅਦ ਕਲਾਇੰਟ ਪਤਾ ਵਾਪਸ ਦਿੰਦੀ ਹੈ। ਜੇ ਉਹ ਮੁੱਲ ਲੈਪਟਾਪ ਨਹੀਂ ਸਗੋਂ ਗੇਟਵੇ ਹੈ, ਤਾਂ ਪ੍ਰਤੀ-ਵਰਤੋਂਕਾਰ ਹੋਸਟ ਨਿਯਮ ਡੇਟਾਬੇਸ ਮਸ਼ੀਨ ਉੱਤੇ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਦੇਖਿਆ ਗਿਆ ਮੁੱਲ ਚੁਣੇ ਡਿਜ਼ਾਈਨ ਦੇ ਕੋਲ ਲਿਖੋ, ਕਿਉਂਕਿ ਮੁੜ-ਕਨੈਕਸ਼ਨ ਅਤੇ ਪੂਲ ਬਦਲਾਅ ਇਸਨੂੰ ਹਿਲਾਉਂਦੇ ਹਨ।
ਸਰੋਤਾ ਖੋਲ੍ਹੋ ਅਤੇ ਇਸ ਤੋਂ ਵੱਧ ਕੁਝ ਨਹੀਂ
ਸਿਰਫ਼ ਉਹੀ ਸੇਵਾ ਖੋਲ੍ਹੋ ਜੋ ਤੈਨਾਤੀ ਨੂੰ ਲੋੜੀਂਦੀ ਹੈ। ਜਾਣੀ-ਪਛਾਣੀ 1433 ਡਿਫ਼ਾਲਟ ਇੰਸਟੈਂਸ ਦਾ ਪੋਰਟ ਹੈ, ਸਰਵਵਿਆਪੀ ਸਥਿਰਾਂਕ ਨਹੀਂ।
Get-NetTCPConnection -State Listen -LocalPort 1433ਨਾਮਿਤ ਇੰਸਟੈਂਸ ਅਕਸਰ ਗਤੀਸ਼ੀਲ ਪੋਰਟ ਉੱਤੇ ਸੁਣਦੇ ਹਨ, SQL Server Browser UDP 1434 ਉੱਤੇ ਖੋਜ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਨਿਰਭਰਤਾ ਇੱਕ ਵੱਖਰੀ ਖੁੱਲ੍ਹ ਹੈ ਜਿਸਨੂੰ ਜਾਇਜ਼ ਠਹਿਰਾਉਣਾ ਪੈਂਦਾ ਹੈ। ਇੰਸਟੈਂਸ ਲਈ ਸਥਿਰ ਪੋਰਟ ਪਿੰਨ ਕਰਨ ਨਾਲ Browser ਦੀ ਲੋੜ ਹਟਦੀ ਹੈ ਅਤੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਸਥਿਰ ਹੁੰਦੇ ਹਨ। ਟੈਸਟ ਪਾਸ ਕਰਾਉਣ ਲਈ ਕਲਾਇੰਟ ਵੱਲੋਂ ਪਹਿਲਾਂ ਹੀ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਐਨਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਜਾਂਚਾਂ ਬੰਦ ਕਰਨ ਦੀ ਥਾਂ ਕਾਇਮ ਰੱਖੋ। ਫਿਰ ਪੂਰੇ VPN ਸਮੂਹ ਨੂੰ ਸਰਵਰ ਭੂਮਿਕਾ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਥਾਂ ਵਰਕਲੋਡ ਲਈ ਡੇਟਾਬੇਸ ਭੂਮਿਕਾਵਾਂ ਦਿਓ।
ਮਨਜ਼ੂਰ ਰਾਹ ਅਤੇ ਰੱਦ ਕੀਤਾ ਰਾਹ ਸਾਬਤ ਕਰੋ
ਆਮ ਮਨਜ਼ੂਰ ਵਰਤੋਂਕਾਰ ਵਜੋਂ ਨਵਾਂ ਸੈਸ਼ਨ ਖੋਲ੍ਹੋ ਅਤੇ ਸਰਵਰ ਪਛਾਣ, ਡੇਟਾਬੇਸ ਅਤੇ ਲੋੜੀਂਦੀ ਕਾਰਵਾਈ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਫਿਰ ਬਾਹਰ ਕੱਢਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ: ਨੀਤੀ ਤੋਂ ਬਾਹਰਲੇ ਸਰੋਤ ਜਾਂ ਖਾਤੇ ਨੂੰ ਉਸੇ ਟੈਸਟ ਵਿੱਚ ਫੇਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਵਰਕਸਟੇਸ਼ਨ ਡਿਜ਼ਾਈਨ ਲਈ, ਜਾਂਚੋ ਕਿ ਲੈਪਟਾਪ ਸਿੱਧਾ ਡੇਟਾਬੇਸ ਤੱਕ ਪਹੁੰਚ ਕੇ ਸੀਮਾ ਨਹੀਂ ਟੱਪ ਸਕਦਾ। ਸਿੱਧੀ ਪਹੁੰਚ ਲਈ, ਜਾਂਚੋ ਕਿ ਮੁੜ-ਕਨੈਕਸ਼ਨ ਤੋਂ ਬਾਅਦ ਵੀ ਰਸਤਾ ਅਤੇ ਸਰੋਤ ਨਿਯਮ ਲਾਗੂ ਰਹਿੰਦੇ ਹਨ।
ਕਲਾਇੰਟ ਕਿੱਥੇ ਚੱਲਿਆ, ਡੇਟਾਬੇਸ ਨੇ ਕਿਹੜਾ ਸਰੋਤ ਦੇਖਿਆ ਅਤੇ ਕਿਹੜੇ ਨਿਯਮ ਨੇ ਇਜਾਜ਼ਤ ਦਿੱਤੀ, ਦਰਜ ਕਰੋ। ਇਹੀ ਉਹ ਸਬੂਤ ਹੈ ਜੋ ਅਗਲੀ ਸਮੀਖਿਆ ਮੰਗੇਗੀ।