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 ની અંદરથી નિષ્ફળ જાય છે. તે ત્રણ પરિણામો નેટવર્ક સીમાને ડેટાબેઝ અધિકૃતિથી અલગ કરે છે, અને નિર્ણયોને અલગ રાખવાનો આખો હેતુ એ જ છે.