Firebird 3 ਦੀ ਵਾਇਰ ਇਨਕ੍ਰਿਪਸ਼ਨ ਅਤੇ VPN ਦੋ ਵੱਖਰੀਆਂ ਹੱਦਾਂ ਹਨ

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

ਦੋ ਹੱਦਾਂ, ਅਤੇ ਉਹ ਇੱਕ-ਦੂਜੇ 'ਤੇ ਓਵਰਲੈਪ ਨਹੀਂ ਹੁੰਦੀਆਂ

VPN ਹੱਦ ਕਲਾਇੰਟ ਅਤੇ ਗੇਟਵੇ ਵਿਚਕਾਰ ਪੈਕਟ ਸੁਰੱਖਿਅਤ ਕਰਦੀ ਹੈ। Firebird ਦੀ ਵਾਇਰ ਇਨਕ੍ਰਿਪਸ਼ਨ ਕਲਾਇੰਟ ਲਾਇਬ੍ਰੇਰੀ ਅਤੇ ਸਰਵਰ ਪ੍ਰਕਿਰਿਆ ਵਿਚਕਾਰ ਡੇਟਾਬੇਸ ਪ੍ਰੋਟੋਕੋਲ ਸੁਰੱਖਿਅਤ ਕਰਦੀ ਹੈ। ਦੋਵੇਂ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ ਕੋਈ ਵੀ ਦੂਜੇ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ।

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

ਪਹਿਲੀ ਹੱਦ: ਲਿਸਨਰ ਕੌਣ ਖੋਲ੍ਹ ਸਕਦਾ ਹੈ

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

ਫਿਰ ਨਕਾਰਾਤਮਕ ਗੱਲ ਸਾਬਤ ਕਰੋ। ਜਿਸ ਬਾਹਰੀ ਮਾਰਗ ਨੂੰ ਰੱਦ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਉਹ ਰੱਦ ਹੀ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਟਨਲ ਖੋਲ੍ਹਣਾ Firebird ਲਿਸਨਰ ਨੂੰ ਆਪਣੇ ਆਪ ਸੀਮਿਤ ਨਹੀਂ ਕਰਦਾ।

ਦੂਜੀ ਹੱਦ: Firebird ਕੀ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ

Firebird 3 ਨੇ ਵਾਇਰ-ਇਨਕ੍ਰਿਪਸ਼ਨ ਢਾਂਚਾ ਪੇਸ਼ ਕੀਤਾ ਜਿਸ ਵਿੱਚ ਸਰਵਰ ਨੀਤੀ ਅਯੋਗ, ਸਮਰੱਥ ਜਾਂ ਲਾਜ਼ਮੀ ਹੋ ਸਕਦੀ ਹੈ। ਨੀਤੀ ਘੱਟੋ-ਘੱਟ ਪੱਧਰ ਤੈਅ ਕਰਦੀ ਹੈ। ਅਸਲ ਸੈਸ਼ਨ ਅਜੇ ਵੀ ਉਸ ਕਲਾਇੰਟ ਲਾਇਬ੍ਰੇਰੀ 'ਤੇ ਨਿਰਭਰ ਹੈ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਲੋਡ ਕਰਦੀ ਹੈ ਅਤੇ ਉਨ੍ਹਾਂ ਪਲੱਗਇਨਾਂ 'ਤੇ ਜਿਨ੍ਹਾਂ ਦਾ ਦੋਵੇਂ ਧਿਰਾਂ ਸਮਰਥਨ ਕਰਦੀਆਂ ਹਨ।

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

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

Legacy_Auth ਦਾ ਜਾਲ

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

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

ਉਸ ਕਨੈਕਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰੋ ਜੋ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ

ਉਸ ਬਿਲਡ 'ਤੇ ਜੋ ਸੰਦਰਭ ਵੇਰੀਏਬਲ ਦਿੰਦਾ ਹੈ, ਇਹ ਕਿਊਰੀ ਮੌਜੂਦਾ ਕਨੈਕਸ਼ਨ ਦੀ ਇਨਕ੍ਰਿਪਸ਼ਨ ਸਥਿਤੀ ਦੱਸਦੀ ਹੈ:

SELECT RDB$GET_CONTEXT('SYSTEM', 'WIRE_ENCRYPTED')
FROM RDB$DATABASE;

ਇਸਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਆਪਣੇ ਕਨੈਕਸ਼ਨ ਰਾਹੀਂ ਚਲਾਓ, ਉਸੇ ਸਰਵਰ 'ਤੇ ਪ੍ਰਸ਼ਾਸਕ ਸੈਸ਼ਨ ਰਾਹੀਂ ਨਹੀਂ। ਇਨਕ੍ਰਿਪਟਿਡ ਪ੍ਰਸ਼ਾਸਕ ਕਨੈਕਸ਼ਨ ਕਿਸੇ ਹੋਰ ਕਲਾਇੰਟ ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਸੈਸ਼ਨ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ, ਅਤੇ ਵੇਰੀਏਬਲ ਦਾ ਸਮਰਥਨ ਨਾ ਕਰਨ ਵਾਲਾ ਪੁਰਾਣਾ ਬਿਲਡ ਇਨਕ੍ਰਿਪਸ਼ਨ ਬੰਦ ਹੋਣ ਦਾ ਸਬੂਤ ਨਹੀਂ ਹੈ।

ਕਲਾਇੰਟ ਲਾਇਬ੍ਰੇਰੀ ਦਾ ਸੰਸਕਰਣ, ਸਰਵਰ ਬਿਲਡ ਅਤੇ ਨਤੀਜਾ ਇਕੱਠੇ ਦਰਜ ਕਰੋ, ਕਿਉਂਕਿ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਇਕੱਲਾ ਪੜ੍ਹਨਯੋਗ ਨਹੀਂ ਹੈ।

ਅਨੁਮਤੀਆਂ ਅਤੇ ਅਪਗ੍ਰੇਡ ਮਾਰਗ

ਸਰੋਤ ਸੀਮਿਤ ਕਰਨਾ ਅਤੇ ਆਵਾਜਾਈ ਇਨਕ੍ਰਿਪਟ ਕਰਨਾ ਪ੍ਰਮਾਣਿਕਤਾ ਜਾਂ ਘੱਟੋ-ਘੱਟ-ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਅਨੁਮਤੀਆਂ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦੇ। ਆਮ ਡੇਟਾਬੇਸ ਵਰਤੋਂਕਾਰ ਦੀਆਂ ਉਨ੍ਹਾਂ ਵਸਤੂਆਂ 'ਤੇ ਅਨੁਮਤੀਆਂ ਜਾਂਚੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਉਹ ਸੱਚਮੁੱਚ ਛੂਹਦਾ ਹੈ।

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