VPN એન્ડપોઇન્ટ નામ વિરુદ્ધ ખાનગી સેવાનું નામ: બે માલિકો

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

બંનેમાંથી કોઈપણને ડિબગ કરતા પહેલાં બંને રેકોર્ડને નામ આપો

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

આ ટૂંકી યાદી આ ક્ષેત્રની સૌથી સામાન્ય ખોટી નિદાન અટકાવે છે: કામ કરતી શાખા-ટનલને ફરી ચાલુ કરવી, એવા રેકોર્ડને સુધારવા માટે જે સંપૂર્ણપણે તેની અંદર જ રહે છે. ટનલ સેવાના નામ માટે પરિવહન છે; તે તેની સત્તા નથી.

જ્યારે ફેરફાર સૂચવાય, ત્યારે પૂછો કે તે બેમાંથી કયા રેકોર્ડને સ્પર્શે છે. જો કોઈ જવાબ આપી ન શકે, તો ફેરફાર સમયપત્રક માટે તૈયાર નથી.

કોઈ પણ ટનલ અસ્તિત્વમાં આવે તે પહેલાં એન્ડપોઇન્ટનું રિઝોલ્યુશન થવું જોઈએ

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

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

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

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

સેવાનું નામ વર્ણવે છે કે એપ્લિકેશન ક્યાં રહે છે

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

અહીં બે અપડેટ મિકેનિઝમ ભેગા થઈ જાય છે. RFC 2136 ઝોનમાં DNS રેકોર્ડ ઉમેરવા અને કાઢી નાખવા માટે પ્રોટોકોલ નક્કી કરે છે, જ્યારે વ્યાપારી ગતિશીલ DNS પ્રદાતા બીજા હેતુ માટે સંપૂર્ણપણે જુદું HTTP API આપી શકે છે. એકનો ઉપયોગ એનો અર્થ નથી કે બીજું તમારા વાતાવરણમાં છે. તેની સામે અપડેટર લખતા પહેલાં તપાસો કે તમારો ઝોન ખરેખર કઈ મિકેનિઝમ સ્વીકારે છે.

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

બંને માર્ગ અલગ રીતે ચકાસો

ટનલની બહારથી એન્ડપોઇન્ટ અને તેની અંદરથી સેવા તપાસો, અને પરિણામોને બે સ્વતંત્ર તથ્યો તરીકે રાખો:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

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

દરેક સરનામા ફેરફાર પછી જોડી ચલાવો અને નોંધો કે કયો રેકોર્ડ ખસ્યો. જે સોંપણી ફક્ત કહે છે «DNS અપડેટ થયું» તે આગલા ઇજનેરને અનુમાન કરવા છોડી દે છે કે બે જીવનચક્રોમાંથી કયું ખરેખર ચાલ્યું.