ખાનગી DNS નામ કે ફક્ત એક IP? શેર કરતાં પહેલાં નિર્ણય લો

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

શરત એક: ક્લાયન્ટ્સ પાસે કયો રિઝોલ્વર માર્ગ છે?

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

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

જાહેર રિઝોલ્વર ખાનગી ઝોન શીખશે નહીં કારણ કે લેપટોપ VPN સાથે જોડાયું છે.

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

શરત બે: સેવા કયો સ્રોત મેળવે છે?

પ્રવેશ નિયમો સરનામાંઓ સામે લખાય છે, તેથી ઉપયોગી પ્રશ્ન એ છે કે રૂટિંગ અને અનુવાદ પછી સેવા કયું સરનામું જુએ છે. 10.20.30.40 પરની ઉદાહરણ સેવા માટે, ઓફિસ ક્લાયન્ટ્સ 10.20.30.0/24 થી આવે છે અને દૂરસ્થ ક્લાયન્ટ્સ અલગ પૂલમાંથી આવે છે, જેમ કે 10.99.0.0/24.

જો ગેટવે દૂરસ્થ પૂલનો અનુવાદ કરે, તો સેવા અનુવાદકને જુએ છે, અને 10.99.0.0/24 માટે લખાયેલો નિયમ મેળ ખાશે નહીં.

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

શરત ત્રણ: નામ સેવા સાથે જોડાયેલું છે કે હોસ્ટ સાથે?

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

એક આંતરિક સેવા માટે, સીધો રેકોર્ડ સામાન્ય રીતે યોગ્ય છે અને વિચારવામાં સરળ છે.

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

બે નિર્ણયો અલગ અલગ ચકાસો

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

curl -sv --max-time 5 https://files.corp.example/health

પછી એક વાર પ્રતિબંધિત સ્રોત ચકાસો, અને પરિણામ નોંધો.

તમારા દસ્તાવેજીકરણમાં બે રેકોર્ડ અલગ રાખો: નામ અને તેનો ઝોન, સ્વીકૃત સ્રોતો અને નિયમનો માલિક. જ્યારે એક બદલાય, ત્યારે બીજાને બદલવાની જરૂર નથી.

નિર્ણય સામાન્ય રીતે ક્યાં ખોટો જાય છે

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

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

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