QGIS PostGIS SSH ਟਨਲ: TLS ਲਈ ਸਰਵਰ ਦਾ ਨਾਮ ਰੱਖੋ

ਟਨਲ ਉੱਪਰ ਆਉਂਦਾ ਹੈ, QGIS ਜੁੜਦਾ ਹੈ, ਅਤੇ ਲੌਗਇਨ ਡੇਟਾਬੇਸ ਹੋਸਟ ਦੀ ਥਾਂ 127.0.0.1 ਦਾ ਨਾਮ ਲੈਣ ਵਾਲੀ ਸਰਟੀਫਿਕੇਟ ਗਲਤੀ ਨਾਲ ਮਰ ਜਾਂਦਾ ਹੈ। ਅਗਲਾ ਲੁਭਾਉਣਾ ਕਦਮ sslmode ਨੂੰ ਢਿੱਲਾ ਕਰਨਾ ਹੈ, ਜੋ ਜਾਂਚ ਨੂੰ ਚੁੱਪ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਉਹੀ ਪਛਾਣ ਦੀ ਗਾਰੰਟੀ ਸੁੱਟ ਦਿੰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਸ਼ੁਰੂ ਤੋਂ ਚਾਹੁੰਦੇ ਸੀ। ਅਸਲ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਸਥਾਨਕ ਪੋਰਟ ਅਤੇ ਸਰਵਰ ਦਾ ਨਾਮ ਇੱਕੋ ਫੀਲਡ ਵਿੱਚ ਰੱਖੇ ਜਾਂਦੇ ਹਨ। libpq ਸੇਵਾ ਐਂਟਰੀ ਉਹਨਾਂ ਨੂੰ ਵੱਖ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਸਾਕਟ ਫਾਰਵਰਡ ਕੀਤੇ ਪੋਰਟ ਵੱਲ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਕਿ TLS ਹਾਲੇ ਵੀ ਸਰਟੀਫਿਕੇਟ ਉੱਤੇ ਛਾਪੇ ਨਾਮ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ।

ਕਲਾਇੰਟ ਕੀ ਸੋਚਦਾ ਹੈ ਕਿ ਉਹ ਕਿਸ ਨਾਲ ਜੁੜ ਰਿਹਾ ਹੈ

sslmode=verify-full ਹੇਠ libpq ਸਰਵਰ ਵੱਲੋਂ ਪੇਸ਼ ਕੀਤੇ ਸਰਟੀਫਿਕੇਟ ਦੀ ਤੁਲਨਾ ਮੰਗੇ ਗਏ ਹੋਸਟ ਨਾਮ ਨਾਲ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਉਹ ਨਾਮ loopback ਪਤਾ ਹੋਵੇ, ਤੁਲਨਾ ਫੇਲ ਹੋ ਜਾਂਦੀ ਹੈ ਭਾਵੇਂ ਸਰਟੀਫਿਕੇਟ ਅਸਲ ਡੇਟਾਬੇਸ ਹੋਸਟ ਲਈ ਵੈਧ ਹੋਵੇ। SSH ਫਾਰਵਰਡ ਇਹ ਬਦਲਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਸਾਕਟ ਬਾਈਟ ਢੋਂਦਾ ਹੈ, ਉਹ ਪਛਾਣ ਨਹੀਂ ਜਿਸਦੀ ਕਲਾਇੰਟ ਨੂੰ ਉਮੀਦ ਰੱਖਣੀ ਚਾਹੀਦੀ ਹੈ। ਇੱਕ ਵਾਰ ਇਹ ਦੋ ਵਿਚਾਰ ਵੱਖ ਹੋ ਜਾਣ, ਤਾਂ ਗਲਤੀ TLS ਖਰਾਬੀ ਵਰਗੀ ਨਹੀਂ ਲੱਗਦੀ।

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

ਫਾਰਵਰਡ ਨੂੰ ਸਿਰਫ਼ loopback ਨਾਲ ਬੰਨ੍ਹੋ

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

ssh -N -L 127.0.0.1:15432:127.0.0.1:5432 [email protected]

