Azure P2S VPN ખાનગી એન્ડપોઇન્ટનું નામ ઉકેલી શકતું નથી

તમે point-to-site ટનલ જોડો છો, ખાનગી સરનામાં પર ping કરો છો, એપ ખોલો છો અને તેના બદલે 403 અથવા પ્રમાણપત્રની ભૂલ મળે છે. બંને લક્ષણો DNS તરફ ઇશારો કરે છે, પણ તે અલગ ખામીઓ છે: એકનો અર્થ ક્લાયન્ટે જાહેર સરનામું ઉકેલ્યું, બીજાનો અર્થ તેણે ખાનગી સરનામું ઉકેલ્યું અને પછી એવું નામ આપ્યું જે પ્રમાણપત્ર આવરી લેતું નથી. નીચેની તપાસો ક્રમમાં કરો અને પહેલી નિષ્ફળતા પર અટકો, કારણ કે hosts એન્ટ્રી કે કેશમાં સાચવેલો જવાબ પછીની દરેક તપાસને ખોટા કારણે પાસ કરાવી શકે છે. હું આ ક્રમ મારી VPN પ્રોફાઇલની બાજુમાં એક ટેક્સ્ટ ફાઇલમાં રાખું છું, કારણ કે સુધારો ટનલમાં કંઈ બદલતો નથી અને ક્લાયન્ટ જે જાણે છે તેમાં બધું બદલે છે.

ક્લાયન્ટને ખરેખર જે સરનામું મળે છે તેનાથી શરૂ કરો

એપ્લિકેશન પર ભરોસો કરવાને બદલે રિઝોલ્વરને સીધું પૂછો. Windows પર, nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net દર્શાવે છે કે ક્લાયન્ટને કયું દૃશ્ય મળ્યું. જાહેર જવાબનો અર્થ છે કે નીચે કંઈ પણ એન્ડપોઇન્ટ સુધી પહોંચશે નહીં; એન્ડપોઇન્ટનું ખાનગી સરનામું એટલે DNS પૂરું થયું અને આગળની તપાસ કનેક્શન પોતે છે.

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

ટનલ પહેલાં ઝોન, તેની લિંક અને રેકોર્ડ તપાસો

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

ઝોનના નામ સેવાઓના હોય છે, સામાન્ય રીતે ખાનગી લિંકના નહીં. App Service સામાન્ય રીતે privatelink.azurewebsites.net વાપરે છે, સ્ટોરેજ અને SQL ના પોતાના નામસ્થાન હોય છે, અને બીજી સેવાનો ઝોન ઉછીનો લેવાથી એવો ઝોન બને છે જે અસ્તિત્વમાં છે પણ કંઈ ઉપયોગી જવાબ આપતો નથી.

ક્લાયન્ટને એવું રિઝોલ્વર આપો જે સાચે જ તેની પહોંચમાં હોય

168.63.129.16 Azure વર્ચ્યુઅલ મશીનમાંથી જવાબ આપે છે અને point-to-site ટનલની બીજી બાજુના લેપટોપ માટે DNS સર્વર નથી. ક્લાયન્ટને ટનલ દ્વારા પહોંચી શકાય તેવું રિઝોલ્વર જોઈએ: Azure DNS Private Resolver નું ઇનબાઉન્ડ એન્ડપોઇન્ટ, વર્ચ્યુઅલ નેટવર્કની અંદરનું ફોરવર્ડર, અથવા VPN ક્લાયન્ટ પ્રોફાઇલમાં વહેંચાયેલી DNS સર્વર એન્ટ્રીઓ જેથી ક્લાયન્ટ વર્ચ્યુઅલ નેટવર્કને સીધું પૂછે.

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

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

જે નામ માટે પ્રમાણપત્ર જારી થયું છે તે વાપરો

સરનામું સાચું થાય એટલે બીજી ખામી સામે આવે છે. સ્ટોરેજ અને App Service privatelink ઉપનામ પ્રકાશિત કરે છે, અને એ ઉપનામ જરૂરી નથી કે પ્રમાણપત્રમાંનું નામ હોય. privatelink.blob.core.windows.net પર મોકલેલી AzCopy અપલોડ માન્યતામાં નિષ્ફળ ગઈ; એ જ અપલોડ <account>.blob.core.windows.net/<container> પર ખાનગી સરનામે ઉકેલાઈ અને પસાર થઈ, તેથી તે કોઈ બાયપાસ વિના ખાનગી માર્ગ પર રહી.

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

ચાર પગલાંનો ક્રમ જે દરેક સ્તરને અલગ કરે છે

1. ખાતરી કરો કે VPN ક્લાયન્ટ પાસે point-to-site પૂલનું સરનામું છે અને એન્ડપોઇન્ટના ખાનગી સરનામા સુધીનો માર્ગ છે.
2. એપ જે ચોક્કસ નામ વાપરે છે તે ઉકેલો અને જવાબને એન્ડપોઇન્ટના સરનામા સાથે સરખાવો.
3. સેવા પોર્ટ પર એન્ડપોઇન્ટ સાથે TCP કનેક્શન ખોલો, પછી તે કનેક્શન પર રજૂ થતું પ્રમાણપત્રનું નામ વાંચો.
4. હવે જ અધિકૃતતા ચકાસો, કારણ કે કામ કરતો માર્ગ અને માન્ય પ્રમાણપત્ર હજી સંસાધનનો ઍક્સેસ આપતા નથી.

સરનામું સાચું હોય ત્યારે નકારાયેલું કનેક્શન DNS તરફ નહીં, નેટવર્ક સુરક્ષા જૂથ કે ખાનગી એન્ડપોઇન્ટ કનેક્શનની સ્થિતિ તરફ ઇશારો કરે છે, તેથી રિઝોલ્વર સેટિંગ ફરી સંપાદિત કરતાં પહેલાં તે તપાસો. TLS નામની અસંગતિ તમને URL ના હોસ્ટનામ અને પ્રમાણપત્રના subject પર પાછા મોકલે છે. રિઝોલ્યુશન આઉટપુટ, પ્રમાણપત્રનું નામ અને ચોક્કસ URL સાથે રાખો; એ ત્રણ મૂલ્યો ગેટવેને અડ્યા વિના આમાંના મોટા ભાગના કિસ્સા સમજાવે છે.

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

ક્લાયન્ટ પણ કેશ કરે છે. દસ મિનિટ પહેલાં જાહેર રીતે જવાબ આપનારો રેકોર્ડ ઝોન સુધાર્યા પછી પણ જવાબ આપતો રહે છે, તેથી ફરી ચકાસતાં પહેલાં કેશ ખાલી કરો. Windows પર, ipconfig /flushdns ક્લાયન્ટ કેશ સાફ કરે છે; નામ રિઝોલ્યુશન નીતિના નિયમો ટકી રહે છે, કયો સફિક્સ કયા સર્વર પર જાય તે નક્કી કરે છે અને તમે હમણાં બદલ્યું તે રિઝોલ્વર પર નામસ્થાન મોકલતા રહી શકે છે.

hosts એન્ટ્રી ક્યાં આવે છે

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

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

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