WireGuard નિષ્ક્રિયતા પછી નિષ્ફળ જાય છે: પહેલાં દિશા ચકાસો

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

કઈ દિશા નિષ્ફળ જાય છે?

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

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

wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

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

ઊંઘ, રેડિયો અને એપ્લિકેશનની સ્થિતિ

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

નિષ્ક્રિય સમયગાળા પછી ખુલ્લું રહી ગયેલા ટૅબ પર ભરોસો ન કરતાં એપ્લિકેશન ફરી ખોલો. જ્યાં જૂનું સત્ર નિષ્ફળ ગયું ત્યાં નવી વિનંતી સફળ થાય, તો ટનલ ક્યારેય સમસ્યા ન હતી.

keepalive ખરેખર શું કરે છે

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

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

પહેલાં નિષ્ફળ જતું અંતરાલ પસાર થવા દો

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

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