స్థానిక డేటాబేస్ క్లయింట్ మరియు ప్రైవేట్ RDS: కనెక్షన్ ఎందుకు సమయం మించిపోతుంది

ఒక డెవలపర్ ల్యాప్టాప్ ప్రైవేట్ RDS ఎండ్పాయింట్కు కనెక్ట్ అయ్యేటప్పుడు సమయం మించిపోతుంది, అయితే అదే ఆధారాలు బాస్టియన్ హోస్ట్ నుండి పనిచేస్తాయి. ఏదీ పడిపోలేదు. ఆ ల్యాప్టాప్ మరియు డేటాబేస్ మధ్య మార్గంలో మూడింటిలో ఒకటి లోపించింది: పరిష్కరించబడే పేరు, ట్రాఫిక్ను మోసుకెళ్లే మార్గం, లేదా డేటాబేస్ నిజంగా చూసే మూలాన్ని అనుమతించే భద్రతా సమూహ నియమం. మిగిలిన రెండింటిని మార్చే ముందు ఏది లోపించిందో కనుగొనండి.

సరైన పొరలో వైఫల్యాన్ని చదవండి

సమయం మించడం ఒకే లోపం కాదు. పరిష్కరించబడని పేరు ప్యాకెట్ యంత్రాన్ని విడిచిపెట్టకముందే విఫలమవుతుంది. మార్గం లేని చిరునామా ప్యాకెట్లను నల్ల రంధ్రంలోకి పంపుతుంది. ఫిల్టర్ చేసిన పోర్టు తప్పు హోస్ట్లాగానే కనిపించే నిరీక్షణను సృష్టిస్తుంది. దశలను క్రమంగా అమలు చేసి మొదట విఫలమైన దశలో ఆగండి.

dig +short db.internal.example
nc -vz db.internal.example 5432

పేరు పబ్లిక్ చిరునామాను తిరిగి ఇచ్చినా, లేదా ఏమీ ఇవ్వకపోయినా, టన్నెల్ ఇంకా సమస్య కాదు.

పేరు పరిష్కరించబడి పోర్టు పరీక్ష వేలాడితే, మీరు పరిష్కరించిన చిరునామాను డేటాబేస్ నివేదించే చిరునామాతో పోల్చండి. నిర్వహిత ఎండ్పాయింట్ VPC లోపల ప్రైవేట్ చిరునామాకు, బయట ఉపయోగకరమైన దేనికీ పరిష్కరించబడవచ్చు, పాత శోధన నుండి కాపీ చేసిన చిరునామా ఇక స్పందించని హోస్ట్ను సూచిస్తుంది.

టన్నెల్ను మార్గం నుండి వేరు చేయండి

క్లయింట్ VPN కనెక్ట్ చేయడం ప్రతి ప్రైవేట్ పరిధిని స్వయంచాలకంగా మార్గనిర్దేశం చేయదు. ప్రొఫైల్ సేవ నెట్టే మార్గాలను మోసుకెళ్తుంది, క్లయింట్ వాటిలో కొన్నింటిని మాత్రమే ఇన్స్టాల్ చేయవచ్చు. క్లయింట్ నిజంగా ఏ పరిధులను జోడించింది, డేటాబేస్ చిరునామా వాటిలో ఒకటిలోకి వస్తుందా అని చూడండి.

ip route get 10.20.40.15
ip addr show tun0

టన్నెల్ ఇంటర్ఫేస్ వైపు చూపే మార్గం అవసరం; అది సరిపోదు, ఎందుకంటే ఎదురుగా ఉన్న వైపు ఇంకా ట్రాఫిక్ను అంగీకరించాలి.

స్ప్లిట్-టన్నెల్ ప్రొఫైల్స్ ఈ సగం వైఫల్యానికి సాధారణ మూలం. అవి ప్రొఫైల్ రూపొందించిన అప్లికేషన్కు పనిచేస్తాయి మరియు డేటాబేస్ పరిధిని టన్నెల్ వెలుపల వదిలేస్తాయి, ఇది ఫైర్వాల్ సృష్టించే అదే సమయ మించుటను సృష్టిస్తుంది.

భద్రతా సమూహాన్ని నిజమైన మూలంతో సరిపోల్చండి

