ટનલ ચાલુ છે, તો પણ ખાનગી નામ કેમ હજુ નિષ્ફળ છે?

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

વિનંતી કયા રિઝોલ્વર સુધી પહોંચી?

ટનલ તરફ જોતા પહેલાં દરેક લિંક સાથે જોડાયેલ રિઝોલ્વર શોધો. Linux રિઝોલ્વર સ્થિતિ આદેશ દ્વારા દરેક લિંકના સર્વર બતાવે છે, અને macOS તેના DNS રૂપરેખાંકન ડમ્પમાં સ્કોપ્ડ રિઝોલ્વર બતાવે છે. જો જવાબ હજુ ઘરના રાઉટરથી આવે છે, તો ટનલ લિંકની ક્યારેય ચકાસણી થઈ નથી.

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

અહીં બે તબક્કા ભેગા થઈ જાય છે: રિઝોલ્વર સરનામું ધકેલતું સર્વર, અને તેને સક્રિય લિંક પર સ્થાપિત કરતું ક્લાયન્ટ. પ્રોફાઇલમાં વિકલ્પ હોઈ શકે, અને લોગ તેના આવવાનું બતાવી શકે, જ્યારે ઓપરેટિંગ સિસ્ટમ જૂનું સર્વર વાપરતું રહે છે. લોગની સરખામણી લિંક જે જણાવે છે તેની સાથે કરો, અને લિંક પર ભરોસો રાખો.

એવું સરનામું વાપરો જેના પર ક્લાઉડ નેટવર્ક ખરેખર જવાબ આપે

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

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

ટનલ નામની જગ્યા વહન કરતી નથી

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

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

સીમાઓ ક્રમમાં પાર કરો

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

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

સાંકળને ત્યાં રાખો જ્યાં આગલી વ્યક્તિ તેને શોધી શકે

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

રેકોર્ડને ચોક્કસ રહેવા જેટલો ટૂંકો રાખો: ચાર લીટી, એક તારીખ, અને દરેક ભાગનો માલિક કોણ છે તેનું નામ. જૂનો રેકોર્ડ ન હોવા કરતાં ખરાબ છે, કારણ કે તે ખોટો હોવા છતાં અધિકૃત લાગે છે.