ખાનગી એન્ડપોઈન્ટ, એ જ સર્વર નામ: Azure SQL કનેક્શન સ્ટ્રિંગ્સ

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

orders-db.database.windows.net રાખો અને ક્લાયન્ટને તેના માટે ખાનગી જવાબ આપો.

નામ અને સરનામાની અલગ અલગ જવાબદારીઓ છે

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

Azure SQL માટે Microsoftની માર્ગદર્શિકા ક્લાયન્ટ્સ પાસેથી સામાન્ય સર્વર નામ માંગે છે. સીધું IP, અને તે જ રીતે privatelink ઉપસર્ગવાળું નામ, અદલાબદલી કરી શકાય તેવું લોગિન લક્ષ્ય નથી. જે સાધનો IP સ્વીકારે છે તે સ્વીકારશે અને પછી TLS પર અથવા પ્રમાણીકરણ પર નિષ્ફળ જશે, જે સાચી ભૂલ છુપાવે છે. એ નિષ્ફળતાઓ ઓળખપત્રની સમસ્યા જેવી વંચાય છે જ્યાં સુધી તમે ભૂલમાંનું હોસ્ટનામ ન જુઓ.

ખાનગી ઝોન ખરેખર શું બદલે છે

ખાનગી DNS ઝોન privatelink નામ સ્થાનની અંદર સર્વર માટે એક સરનામું નોંધે છે, અને ઝોન તે વર્ચ્યુઅલ નેટવર્ક સાથે જોડાયેલો છે જે તેનો ઉપયોગ કરવો જોઈએ. ઉકેલ આગળ વધે છે; કનેક્શન સ્ટ્રિંગ નહીં. નીચેનો આકાર એક ઉદાહરણ છે, જાહેર ઝોનમાં પેસ્ટ કરવાનો રેકોર્ડ નથી.

Application name:        orders-db.database.windows.net
Private DNS zone:        privatelink.database.windows.net
Resolved private entry:  the approved private endpoint address

એ રેકોર્ડ અને તેની ઝોન લિંકને માલિક અને સમીક્ષા તારીખ સાથે માળખાગત સુવિધા તરીકે જાળવો.

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

Azureની બહારના ક્લાયન્ટ્સને એ ઝોનમાં પ્રવેશ માર્ગની જરૂર છે

VPN ક્લાયન્ટ Azureના રિઝોલ્વરની બહાર બેસે છે, તેથી ખાનગી ઝોન હાઇબ્રિડ માર્ગથી પહોંચી શકાય તેવો હોવો જોઈએ. Azure DNS ફોરવર્ડર અથવા Azure DNS Private Resolver તે નેટવર્ક દ્વારા આવતી ક્વેરીઓને સેવા આપી શકે છે. Microsoftની માર્ગદર્શિકા છે કે સંબંધિત જાહેર સેવા ઝોનને એ ગોઠવણ દ્વારા ફોરવર્ડ કરો, એવું ધારવાને બદલે કે ક્લાયન્ટ્સ સીધું privatelink નામ પૂછે છે. જે ક્લાયન્ટ્સ ખાનગી જવાબ ઉકેલી શકતા નથી તે ફરિયાદ કર્યા વિના જાહેર જવાબ પર પાછા જાય છે.

ફોરવર્ડિંગનો વ્યાપ ઇરાદાપૂર્વક રાખો, કારણ કે વપરાશમાં રહેલા જાહેર ઝોનને બદલવાથી એવા નામ તૂટે છે જે બદલીમાં નથી.

ઓળખ સ્થિર રાખતા ક્રમમાં પ્રદાન કરો

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

જોડાયેલું VPN ચિહ્ન પોતે ખાનગી લક્ષ્ય પસંદ કરતું નથી.

ખાનગી એન્ડપોઈન્ટ શું બંધ કરતું નથી

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

સર્વર કઈ કનેક્શન નીતિ વાપરે છે તે પણ તપાસો.

Redirect પ્રારંભિક ગેટવે કનેક્શન પછી ક્લાયન્ટને નોડ પરના પોર્ટ પર મોકલે છે, જે બદલે છે કે ક્લાયન્ટ નેટવર્કે શું મંજૂર કરવું જોઈએ. Proxy ટ્રાફિક ગેટવે પર રાખે છે. એક પોર્ટ પર સફળ TCP હેન્ડશેક આખી લોગિન કાર્યપ્રવાહ નથી.

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