કયો NAT હોપ નિષ્ક્રિય VPN મેપિંગ ગુમાવે છે અને તે કેવી રીતે ઓળખવું
નિષ્ક્રિય VPN પ્રવાહ કોઈપણ સ્થિતિ રાખતા હોપ પર મરી શકે છે. એક પરીક્ષણનું પુનરાવર્તન કરો, દરેક સીમાએ શું જોયું તેની તુલના કરો અને અનુમાનિત દોષિતને બદલે મર્યાદિત પરિણામની જાણ કરો.
શાંત સમયગાળા પછી ટનલ ફરી જોડાય છે, કોઈ લોગ દોષિતનું નામ લેતું નથી, અને સ્પષ્ટ પગલું એ છે કે સૌથી પ્રભાવશાળી ટાઇમઆઉટ દસ્તાવેજીકરણ ધરાવતું ઉપકરણ પસંદ કરવું. તે નિદાનનો વેશ પહેરેલું અનુમાન છે. સ્થિતિ થોડા સમય માટે ઘરેલું રાઉટરમાં, ઓપરેટરના અનુવાદકમાં અને ક્લાઉડ ધાર પર ટકી શકે છે, અને તેમાંથી કોઈપણ શાંત થઈ ગયેલો પ્રવાહ પડી ભાંગી શકે છે. તેના બદલે તમે જે કરી શકો તે છે માર્ગનું નકશો બનાવવો, કયા ઉપકરણોને તમે ખરેખર અવલોકી શકો તે ચિહ્નિત કરવું અને એક નિષ્ક્રિય પરીક્ષણ ચલાવવું જેનું તમે પુનરાવર્તન કરી શકો.
પુનરાવર્તનક્ષમ પરીક્ષણ કથાને માપમાં બદલે છે. નીચેનું બધું એક ક્લાયન્ટ, એક સર્વર અને એક પ્રોટોકોલ ધારે છે, અને ધારે છે કે તમે એક સાથે બે ચલ બદલવાનો પ્રતિકાર કરો છો. હેતુ એ છે કે આગલી ઘટના આ એક કરતાં સસ્તી થાય.
દર વખતે એ જ નિષ્ક્રિય પરીક્ષણ કરો
લખો કે પ્રવાહ છેલ્લે ક્યારે સારો હતો, પછી કેટલો સમય નિષ્ક્રિય રહ્યો, અને એક તાજા પેકેટે તેને પાછો લાવ્યો કે નહીં. તે ત્રણ તથ્યો જ માપ છે; તેમના વિના તમારી પાસે પડી ગયેલા લેપટોપની વાર્તા છે. દરેક પુનરાવર્તનમાં એ જ ક્લાયન્ટ, એ જ સર્વર અને એ જ પ્રોટોકોલ વાપરો, અને નીરવતા પછી પ્રથમ પેકેટ મોકલાયો તે ક્ષણ નોંધો.
પછી તમારી માલિકીની દરેક સીમાએ ખરેખર શું જોયું તેની તુલના કરો. તપાસ નક્કી કરતો ભેદ એ છે કે સર્વરે વિરામ પછી કંઈ જ જોયું નહીં, કે પછી વિનંતી જોઈ અને એવા માર્ગમાં જવાબ આપ્યો જે હવે જવાબો લઈ જતો ન હતો.
| What you observe | What it suggests | What it does not prove |
|---|---|---|
| server records no packet after the pause | state was lost upstream of the server | which hop dropped it |
| server answers, client never receives | return-path state or filtering | that the timer belongs to the client |
| client sends nothing at all | client-side timer or application behaviour | that the network path is healthy |
પાંચ વસ્તુઓ બદલ્યા વિના માર્ગોની તુલના
બીજું મંજૂર ઍક્સેસ નેટવર્ક કાયદેસર તુલના છે, કારણ કે NAT શૃંખલા અલગ છે. તે પ્રદાતા, રેડિયો પરિસ્થિતિ અને કદાચ સરનામા કુટુંબમાં પણ અલગ છે, તેથી પરિણામ સીમા છે, આરોપ નહીં. જાણ કરતી વખતે મર્યાદાઓને ચૂપચાપ છોડી દેવાને બદલે પરિણામ સાથે નોંધો. માર્ગ પણ લખો: ઉપકરણ, ભૂમિકા, અને તેની સ્થિતિ બિલકુલ વાંચી શકાય છે કે નહીં.
માર્ગોની તુલના તમને મર્યાદિત પ્રશ્ન આપે છે: પ્રવાહ એક પર ટકી રહે છે અને બીજા પર સમાન નીરવતા પછી મરી જાય છે, તેથી ચલ અલગ પડતા ભાગોમાં ક્યાંક રહે છે. કોઈ ઉપકરણનું નામ ન હોવા છતાં આ વાસ્તવિક પરિણામ છે, અને તે આગલા ઇજનેરને કહે છે કે બપોર ક્યાં ગાળવી અને ક્યાં નહીં.
ઓપરેટરો વિશે અનુમાન કરતાં પહેલાં સ્થાનિક સ્થિતિ વાંચવા જેવી છે. Linux ગેટવે પર conntrack -L ટ્રૅક થયેલા પ્રવાહોને તેમના બાકીના આયુષ્ય સાથે સૂચિબદ્ધ કરે છે, જે ટાઇમર વિશેના અનુમાનને એવી સંખ્યામાં ફેરવે છે જેને તમે પૂરી થતી જોઈ શકો. તેને નિષ્ક્રિય સમયગાળા પહેલાં અને પછી વાંચો, ફક્ત પછી નહીં.
કીપઅલાઇવ શું ટકાવશે અને શું નહીં
સમર્થિત કીપઅલાઇવ મેપિંગ ખુલ્લું રાખે છે, અને મેપિંગ ખુલ્લું રાખવું તેની પાછળની સેવા વિશે કંઈ સાબિત કરતું નથી. ટનલ મેપ થયેલી રહી શકે છે જ્યારે તે જે એપ્લિકેશન વહે છે તે જવાબ આપવાનું બંધ કરી ચૂકી હોય, અને સ્થિતિ દીવા પરથી આ બે પરિસ્થિતિઓ સરખી દેખાય છે. કીપઅલાઇવને નિષ્ક્રિય સમાપ્તિ સામે વીમા તરીકે ગણો, આરોગ્ય તપાસ તરીકે નહીં.
અંતરાલ તમે ખરેખર માપેલા સૌથી ટૂંકા ટાઇમઆઉટ પ્રમાણે સેટ કરો, ફોરમ પરથી કોપી કરેલી સંખ્યા પ્રમાણે નહીં. દરેક સંભવિત ટાઇમરની નીચે ટ્યુન કરેલો કીપઅલાઇવ એ ટ્રાફિક છે જે કોઈને જરૂર ન હતી, અને તે એ લક્ષણ પણ દૂર કરે છે જે તમને કહેત કે કઈ સીમા પહેલા સમાપ્ત થાય છે. માપેલી સંખ્યામાંથી અંતરાલ પસંદ કરો અને બાકીનું બધું શાંત રહેવા દો.
એક ફેરફાર, પછી ફરી માપો
લાઇવ પરીક્ષણ દરમિયાન દરેક ટાઇમઆઉટ વધારવાની અને દરેક ગેટવે ફ્લશ કરવાની ઇચ્છાનો પ્રતિકાર કરો. તે તમે જેના માટે આવ્યા તે પુરાવા ભૂંસી નાખે છે અને બીજા લોકોના પ્રવાહોમાં વિક્ષેપ પાડે છે, જે પરીક્ષણ ન કરેલી પરિકલ્પના માટે ખરાબ સોદો છે. એક ઉપકરણ પર એક સમર્થિત સેટિંગ બદલો, પછી નિષ્ક્રિય સમયગાળો અને એપ્લિકેશનની પુનઃપ્રાપ્તિનું પુનરાવર્તન કરો.
કયું સીમા-અવલોકન ખસ્યું તે નોંધો, અને કંઈ સુધર્યું ન હોય તો પણ નોંધો. જે સેટિંગે કંઈ સુધાર્યું નહીં તે માહિતી છે, અને એક વાર ધ્યાનમાં લેવું આખા એસ્ટેટ પર ફેરવવા કરતાં સસ્તું છે.
એવી શોધ લખવી જેનો તમે બચાવ કરી શકો
જ્યારે ઉપરના પ્રવાહનો અનુવાદક નિરીક્ષણ કરી શકાતો નથી, ત્યારે ફક્ત તે જ કહો જે પુરાવા ટેકો આપે છે: આદાનપ્રદાન માર્ગના આ ભાગ પર ક્યાંક આટલી નીરવતા પછી મરી જાય છે, અને જવાબદાર હોપ અનાવટ થયેલો જ રહે છે. મર્યાદિત વિધાન સમીક્ષામાં ટકી રહે છે અને આગલી વ્યક્તિને યોગ્ય સેગમેન્ટ તરફ દોરે છે. છુપાયેલા રાઉટરને કારણ ગણાવવાથી આ બેમાંથી એક પણ થતું નથી. મર્યાદિત શોધ અંતરાલ સાથે જેની પાસે અવલોકન ન કરી શકાય તેવો સેગમેન્ટ છે તેને આપો.
RFC 4787 સમજાવે છે કે UDP મેપિંગ ટાઇમરને એક અંત્ય બિંદુથી અનુમાન કરવું કેમ મુશ્કેલ છે, અને એ જ મુશ્કેલી મર્યાદિત શોધને પ્રામાણિક બનાવે છે. ટાઇમર વાસ્તવિક છે, અને તેમની આસપાસની અનિશ્ચિતતા પણ.