RDS భద్రతా సమూహం మనుషులను కాదు, మూలాలను అనుమతిస్తుంది. నిర్మాణాన్ని బట్టి మూలం VPN క్లయింట్ పూల్, బాస్టియన్ ప్రైవేట్ చిరునామా, లేదా ట్రాఫిక్ అనువదించబడే NAT చిరునామా కావచ్చు. నియమాన్ని మరియు ప్యాకెట్ నిజమైన మూలాన్ని కలిసి చదవండి.

aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0 \
  --query 'SecurityGroups[].IpPermissions'

ఒక ల్యాప్టాప్ ఇంటి చిరునామా కోసం నియమం యాక్సెస్ డిజైన్ కాదు, నిర్వహణ సమస్య.

మార్గంలో క్లయింట్ VPN లేదా NAT గేట్వే ఉన్నప్పుడు, డేటాబేస్ డెవలపర్ టన్నెల్ చిరునామా బదులు అనువాదకుడి చిరునామాను చూడవచ్చు. అందుకే పనిచేసే బాస్టియన్ సెటప్ నుండి కాపీ చేసిన నియమం ల్యాప్టాప్కు విఫలమవచ్చు: రెండు మార్గాలు వేర్వేరు మూలాల నుండి వస్తాయి, రెండూ అంతర్గతంగా కనిపించినా.

విశాలమైన మార్గం కంటే ఇరుకైన మార్గాన్ని ఇష్టపడండి

ఒక డెవలపర్కు ఒక డేటాబేస్ అవసరమైనప్పుడు, సెషన్ ఆధారిత ఫార్వర్డింగ్ పూర్తి నెట్వర్క్ టన్నెల్ కంటే నిర్వహించడానికి చవకగా ఉంటుంది. స్థానిక క్లయింట్ ఫార్వర్డ్ చేసిన పోర్టుకు కనెక్ట్ అవుతుంది, దూరపు ఘటకం నెట్వర్క్ లోపలి నుండి డేటాబేస్ కనెక్షన్ చేస్తుంది.

ssh -N -L 5432:db.internal.example:5432 bastion.internal.example

ఆ డిజైన్లో TLS ధృవీకరణను చెక్కుచెదరకుండా ఉంచండి. క్లయింట్ ఆశించే పేరుకు వ్యతిరేకంగా సర్వర్ సర్టిఫికేట్ను ఇంకా ధృవీకరించాలి; స్థానిక ఫార్వర్డ్ పోర్టు ధృవీకరణను ఆపివేయడానికి కారణం కాదు, దాన్ని ఆపివేయడం పట్టుకోవడానికి అర్హమైన గుర్తింపు సమస్యను మరుగుపరుస్తుంది.

పూర్తి టన్నెల్ మరియు ఇరుకైన ఫార్వర్డింగ్ మధ్య ఎంపిక భద్రతా నాటకం కాదు, పరిధి గురించిన నిర్ణయం.

వెనుక పునరావృతమయ్యే మార్గాన్ని విడిచిపెట్టండి

పరిష్కరించిన చిరునామా బదులు ఎండ్పాయింట్ పేరు, భద్రతా సమూహం అనుమతించే మూల పరిధి, మరియు డెవలపర్ ఉపయోగించే డేటాబేస్ పాత్రను నమోదు చేయండి. ఈ మూడు వాస్తవాలు భవిష్యత్తు వైఫల్యాలలో చాలావరకు ఫోన్ కాల్ లేకుండా వివరిస్తాయి. క్లయింట్ ప్రొఫైల్ వెర్షన్ను కూడా జోడించండి, ఎందుకంటే ప్రొఫైల్ మార్పు పాతది మోసిన మార్గాన్ని తొలగించవచ్చు.

తర్వాత ప్రతికూల కేసును ఒకసారి పరీక్షించండి: ఆమోదించిన మూలం వెలుపల ఉన్న క్లయింట్ ఇంకా తిరస్కరించబడాలి.

తనను సెట్ చేసుకున్న వ్యక్తికి మాత్రమే పనిచేసే ప్రైవేట్ డేటాబేస్ ప్రైవేట్ యాక్సెస్ కాదు; అది మళ్లీ కనుగొనబడటానికి వేచి ఉన్న నమోదు చేయని మినహాయింపు. మార్గాన్ని రాయండి, తదుపరి డెవలపర్ రహస్యం బదులు పద్ధతిని వారసత్వంగా పొందుతాడు.