ਦੂਜੇ ਕੋਲਨ ਤੋਂ ਬਾਅਦ ਦਾ ਟਿਕਾਣਾ SSH ਸਰਵਰ ਦੇ ਪਾਸਿਓਂ ਹੱਲ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਉਦਾਹਰਨ ਮੰਨਦੀ ਹੈ ਕਿ PostgreSQL ਉਸੇ ਹੋਸਟ ਉੱਤੇ ਹੈ ਜਿਸ ਉੱਤੇ sshd ਹੈ; ਹੋਰ ਮਸ਼ੀਨ ਉੱਤੇ ਡੇਟਾਬੇਸ ਲਈ ਉਹ ਪਤਾ ਅਤੇ ਉਸਦੀਆਂ ਇਜਾਜ਼ਤਾਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਸੈਸ਼ਨ -N ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਤਾਂ ਜੋ ਕੋਈ ਸ਼ੈੱਲ ਨਾ ਖੁੱਲ੍ਹੇ, ਹੋਸਟ-ਕੁੰਜੀ ਪੁਸ਼ਟੀ ਨੂੰ ਹੱਥ ਨਾ ਲਾਓ, ਅਤੇ QGIS ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਰੋਤਾ ਦਿਸ ਰਿਹਾ ਹੈ। ਜੇ ਪੋਰਟ ਪਹਿਲਾਂ ਹੀ ਵਰਤੋਂ ਵਿੱਚ ਹੈ, ਤਾਂ ਫਾਰਵਰਡ ਕੁਐਰੀ ਵੇਲੇ ਨਹੀਂ, ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ ਫੇਲ ਹੁੰਦਾ ਹੈ।

ਨਾਮ ਅਤੇ ਸਾਕਟ ਨੂੰ ਇੱਕੋ ਸੇਵਾ ਐਂਟਰੀ ਵਿੱਚ ਰੱਖੋ

ਸੇਵਾ ਫਾਈਲ ਇੱਕੋ ਕਨੈਕਸ਼ਨ ਨੂੰ ਪੁਸ਼ਟੀ ਨਾਮ ਅਤੇ ਵੱਖਰਾ ਸਾਕਟ ਟਿਕਾਣਾ ਢੋਣ ਦਿੰਦੀ ਹੈ। ਐਂਟਰੀ ਉੱਥੇ ਸੰਭਾਲੋ ਜਿੱਥੇ libpq ਸੇਵਾਵਾਂ ਲੱਭਦਾ ਹੈ, ਜਾਂ PGSERVICEFILE ਨੂੰ ਉਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰੋ।

[gis-via-ssh]
host=db.geo.example
hostaddr=127.0.0.1
port=15432
dbname=gisdb
user=gis_reader
sslmode=verify-full
gssencmode=disable
sslrootcert=/path/to/approved-root.crt

ਇੱਥੇ host ਸਰਟੀਫਿਕੇਟ ਜਾਂਚ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਪਛਾਣ ਰੱਖਦਾ ਹੈ ਜਦੋਂ ਕਿ hostaddr ਪੈਕਟ ਫਾਰਵਰਡ ਕੀਤੇ loopback ਪੋਰਟ ਉੱਤੇ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਇਹ ਬੰਦੋਬਸਤ ਕੰਮ ਕਰੇ ਇਸ ਲਈ ਦੋਵੇਂ ਜ਼ਰੂਰੀ ਹਨ। gssencmode=disable ਉਹਨਾਂ ਬਿਲਡਾਂ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜੋ ਨਹੀਂ ਤਾਂ ਪਹਿਲਾਂ GSSAPI ਐਨਕ੍ਰਿਪਸ਼ਨ ਉੱਤੇ ਗੱਲਬਾਤ ਕਰਦੇ, ਕਿਉਂਕਿ ਉਹ ਰਾਹ ਹੁਣੇ ਸੈੱਟ ਕੀਤੀਆਂ TLS ਸੈਟਿੰਗਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ। QGIS ਦੇ PostgreSQL ਕਨੈਕਸ਼ਨ ਡਾਇਲਾਗ ਤੋਂ ਨਾਮ ਰਾਹੀਂ ਸੇਵਾ ਦਾ ਹਵਾਲਾ ਦਿਓ ਅਤੇ ਪਾਸਵਰਡ ਆਮ ਪ੍ਰੋਂਪਟ ਰਾਹੀਂ ਦਿਓ, ਸਾਂਝੀ ਫਾਈਲ ਦੇ ਅੰਦਰ ਨਹੀਂ। ਉੱਪਰ ਦਿੱਤੇ ਨਾਮ ਅਤੇ ਪਾਥ ਪਲੇਸਹੋਲਡਰ ਹਨ; ਉਹਨਾਂ ਨੂੰ ਆਪਣੇ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਮੁੱਲਾਂ ਨਾਲ ਬਦਲੋ।

ਟਨਲ ਤੋਂ ਬਾਅਦ PostgreSQL ਹਾਲੇ ਵੀ ਕੀ ਜਾਂਚਦਾ ਹੈ

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

psql "service=gis-via-ssh" -c "select inet_server_addr(), current_user"

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