જ્યારે સ્પ્લિટ-ટનલ માર્ગો ઓવરલેપ થાય: કયો પ્રીફિક્સ જીતે

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

1. ગંતવ્ય અને સ્રોત લખો

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

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

2. કર્નેલને પૂછો કે તેણે કયો માર્ગ પસંદ કર્યો

રૂટ કોષ્ટક વાંચીને જવાબ અનુમાન ન કરો. સ્ટેક જે પ્રશ્ન પૂછે છે એ જ પ્રશ્ન એ જ સ્રોત સરનામા સાથે પૂછો: Linux પર ip route get 10.20.4.10 from 10.8.0.2, અથવા PowerShell માં Find-NetRoute -RemoteIPAddress 10.20.4.10. આઉટપુટ એ માર્ગનું નામ આપે છે જે ખરેખર વપરાયો હોત, અને તે ઘણી વાર એ નથી હોતો જે કોષ્ટક વાંચતી વખતે તમે ધાર્યો હતો.

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

3. ચકાસો કે નીતિ નિયમે શોધને બીજે વાળી છે કે નહીં

રૂટ કોષ્ટક જોવાય તે પહેલા, કર્નેલ તેના નીતિ નિયમોમાંથી પસાર થાય છે. નિયમ આપેલા સ્રોત, વપરાશકર્તા અથવા ફાયરવોલ માર્કનું ટ્રાફિક સંપૂર્ણ બીજા કોષ્ટકમાં મોકલી શકે છે, તેથી મુખ્ય કોષ્ટકનું જીતતું પ્રીફિક્સ એ પ્રવાહ માટે કદી જોવાય જ નહીં. ip rule show તેમને મૂલ્યાંકન ક્રમમાં સૂચિબદ્ધ કરે છે, અને ip route show table 100 દર્શાવે છે કે પસંદ કરેલા કોષ્ટકમાં ખરેખર શું છે.

અહીં બે જાળ છે. ખાલી કોષ્ટક તરફ ઇશારો કરતો નિયમ એવી શોધ બનાવે છે જે આગલા નિયમ પર પડી જાય છે, તેથી નિયમ કંઈ કરતું ન હોય તેમ લાગે છે. બીજી જાળ પ્રાયોરિટી નંબર પોતે છે: નિયમો ચઢતા ક્રમમાં વંચાય છે, અને અંતર્નિર્મિત મૂલ્યો 0 local, 32766 main અને 32767 default છે. 32767 થી નીચે નંબર ધરાવતો નિયમ બધું પકડતા ડિફોલ્ટ નિયમ પહેલા જોવાય છે. 32767 થી ઉપર નંબર ધરાવતો નિયમ તેની પાછળ બેસે છે અને ત્યારે જ પહોંચાય છે જ્યારે પહેલું કોઈ કોષ્ટક જવાબ ન આપે, જેને main માંનો સામાન્ય ડિફોલ્ટ માર્ગ અટકાવે છે, તેથી વ્યવહારમાં તે કદી પહોંચાતો નથી અને સ્થાપિત દેખાતો હોવા છતાં ચૂપચાપ કંઈ કરતો નથી. જો ક્લાયન્ટે નિયમ અને માર્ગ બંને લખ્યા હોય, તો બંને તપાસો, અને ફરી જોડાણ પછી ફરી તપાસો, કારણ કે ફરીથી લખાયેલી પ્રોફાઇલ અલગ પ્રાયોરિટીવાળો બીજો નિયમ ઉમેરી શકે છે.

4. રૂટિંગ ટાઈને ડુપ્લિકેટ સરનામા યોજનાથી અલગ કરો

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

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

5. ખાતરી કરો કે રિઝોલ્વર માર્ગ સાથે સંમત છે

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

રિઝોલ્વરને સીધું પૂછો અને જવાબ આપનાર સર્વર નોંધો. ટૂંકા TTL સાથેનો કેશ જવાબ પણ સમજાવી શકે છે કે ફરી જોડાણ પછીની પહેલી વિનંતી પાંચમીથી અલગ કેમ વર્તે છે.

6. ફરી જોડાઓ, લાગુ થયેલી સ્થિતિ તપાસો, પછી બંને પ્રવાહ ચકાસો

સુધારા પછી, ફરી જોડાઓ અને પ્રોફાઇલ એડિટર પર ભરોસો કરવાને બદલે ક્લાયન્ટે ખરેખર શું સ્થાપિત કર્યું તે તપાસો. નિયમો, કોષ્ટકો અને પરિણામી ip route get જવાબ ફરી વાંચો. બીજો ક્લાયન્ટ જોડાતી વખતે પોતાનો માર્ગ ફરી સ્થાપિત કરી શકે છે અને સંઘર્ષ ફરી ઊભો કરી શકે છે, તેથી સ્થિતિ તપાસ છેલ્લા ક્લાયન્ટના જોડાણ પછી થવી જોઈએ, તેના પહેલા નહીં.

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