VPC માં VPN કામ કરે છે, પણ સંચાલિત સેવા સમય સમાપ્ત કરે છે
ટનલ તમારી ધાર પર સમાપ્ત થાય છે, પ્રદાતાના આગળના દરવાજા પર નહીં. રૂટ બદલતા પહેલાં લક્ષ્યને VM પર હોસ્ટ કરેલું, VPC સાથે જોડાયેલું અથવા ફક્ત જાહેર તરીકે વર્ગીકૃત કરો.
VPN દ્વારા સંચાલિત ડેટાબેઝ સુધી પહોંચવું સામાન્ય રીતે એ કારણે નિષ્ફળ જાય છે જે કોઈએ રનબુકમાં લખ્યું નથી: ટનલ તમારા નેટવર્કની ધાર પર સમાપ્ત થાય છે, જ્યારે સેવા ક્યારેય તેની તમારી બાજુ પર નહોતી. રૂટ કોષ્ટક સાચું દેખાય છે, ટનલ ચાલુ હોવાનું જણાવે છે, અને જોડાણ તોપણ સમય સમાપ્ત કરે છે. નીચેની ચાર તપાસ ક્રમમાં કરો અને પહેલી એવી તપાસ પર થોભો જેની સફળતાની શરત પૂરી ન થાય, કારણ કે તેના પછીની દરેક તપાસ ધારે છે કે પહેલાની પસાર થઈ છે.
તપાસ એક: અંતિમ બિંદુ ખરેખર ક્યાં રહે છે?
VPN ગેટવે બે નેટવર્ક જોડે છે જેનું સરનામું તમે નિયંત્રિત કરો છો. સંચાલિત સેવા પ્રદાતાના પોતાના આગળના દરવાજા પાછળ ચલાવવામાં આવે છે, અને તે દરવાજો ઉત્પાદનના આધારે ત્રણમાંથી એક આકાર લે છે. જો તમને ખબર ન હોય કે તમે કયા આકાર સાથે વ્યવહાર કરો છો, તો કોઈ પણ રૂટ કાર્ય મદદ કરશે નહીં, કારણ કે નિષ્ફળતા કદાચ રૂટ નિષ્ફળતા જ ન હોય.
| Shape | What it means | Pass condition |
|---|---|---|
| Software on your VM | Ordinary subnet addressing | Route and security group permit the client |
| Attached to your VPC | Private, but only inside that VPC | Endpoint associated, source allowed, route present |
| Provider-hosted, public endpoint | Optional private link, not private by default | A private endpoint exists and DNS points at it |
મોટાભાગની બગડેલી બપોરો આ વર્ગીકરણ છોડીને સીધા રૂટ કોષ્ટક પર જવાથી આવે છે. પ્રદાતા દ્વારા હોસ્ટ કરેલી સેવા જેનું અંતિમ બિંદુ જાહેર છે તે આકૃતિ ગમે તે કહે, તમારી ટનલ પાછળ નથી, અને VPC સાથે જોડાયેલી સેવા જાહેર DNS જવાબમાં ક્યારેય દેખાશે નહીં.
તપાસ બે: VPC સાથે જોડાયેલી સેવા જેમ કે ElastiCache
એ પ્રકારની કેશ તમારા પોતાના VPC ની અંદર સંબોધવામાં આવે છે અને તેમાં ઇન્ટરનેટ તરફનું કોઈ શ્રોતા જ નથી. એ જ VPC માં સમાપ્ત થતું ક્લાયન્ટ VPN તેમને પહોંચી શકે છે, પણ ફક્ત ત્યારે જ જ્યારે ત્રણ શરતો એકસાથે મળે. કેશનું અંતિમ બિંદુ એવા સબનેટ સાથે જોડાયેલું હોવું જોઈએ જે તમારી ટનલ જોઈ શકે, તેનું સુરક્ષા જૂથ તમારા ક્લાયન્ટ જે સરનામેથી આવે છે તેને મંજૂરી આપવી જોઈએ, અને ક્લાયન્ટ બાજુને કેશના સબનેટને આવરી લેતો રૂટ જોઈએ.
સામાન્ય ભૂલ એ છે કે નજીકમાં ક્યાંકનું જોડાણ ગણાય છે એમ માની લેવું. VPN ને બીજા VPC સાથે જોડવાથી, અથવા ફક્ત peering પર આધાર રાખવાથી, કેશના સુરક્ષા જૂથ કે તેના સબનેટના રૂટ કોષ્ટકને તમારા ક્લાયન્ટ સુધી લંબાવતું નથી. જ્યારે હાલની ટનલ બીજે સમાપ્ત થાય છે, ત્યારે તે VPC ની અંદર મૂકેલો જમ્પ હોસ્ટ અથવા VPN સર્વર સામાન્ય વૈકલ્પિક ઉપાય છે. એ વૈકલ્પિક ઉપાય ડિઝાઇન નહીં પણ ચકરાવો છે, અને રનબુકમાં તેને એમ જ લેબલ કરવું જોઈએ.
તપાસ ત્રણ: જાહેર નામ સાથેનું PaaS અંતિમ બિંદુ
Azure Database for PostgreSQL જાહેર સર્વર નામ રજૂ કરે છે. તે તમને એવું ખાનગી સરનામું આપતું નથી જેને તમે hosts ફાઇલમાં પિન કરી શકો અને ગેટવે દ્વારા રૂટ કરી શકો. વર્ચ્યુઅલ નેટવર્ક સેવા અંતિમ બિંદુઓ મર્યાદિત કરે છે કે કયા સબનેટ સંસાધન સુધી પહોંચી શકે; તે VPN દ્વારા આવતા સ્થાનિક ક્લાયન્ટને અધિકૃત કરતા નથી.
ખાનગી ઍક્સેસ મેળવવાનો અર્થ છે ખાનગી અંતિમ બિંદુ અથવા ખાનગી લિંક ડિઝાઇન દાખલ કરવી અને પછી ખાનગી DNS ઝોન ઉમેરવો, જેથી જાહેર નામ ઇન્ટરનેટને બદલે તે અંતિમ બિંદુ સાથે જવાબ આપે. સેવા અંતિમ બિંદુના નિયમ સાથે જોડાયેલું VPN બીજી આર્કિટેક્ચર છે જે ફક્ત આકૃતિમાં સરખી દેખાય છે. App Service એ જ તર્ક વિરુદ્ધ દિશામાં અનુસરે છે: VNet એકીકરણ એપ્લિકેશનને VNet માં બહાર જતા કૉલ કરવા દે છે, અને તે તમારી ટનલમાંથી અંદર આવતો ખાનગી માર્ગ બનાવતું નથી. તેથી અંદર આવતી ખાનગી ઍક્સેસ માટે ખાનગી અંતિમ બિંદુ, App Service પર્યાવરણ અથવા એપ્લિકેશનની આગળ ગેટવે જરૂરી છે, અને તેમાંથી કયું વાપરી શકો તે પ્લાન પર આધાર રાખે છે.
તપાસ ચાર: પોતાનું આગળનું દરવાજું ધરાવતા ઉત્પાદનો
Firebase Hosting ને Cloud VPN સાથે જોડી શકાતું નથી, કારણ કે હોસ્ટિંગ સ્તર વૈશ્વિક ફ્રન્ટએન્ડ છે, પ્રોજેક્ટ VPC ની અંદરની કોઈ વસ્તુ નહીં. દસ્તાવેજીકૃત વિકલ્પ એ છે કે નિયંત્રિત પ્રવેશ બિંદુ જાતે બનાવો, પ્રોક્સી ઇન્સ્ટન્સ અથવા બકેટ દ્વારા સમર્થિત લોડ બેલેન્સર સાથે. બંને રીતે સાઇટ શુદ્ધ હોસ્ટિંગ ઉત્પાદન રહેવાનું બંધ કરે છે અને હવે તમે સંચાલિત કરો છો તેવી ઇન્ફ્રાસ્ટ્રક્ચર બને છે. કોઈ ટનલ તેને આવરી લેશે એવું વચન આપે તે પહેલાં આ વિનિમયને નામ આપવા યોગ્ય છે.
Private API Gateway VPC સેવા બાજુની વધુ નજીક છે: interface પ્રકારનું VPC અંતિમ બિંદુ એવું હોસ્ટનામ પ્રકાશિત કરે છે જેના જવાબો ખાનગી સરનામાં હોય છે, અને તમારા પરિસરનો ટ્રાફિક ટનલ અથવા સમર્પિત ઇન્ટરકનેક્ટ દ્વારા આવે છે. અંતિમ બિંદુ API સાથે જોડાયેલું હોવું જોઈએ, અને પ્રમાણપત્ર તથા હોસ્ટનામ કૉલ કરનારા વાપરે છે તે કસ્ટમ ડોમેન સાથે મેળ ખાવું જોઈએ.
Google Cloud VPN ટનલ સાથી IP સરનામાં સાથે બંધાય છે, નામ સાથે નહીં. DNS ફોરવર્ડિંગ અલગથી ગોઠવાય છે, અને તેથી ટનલ સંપૂર્ણ સ્વસ્થ હોઈ શકે જ્યારે દૂરના ખાનગી ઝોનમાં શોધ હજુ પણ નિષ્ફળ જાય.
પછી સીમા શોધો
VPC ની અંદરની VM પરથી એ જ જોડાણ ચલાવો. જ્યારે ત્યાં સફળ થાય અને VPN ક્લાયન્ટ પરથી નિષ્ફળ જાય, ત્યારે અંતર ક્લાયન્ટના માર્ગ અને સેવાના અંતિમ બિંદુ વચ્ચે હોય છે: રૂટ, સુરક્ષા જૂથ, અંતિમ બિંદુ નીતિ અથવા નામ. જ્યારે બંને પ્રયાસ નિષ્ફળ જાય, ત્યારે તે નેટવર્કમાં કંઈ પણ સેવા સુધી પહોંચી શકતું નથી, અને VPN ક્યારેય અવરોધ નહોતું.
getent hosts db.internal.example
nc -vz db.internal.example 5432નામની શોધ અને પોર્ટ તપાસ અલગ રીતે કરો, કારણ કે તે જુદા જુદા કારણોસર નિષ્ફળ જાય છે અને જોડી તમને જણાવે છે કે માર્ગનો કયો અડધો ભાગ તૂટેલો છે. જાહેર સરનામામાં ઉકેલાતું નામ તમને જણાવે છે કે ખાનગી DNS ઝોન ચાલુ નથી.