તમારો સ્પ્લિટ-ટનલ નિયમ કોઈ સેવા સાથે મેળ ખાવાનું કેમ બંધ થયું

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

નિયમ શું પિન કરે છે અને DNS શું પરત આપે છે

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

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

મેળ તૂટવાની ત્રણ રીતો

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

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

એપ ખરેખર જે ગંતવ્ય વાપરે છે તે વાંચો

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

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

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

મિકેનિઝમ સુધારો, લક્ષણ નહીં

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

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

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

ઉદ્દેશના બંને અર્ધ ચકાસો

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

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

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