VPN દ્વારા Cloud SQL ખાનગી IP: જે રૂટ કોઈ નિકાસ કરતું નથી

ઘણી ટીમો માને છે કે Cloud SQL ખાનગી IP ફક્ત VPCની અંદરથી જ કામ કરે છે, અને આ માન્યતા ટકી રહે છે કારણ કે નિષ્ફળતા ડેટાબેઝ સમસ્યા જેવી લાગે છે. Google એ Cloud VPN અથવા Cloud Interconnect દ્વારા જોડાયેલા નેટવર્કમાંથી ઍક્સેસનું દસ્તાવેજીકરણ કરે છે. તે નેટવર્કને કોઈ ખાસ ડેટાબેઝ સુવિધાની જરૂર નથી, પણ બે રૂટ વિનિમયની જરૂર છે જેને અડધા કન્ફિગર કરેલા છોડી દેવું સરળ છે. ટનલ ઉપર આવે છે, કમ્પ્યુટ ઇન્સ્ટન્સ જવાબ આપે છે, અને ડેટાબેઝ કનેક્શન સમયસીમા વટાવે છે — બરાબર એ જ સંયોજન જે લોકોને ખોટા કન્સોલ પર મોકલે છે.

દંતકથા: ખાનગી IP એટલે VPC માટે ખાનગી

ખાનગી સેવાઓની ઍક્સેસ એ તમારા નેટવર્ક અને Googleની માલિકીના ઉત્પાદક નેટવર્ક વચ્ચેનું VPC પિયરિંગ છે. સેવા માટે ફાળવેલી શ્રેણી ઉત્પાદકની બાજુ રહે છે, અને ઇન્સ્ટન્સનું સરનામું તેની અંદર છે. એ પિયરિંગને કારણે તમારા પ્રોજેક્ટનો ડેટાબેઝ એવા સરનામા પર બેસી શકે છે જ્યાં તમારું VPC રૂટ કરે છે, જ્યારે તમારા કોઈ સ્પષ્ટ સબનેટમાં તે નથી હોતું.

કારણ કે તે પિયરિંગ છે, તેમાં પિયરિંગ વર્તન પણ છે, જેમાં એ ભાગનો સમાવેશ થાય છે જ્યાં કસ્ટમ રૂટ આપમેળે પસાર થતા નથી.

દંતકથા: કામ કરતી ટનલ ડેટાબેઝ રૂટ સાથે લઈ જાય છે

બે શ્રેણીઓએ આ મુસાફરી ટકાવવી પડે છે. પ્રથમ ક્લાયન્ટ પ્રીફિક્સ છે: તમારું સ્થાનિક નેટવર્ક ચોક્કસ પ્રીફિક્સ સાથે Cloud Routerને જાણીતું હોવું જોઈએ, કારણ કે ડિફોલ્ટ રૂટ એ ઇમ્પોર્ટ આપી શકતું નથી જે ઉત્પાદક નેટવર્કને પરત માર્ગ માટે જોઈએ છે. બીજી ફાળવેલી સેવા શ્રેણી છે, જે બહારની બાજુએ શીખવી પડે છે જેથી ડેટાબેઝ માટેના તેના પેકેટને જવાનું સ્થળ મળે. આ અલગ સીમાઓ પર જાળવવામાં આવતા અલગ રૂટ છે, અને એકને ઠીક કરવાથી બીજું તૂટેલું રહે છે.

Googleની બાજુએ તેનો અર્થ છે સંબંધિત પિયરિંગ જોડાણો પર Export custom routes સક્ષમ કરવું અને ટનલ માટે Cloud Routerના જાહેર કરેલા રૂટમાં ફાળવેલી સેવા શ્રેણી ઉમેરવી.

પહેલેથી હાજર જાહેરાતો રાખો. સેવા શ્રેણી ઉમેરવાથી એ VPC રૂટ દૂર થવા જોઈએ નહીં જે એ જ BGP સત્ર બીજા ટ્રાફિક માટે વહન કરે છે, અને સંપૂર્ણપણે બદલાયેલ જાહેરાત સમૂહ પ્રથમની પાછળ છુપાયેલું બીજું વિક્ષેપ છે. બહારના ઉપકરણ પર અસરકારક રૂટ પણ તપાસો, કારણ કે VPN ગેટવે કે બીજા સબનેટ સુધી પહોંચવું ફક્ત પરિવહન સાબિત કરે છે.

દંતકથા: Cloud SQL Auth Proxy નેટવર્ક હલ કરે છે

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

તે જે કરતું નથી તે છે ડિસ્કનેક્ટેડ લેપટોપને ફક્ત ખાનગી ઇન્સ્ટન્સ સુધી પહોંચવા દેવું.

દંતકથા: Private Service Connect એ જ નિયમો અનુસરે છે

Private Service Connect તમારા પોતાના સબનેટમાં endpoint અને તમે નિયંત્રિત કરો એવી DNS ગોઠવણી વાપરે છે, તેથી ત્યાં જવાનો રૂટ તમારા માલિકીના સરનામા સુધીનો સામાન્ય રૂટ છે. પિયરિંગ નિકાસ સેટિંગ્સ એ ડિઝાઇન પર લાગુ પડતા નથી, અને પિયરિંગ ફેરફારો PSC ડિપ્લોયમેન્ટમાં કોપી કરવાથી પહોંચ ન વધારતાં જોખમ વધે છે.

બંને તમને ખાનગી સરનામું આપે છે; સામ્ય ત્યાં જ પૂરું થાય છે.

માર્ગને યોગ્ય ક્રમમાં ચકાસો

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

જો તમારી ક્લાયન્ટ શ્રેણીઓ RFC 1918ની બહાર હોય, તો ડિઝાઇન અસમર્થિત છે એવા નિષ્કર્ષ પર આવતા પહેલા વધારાની રૂટ-નિકાસ અને નેટવર્ક-અધિકૃતિની જરૂરિયાતોની સમીક્ષા કરો.

કનેક્શન સાથે ચાર વસ્તુઓ નોંધો: બહારનું પ્રીફિક્સ, ફાળવેલી સેવા શ્રેણી, સંબંધિત પિયરિંગ જોડાણો અને જાહેરાત કરતું રાઉટર. આ ચાર આખો ખાનગી માર્ગ સમજાવે છે, અને તેઓ એ દંતકથા બદલે છે કે Cloud SQLને કાં તો હંમેશા પ્રોક્સી જોઈએ છે અથવા VPN પરથી જ પહોંચી શકાતું નથી.