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

સંપૂર્ણ ટનલ અને સાંકડા ફોરવર્ડિંગ વચ્ચેની પસંદગી સુરક્ષા-નાટક નહીં, વ્યાપ વિશેનો નિર્ણય છે.

પાછળ પુનરાવર્તિત માર્ગ છોડો

ઉકેલાયેલા સરનામાના બદલે એન્ડપોઇન્ટનું નામ, સિક્યોરિટી ગ્રુપ જે સ્રોત શ્રેણીને મંજૂરી આપે છે, અને ડેવલપર જે ડેટાબેઝ ભૂમિકા વાપરે છે તેનું દસ્તાવેજીકરણ કરો. એ ત્રણ તથ્યો ભવિષ્યની મોટાભાગની નિષ્ફળતા ફોન કૉલ વગર સમજાવે છે. ક્લાયન્ટ પ્રોફાઇલની આવૃત્તિ પણ ઉમેરો, કારણ કે પ્રોફાઇલ ફેરફાર જૂનાએ વહન કરેલો રૂટ દૂર કરી શકે છે.

પછી નકારાત્મક કેસ એક વાર ચકાસો: મંજૂર સ્રોતની બહારનો ક્લાયન્ટ હજી પણ નકારાવો જોઈએ.

જે ખાનગી ડેટાબેઝ ફક્ત તેને સેટ કરનાર વ્યક્તિ માટે કામ કરે છે તે ખાનગી ઍક્સેસ નથી; તે અદસ્તાવેજીકૃત અપવાદ છે જે ફરી શોધાવાની રાહ જુએ છે. માર્ગ લખી રાખો, અને આગલો ડેવલપર રહસ્યના બદલે પદ્ધતિ વારસામાં મેળવશે.