CDN તેના સરનામાં બદલે ત્યારે VPN ડોમેન નિયમ તૂટે છે

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

એક લુકઅપ ઇન્વેન્ટરી કેમ નથી

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

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

ત્રીજું અંતર સરનામા પરિવાર છે. ફક્ત v4 માટેનો નિયમ AAAA રેકોર્ડ વિશે કંઈ કહેતો નથી, જે ક્લાયન્ટ પસંદ કરી શકે.

ડોમેન નિયમ કે શ્રેણી, તે નક્કી કરતી ત્રણ શરતો

પ્રથમ, શું સેવા સ્થિર પ્રીફિક્સનો સમૂહ પ્રકાશિત કરે છે જે તમે ધરાવી અને દસ્તાવેજીકરણ કરી શકો? જો કરે, તો સ્પષ્ટ શ્રેણીઓ પ્રામાણિક અને સસ્તી છે. જો ન કરે, તો ડોમેન નિયમ જ એકમાત્ર માર્ગ છે જે સેવાને અનુસરી શકે.

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

એ ત્રણનો જવાબ આપો અને પસંદગી સામાન્ય રીતે સ્પષ્ટ હોય છે. અનુમાન એવો નિયમ બનાવે છે જે પરીક્ષણમાં કામ કરે અને ઉત્પાદનમાં નિષ્ફળ જાય.

સેશન ચકાસો, પૃષ્ઠ નહીં

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

પૃષ્ઠ શું દર્શાવે છે તેના બદલે સેશન ખરેખર શું સંપર્ક કરે છે તેની યાદી બનાવો:

dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5

તુલના દરમિયાન રિઝોલ્વર દૃશ્યમાન રાખો, કારણ કે એક રિઝોલ્વરથી કામ કરતો અને બીજાથી નિષ્ફળ જતો નિયમ તમને CDNના જવાબ વિશે કહે છે, ટનલ વિશે નહીં. ટૂંકા TTLનો અર્થ એ પણ છે કે તમે નોંધેલા જવાબની મુદત છે.

દરેક પદ્ધતિ ખરેખર શું આવરે છે

બંને પદ્ધતિઓ સેટિંગ્સ પૃષ્ઠ પર અદલાબદલી દેખાય છે અને અંદરથી અલગ વર્તે છે.

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

એક પણ બીજાનો સુપરસેટ નથી, તેથી નોંધ વગર બંને મિશ્ર કરવાથી પછી મૂંઝવણ થાય છે.

સેવા બદલાયા પછી ફરી ચકાસો

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

કઈ પદ્ધતિ કયું હોસ્ટનામ આવરે છે અને છેલ્લે ક્યારે ચકાસ્યું તે લખો.

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