સમાન ખર્ચનાં રૂટ VPN ની ખામીઓને કેમ દેખાવી મુશ્કેલ બનાવે છે
જ્યારે ઘણા ટનલ એક જ ખર્ચ વહેંચે છે, ત્યારે દરેક ફ્લો અલગ પસંદ કરી શકે છે. સફળ ping તમારી એપ્લિકેશન ખરેખર જે માર્ગ વાપરે છે તે વિશે કંઈ કહેતું નથી.
એક વપરાશકર્તા જણાવે છે કે આંતરિક એપ્લિકેશન એક મશીનથી કામ કરે છે અને બીજાથી નિષ્ફળ જાય છે, જ્યારે ગેટવેથી ચલાવેલો ping બંને કિસ્સામાં સફળ થાય છે. સમાન ખર્ચની ઘણી ટનલ હોય ત્યારે આ વિરોધાભાસ નથી. દરેક ફ્લો પોતાના આગળના હોપ પર મૂકવામાં આવે છે, તેથી તમારી તપાસ અને વપરાશકર્તાનું સત્ર ફક્ત જુદા માર્ગો વાપરી શકે છે. નીચેની ચર્ચા કંઈપણ બદલતા પહેલાં આ પસંદગી ફરી ઉત્પન્ન કરે છે.
એક ping, ઘણા શક્ય માર્ગ
જ્યારે કોઈ રૂટમાં સમાન ખર્ચે એકથી વધુ આગળનો હોપ હોય, ત્યારે રાઉટરે દરેક પેકેટ માટે એક પસંદ કરવો પડે. મોટાભાગનાં અમલીકરણો પેકેટનાં ક્ષેત્રોનું હેશ કરે છે, સામાન્ય રીતે સ્રોત અને લક્ષ્ય સરનામાં સાથે પ્રોટોકોલ અને પોર્ટ, જેથી પ્રતિભાવો એક જ માર્ગ પર રહે. જુદી એપ્લિકેશનો, અથવા એક જ એપ્લિકેશનના જુદા જોડાણો પણ જુદા હેશ બનાવે છે.
તેથી ગેટવેથી લીધેલ નિદાન ખૂબ ઓછું સાબિત કરે છે. ગેટવેની પોતાની તપાસને પોતાનાં સરનામાં અને પોર્ટ હોય છે, અને તેથી પોતાનો હેશ. તે સ્વસ્થ ટનલ પર ઊતરી શકે છે જ્યારે વપરાશકર્તા તૂટેલી ટનલ પર ઊતરતો રહે છે.
પ્લેટફોર્મ આગળનો હોપ કેવી રીતે પસંદ કરે છે
અનુમાન કરવાને બદલે પસંદગી ફરી ઉત્પન્ન કરો. કર્નલને પૂછો કે નિષ્ફળ સત્ર જેવા જ સ્રોત અને લક્ષ્ય માટે તે કયો રૂટ વાપરશે. એ શોધમાં એવાં ક્ષેત્રો સામેલ છે જે સામાન્ય લક્ષ્ય-શોધ અવગણે છે. તેને કાર્યરત ક્લાયન્ટથી પણ ચલાવો અને બંને જવાબ સરખાવો:
ip route get 10.20.5.7 from 10.20.0.14નવી iproute2 આવૃત્તિઓ પ્રોટોકોલ અને લક્ષ્ય પોર્ટ પણ સ્વીકારે છે, જે ત્યારે મહત્ત્વનું છે જ્યારે હેશમાં તે સામેલ હોય. એ આઉટપુટને કાર્યરત ક્લાયન્ટની એ જ શોધ સાથે સરખાવો, અને તફાવત એ જ તમારો ખૂટતો પુરાવો છે.
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
નિષ્ફળ ફ્લોને અનુસરો, રૂટ કોષ્ટકને નહીં
રૂટ કોષ્ટક બંને ટનલની યાદી આપે છે અને વ્યાખ્યા પ્રમાણે સાચું લાગે છે. પ્રશ્ન એ છે કે પસંદ થયા પછી દરેક ટનલ પેકેટ સાથે શું કરે છે. ચકાસો કે બંને એ જ સુરક્ષિત પ્રીફિક્સ, એ જ ફોરવર્ડિંગ પરવાનગી અને એ જ ક્લાયન્ટ સુધી પહોંચતો પરત માર્ગ ધરાવે છે.
વચ્ચેનાં સ્થિતિધારી ઉપકરણો પર ધ્યાન આપો. જો વિનંતી એક ટનલમાંથી નીકળે અને જવાબ બીજીમાંથી પાછો આવે, તો જેણે મૂળ ફ્લો કદી જોયો નથી તેવું ફાયરવોલ અથવા NAT તેને કાઢી નાખશે. બંને ટનલ ટ્રાફિક યોગ્ય રીતે ફોરવર્ડ કરે છે, અને કનેક્શન તોપણ નિષ્ફળ જાય છે.
દરેક માર્ગ માટે MTU પણ તપાસો. વધારાની એન્કેપ્સ્યુલેશનવાળો માર્ગ વપરાયોગ્ય કદ ઘટાડે છે, અને એક ટનલ પર સફળ થતું સ્થાનાંતરણ બીજી પર બરાબર એ જ કદ પર અટકે છે જ્યાં નાની ટનલ તૂટે છે.
એક વખતે એક માર્ગ સરખાવો
જ્યાં રચના જાળવણીની મંજૂરી આપે, ત્યાં એક ટનલ સેવામાંથી દૂર કરો અને વપરાશકર્તાનું કાર્ય ફરીથી કરો. જો ખામી અદૃશ્ય થાય, તો સમસ્યા દૂર કરેલા માર્ગની છે, અને આગળનું પગલું રૂટિંગ કોષ્ટક ફરી તપાસવાને બદલે તેની ગોઠવણી પાડોશી સાથે સરખાવવાનું છે.
વારંવારના ping નહીં, વાસ્તવિક એપ્લિકેશન સરખાવો. નોંધો કે ખામી કોઈ ચોક્કસ આગળના હોપ, પેકેટના કદ કે ફરી જોડાયા પછીના પરિવર્તનને અનુસરે છે કે નહીં, કારણ કે એ ત્રણ પેટર્ન જુદા સમારકામ તરફ ઇશારો કરે છે.
છેલ્લે, લખો કે માર્ગોને સમકક્ષ કેમ ગણવામાં આવે છે અને ખામીએ કેવી રીતે એકને સેવામાંથી દૂર કરવું જોઈએ. મલ્ટિપાથ ફક્ત ત્યારે જ સુરક્ષિત છે જ્યારે માર્ગો ખરેખર અદલાબદલી કરી શકાય તેવા હોય, અને એ ધારવાને બદલે ચકાસવા લાયક ડિઝાઇન-વિધાન છે.