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

ઉપયોગી વિભાજન એ નિયમ વચ્ચે છે જે ઉકેલે છે અને નિયમ વચ્ચે જે ઉકેલતો નથી.

દરેક નિયમ ખરેખર શું મેળ ખાય છે

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

ડિબગ કરતા પહેલાં જાણો કે તમારી પાસે આ બેમાંથી કયો છે, કારણ કે દરેક કિસ્સામાં નિષ્ફળતા સંપૂર્ણપણે અલગ દેખાય છે.

સ્ટેકમાં ડોમેન નિયમ ક્યાં રહે છે

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

સેટિંગ્સના લેબલને બદલે વિક્રેતાનું મોડેલ વાંચો. Split Tunnel નામના બોક્સ ધરાવતા બે ક્લાયન્ટ ત્રણ અલગ કામ કરી રહ્યા હોઈ શકે છે.

શું તૂટે છે તેની સરખામણી કરો

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

ફક્ત બીજો જ ગોઠવણીનો પ્રશ્ન છે. બાકીના બે ડિઝાઇન પ્રશ્નો છે કે ઉત્પાદન કેટલું અનુમાન કરવા તૈયાર છે.

BehaviourPrefix ruleDomain rule
Match basisdestination addressrequested name or resolved addresses
Stalenessnonedepends on refresh policy
Subdomain scopenot applicableproduct-defined
Resolver outageunaffectedproduct-defined fallback
Where to debugrouting tableclient log plus resolver state

ક્યારે પ્રીફિક્સ સારો જવાબ છે

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

અનુમાનિત સ્થિર યાદી બંનેમાં સૌથી ખરાબ છે: તે જાળવેલી લાગે છે, અને જે દિવસે પ્રદાતા હોસ્ટ ઉમેરે છે તે દિવસે ચૂપચાપ ટ્રાફિક ચૂકી જાય છે.

નવી વિનંતી સાથે ચકાસો

સામાન્ય પુનઃકનેક્શન પછી કોલ્ડ વિનંતી સાથે પરીક્ષણ કરો, કારણ કે કેશ કરેલું પૃષ્ઠ કદાચ ક્યારેય નિયમને સ્પર્શશે નહીં. નામ ઉકેલો, પછી તપાસો કે કનેક્શન ખરેખર ક્યાં ગયું. dig +short app.example.com વર્તમાન એડ્રેસ સમૂહ આપે છે, અને ક્લાયન્ટની કનેક્શન યાદી તમને જણાવે છે કે કયા ઇન્ટરફેસે પ્રવાહ વહન કર્યો.

ઉત્પાદન દસ્તાવેજ કરે તે રિફ્રેશ અંતરાલ પછી પુનરાવર્તન કરો. જો એડ્રેસ સમૂહ ખસે અને નિયમ તેને અનુસરે નહીં, તો તમે ખરેખરું વર્તન શોધી કાઢ્યું છે.

રિઝોલ્વર નીતિને પણ અલગ રાખો. ડોમેન નિયમને સાચા નામ-ડેટાની જરૂર છે, પણ તે પોતે નક્કી કરતો નથી કે કયો રિઝોલ્વર પ્રશ્નનો જવાબ આપે છે.

સંબંધિત લેખો