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 તરીકે ગણવો એ જ આગલા કનેક્શનનું ખોટું નિદાન થવાનું કારણ છે.