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-க்குள் இருந்து தோல்வியடைகிறது. அந்த மூன்று முடிவுகள் நெட்வொர்க் எல்லையை தரவுத்தள அங்கீகாரத்திலிருந்து பிரிக்கின்றன, அதுவே முடிவுகளைத் தனித்தனியாக வைத்திருப்பதன் முழு நோக்கம்.