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 ஆகக் கருதுவதே அடுத்த இணைப்பு தவறாகக் கண்டறியப்படுவதற்குக் காரணம்.