Google Cloud VPC માં દૂરસ્થ ડેવલપર ઍક્સેસ: યોગ્ય માર્ગ પસંદ કરો

એક ડેવલપરને એક SSH સત્ર, ડેટાબેઝ પોર્ટ અથવા ડઝનેક ખાનગી સેવાઓની વિશાળ ઍક્સેસની જરૂર હોય છે, અને એ દરેક વિનંતી એક જ પ્રશ્ન જેવી લાગે છે. એવું નથી. લક્ષ્યો, પ્રોટોકોલ અને સંડોવાયેલી ઓળખો નક્કી કરે છે કે Google Cloud માં કયો ઍક્સેસ માર્ગ યોગ્ય છે, અને ડિફૉલ્ટમાં સૌથી પહોળો પસંદ કરવાથી એવું કામ ઊભું થાય છે જે તમારે ધરાવવાની જરૂર ન હતી.

લક્ષ્યો અને પ્રોટોકોલ લખી લો

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

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

થોડી TCP સેવાઓ માટે IAP

Identity-Aware Proxy માં TCP ફોરવર્ડિંગ સેવાને ઇન્ટરનેટ પર ખુલ્લી ન કરતાં લાયક VM સંસાધનો સુધી પ્રમાણિત ટનલ આપે છે. રોજિંદું સ્વરૂપ gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a છે, અને એક પોર્ટને gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a વડે સ્થાનિક રીતે ફોરવર્ડ કરી શકાય છે.

ત્રણ બાબતો મેળ ખાવી જોઈએ: કૉલરને IAP ટનલ ઍક્સેસ ભૂમિકા જોઈએ, ફાયરવૉલે IAP સ્રોત શ્રેણીને મંજૂરી આપવી જોઈએ, અને લક્ષ્ય ઇન્સ્ટન્સ પર પહોંચી શકાય તેવું હોવું જોઈએ. ટનલ બનાવવાની અધિકૃતતા ડેટાબેઝ ક્રેડેન્શિયલ, SSH લૉગિન કે RDP સત્ર નથી, તેથી ઍપ્લિકેશન પ્રમાણીકરણને તેની યોગ્ય જગ્યાએ રાખો.

IAP TCP ફોરવર્ડિંગ ત્રીજા સ્તરનું VPN નથી. તે TCP ને પસંદ કરેલા લક્ષ્ય સુધી લઈ જાય છે, મનસ્વી IP ટ્રાફિક કે UDP નહીં, અને જ્યારે ઍપ્લિકેશનને ઘણી સેવાઓમાં ખાનગી DNS ની જરૂર હોય ત્યારે તે યોગ્ય બેસતું નથી.

વધુ વિશાળ પહોંચ માટે રિમોટ-ઍક્સેસ VPN

જ્યારે ઘણાં લક્ષ્યો, પ્રોટોકોલ કે ખાનગી DNS ઝોનની જરૂર હોય, ત્યારે VM અથવા સમર્થિત ઉપકરણ પર સ્પષ્ટપણે સંચાલિત રિમોટ-ઍક્સેસ VPN વધુ સારું સ્વરૂપ છે. એ જમાવટ Google-સંચાલિત Cloud VPN થી અલગ છે: ક્લાયન્ટ ઓળખ નોંધણી, સૉફ્ટવેર અપડેટ, ક્લાયન્ટ માર્ગો અને VPC પરત માર્ગો તમારા છે.

ફક્ત જાહેર લિસનર નહીં, આખી યાદીનું આયોજન કરો. ટનલ પૂલ, તે તરફ પરત VPC માર્ગ, ફોરવર્ડિંગ નિયંત્રણો, DNS ઉકેલ અને પ્રતિ-સેવા ઍક્સેસ નીતિનો સમાવેશ કરો. જે VPN જોડાય છે પણ આંતરિક નામો ઉકેલી શકતું નથી તે ડેવલપરના કાર્યપ્રવાહને એટલી જ સંપૂર્ણ રીતે નિષ્ફળ કરે છે જેટલી કદી જોડાય નહીં તેવી VPN કરે છે.

Cloud VPN એ સાઇટ ગેટવે છે, લૅપટૉપ પ્રોફાઇલ નથી

Google Cloud VPN IPsec દ્વારા સહકર્મી ગેટવેને જોડે છે, અને તેની વારંવાર પૂછાતા પ્રશ્નો એ સાઇટ-થી-સાઇટ ભૂમિકાને ક્લાયન્ટ-થી-ગેટવે ઍક્સેસથી અલગ પાડે છે. ટનલ બનાવવાથી એવી પ્રોફાઇલ બનતી નથી જે કર્મચારી લૅપટૉપ પર આયાત કરે. જ્યારે કોઈ Cloud VPN પ્રોફાઇલ માગે ત્યારે આ ભેદ મહત્ત્વનો છે. જવાબ બીજું ઉત્પાદન છે.

ગેટવે જે સારી રીતે કરે છે તે છે ઑફિસ નેટવર્ક પાછળનાં મશીનોને VPC માં માર્ગ આપવો. તે દરેક કર્મચારીને પ્રમાણિત કરતું નથી કે ઍપ્લિકેશન પરવાનગીઓ આપતું નથી, તેથી એ નીતિઓ નેટવર્ક અને ઍપ્લિકેશન સ્તરે રહે છે જ્યાં તે ઓળખ મુજબ લાગુ કરી શકાય.

ચકાસો અને નોંધો

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

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