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 లోపలి నుండి విఫలమవుతుంది. ఆ మూడు ఫలితాలు నెట్వర్క్ సరిహద్దును డేటాబేస్ అధికారం నుండి వేరు చేస్తాయి, నిర్ణయాలను వేరుగా ఉంచడం యొక్క మొత్తం ఉద్దేశం అదే.