VPN ਰਾਹੀਂ PostgreSQL: pg_hba ਕਿਹੜਾ ਸਰੋਤ ਪਤਾ ਦੇਖੇਗਾ

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

ਤਿੰਨ ਫੈਸਲੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਮਿਲਾਇਆ ਨਹੀਂ ਜਾਣਾ ਚਾਹੀਦਾ

ਸਰਵਰ ਕਿੱਥੇ ਸੁਣਦਾ ਹੈ ਇਹ ਇੱਕ ਫੈਸਲਾ ਹੈ। ਕਿਹੜਾ ਟ੍ਰੈਫਿਕ ਉਸ ਪਤੇ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ ਇਹ ਦੂਜਾ ਹੈ, ਜੋ ਹੋਸਟ ਫਾਇਰਵਾਲ ਅਤੇ ਇਸ ਦੇ ਸਾਹਮਣੇ ਦੀ ਕੋਈ ਵੀ ਨੈੱਟਵਰਕ ਸੀਮਾ ਲੈਂਦੀ ਹੈ। ਕਿਹੜੀ ਡੇਟਾਬੇਸ ਪਛਾਣ ਕਿਸ ਸਰੋਤ ਤੋਂ ਪ੍ਰਮਾਣਿਤ ਹੋ ਸਕਦੀ ਹੈ ਇਹ ਤੀਜਾ ਹੈ, ਜੋ pg_hba.conf ਵਿੱਚ ਲਿਆ ਜਾਂਦਾ ਹੈ।

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

ਸਰਵਰ ਕਿੱਥੇ ਸੁਣਦਾ ਹੈ

ਉਸ ਪਤੇ 'ਤੇ ਬਾਈਂਡ ਕਰੋ ਜੋ ਅਸਲ ਵਿੱਚ ਮਸ਼ੀਨ ਨੂੰ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਕਿਸੇ ਇੰਟਰਫੇਸ ਨਾਮ 'ਤੇ ਨਹੀਂ:

listen_addresses = '10.20.0.30'

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

ਫਿਰ ਪੋਰਟ, ਆਮ ਤੌਰ 'ਤੇ 5432, ਹੋਸਟ 'ਤੇ ਅਤੇ ਇਸ ਦੇ ਸਾਹਮਣੇ ਦੀ ਹਰ ਸੀਮਾ 'ਤੇ ਫਿਲਟਰ ਕਰੋ। ਨਿੱਜੀ ਪਤੇ 'ਤੇ ਬਾਈਂਡ ਕਰਨਾ ਜਨਤਕ ਇਨਕਾਰ ਦਾ ਸਬੂਤ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਪੋਰਟ ਫਾਰਵਰਡ ਜਾਂ ਕਲਾਊਡ ਪਤਾ ਮੈਪਿੰਗ ਅਜੇ ਵੀ ਉਸ ਨਿੱਜੀ ਲਿਸਨਰ ਤੱਕ ਪੈਕਟ ਭੇਜ ਸਕਦੀ ਹੈ।

ਉਹ ਪਤਾ ਜੋ HBA ਅਸਲ ਵਿੱਚ ਦੇਖਦਾ ਹੈ

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

ਪਹਿਲਾਂ ਹੀ TLS ਅਤੇ SCRAM ਵਰਤ ਰਹੀ ਤੈਨਾਤੀ ਲਈ, ਜਾਣ-ਬੁੱਝ ਕੇ ਤੰਗ ਦੂਰ-ਪਹੁੰਚ ਉਦਾਹਰਨ ਇਸ ਤਰ੍ਹਾਂ ਦਿਸਦੀ ਹੈ:

hostssl appdb app_login 10.8.0.0/24 scram-sha-256
host all all 0.0.0.0/0 reject
host all all ::/0 reject

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

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

ਪਹਿਲਾ ਮੇਲ ਜਿੱਤਦਾ ਹੈ, ਕੋਈ ਵਿਕਲਪ ਨਹੀਂ

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

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

HBA ਸੰਦਰਭ ਕ੍ਰਮ ਅਤੇ host ਤੇ hostssl ਰਿਕਾਰਡਾਂ ਵਿਚਕਾਰ ਫ਼ਰਕ ਦੋਵੇਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਜੋ ਉਦੋਂ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਦੋਂ ਨਿਯਮ ਦਾ ਮਕਸਦ ਇਹ ਹੋਵੇ ਕਿ ਕਨੈਕਸ਼ਨ ਐਨਕ੍ਰਿਪਟਿਡ ਹੋਣਾ ਹੀ ਚਾਹੀਦਾ ਹੈ।

ਮੁੜ-ਲੋਡ, ਮੁੜ-ਸ਼ੁਰੂਆਤ ਅਤੇ ਇਨਕਾਰ ਕੀਤਾ ਕੇਸ

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

ਲਿਸਨਰ ਦੇ ਬਦਲਾਵਾਂ ਲਈ ਆਪਣੀ ਮੁੜ-ਸ਼ੁਰੂਆਤ ਲੋੜੀਂਦੀ ਹੈ, ਅਤੇ ਜਦੋਂ ਕਿਸੇ ਬਦਲਾਅ ਦਾ ਕੋਈ ਅਸਰ ਨਾ ਦਿਸੇ ਤਾਂ ਦੋਵੇਂ ਕਿਰਿਆਵਾਂ ਵਿੱਚ ਉਲਝਣਾ ਆਸਾਨ ਹੈ।

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