પુનરાવર્તિત રૂટિંગ: જ્યારે ટનલ પોતાના જ પેકેટ પકડી લે
ટનલ તેને બનાવતા પેકેટને પકડી શકે છે. ડિફોલ્ટ રૂટ બદલતા પહેલાં અને પછી સર્વરનો માર્ગ સરખાવો, પછી તે માર્ગનો માલિક સુધારો.
ટનલ ઉપર આવે છે, લોગ પૂર્ણ થયેલો હેન્ડશેક બતાવે છે, અને એક સેકન્ડ પછી એ જ સત્ર મરી જાય છે અને લૂપમાં ફરી જોડાય છે. આ પેટર્નનું ચોક્કસ કારણ છે: સર્વરનો માર્ગ હવે ટનલની અંદર દર્શાવે છે, તેથી ટનલ વહન કરતા પેકેટ ટનલમાંથી જ મોકલાય છે. પ્રમાણીકરણમાં કંઈ બદલાયું નથી, તેથી ફરી લોગિન માહિતી દાખલ કરવાથી કોઈ ફરક પડતો નથી. રૂટ બદલતા પહેલાં અને પછી બહારનો માર્ગ સરખાવો, પછી પુનરાવૃત્તિ દેખાય જશે.
પહેલાં બહારનો માર્ગ તપાસો
રમતમાં બે પેકેટ છે, એક નહીં. અંદરનું પેકેટ એપ્લિકેશનનું છે અને તે એન્ક્રિપ્ટ થયેલું હોવું જોઈએ, જ્યારે બહારનું પેકેટ સર્વરને સંબોધાયેલું છે અને તેને ટનલ પર આધારિત ન હોય એવા માર્ગે ત્યાં પહોંચવું જોઈએ.
ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints
ટનલ ઉપર આવ્યા પછી કર્નલને સર્વરના સરનામાનો માર્ગ પૂછો, અને ડિફોલ્ટ રૂટ બદલાયા પછી ફરી પૂછો. જે આગળનો હોપ ટનલ ઉપકરણ પર આવી પડે છે તે જ પુનરાવૃત્તિ છે, અને તે કોઈપણ પેકેટ કેપ્ચર વિના દેખાય છે. ઇન્ટરફેસ બાઇન્ડિંગ, માર્ક કે નેટવર્ક નેમસ્પેસ સામાન્ય શોધને અધૂરી કરી શકે છે, તેથી ક્લાયન્ટ પોતે વાપરે છે તે સંદર્ભ વાપરો. જવાબ સાચો લાગે પણ સત્ર હજી લૂપમાં હોય તો, ફક્ત મુખ્ય ટેબલ નહીં, રૂટિંગ નીતિના નિયમો વાંચો.
સત્ર થોડી ક્ષણ કેમ ટકે છે
નવો રૂટ બેસાડ્યા પહેલાં હેન્ડશેક પૂરો થઈ જાય છે, તેથી પહેલી સેકન્ડો તંદુરસ્ત લાગે છે. ક્લાયન્ટ ડિફોલ્ટ રૂટ ઉમેરે છે એટલે આગળનું બહારનું પેકેટ તેની પાછળ તે ઇન્ટરફેસમાં જાય છે જેમાંથી તે બહારના પેકેટે પસાર થવું પડે છે. સર્વરને કંઈ દેખાતું નથી, ક્લાયન્ટ ફરી મોકલે છે, અને પ્રયાસ ક્યાં તો સમય પૂરો થઈને બંધ થાય છે ક્યાં તો સત્ર મારી નાખીને ફરી શરૂ કરે છે.
આ ક્રમ સમજાવે છે કે ટનલ લેપટોપ પર કેમ કામ કરે છે પણ રાઉટર પર નિષ્ફળ જાય છે, અને નિષ્ફળતા કેમ ઘણી વાર જોડાણ વખતે નહીં પણ ટ્રાફિક શરૂ થાય ત્યારે શરૂ થાય છે. તે લૂપ પણ સમજાવે છે: દરેક પુનઃપ્રારંભ તે સત્ર ફરી સ્થાપે છે, તે પહેલાં કે રૂટ તેને અશક્ય બનાવે.
એન્ડપોઇન્ટના અપવાદનો માલિક કોણ છે તે શોધો
સમર્થિત ક્લાયન્ટ પોતાનો અપવાદ ગોઠવે છે: મૂળ ગેટવે દ્વારા સર્વર સુધીનો હોસ્ટ રૂટ, અથવા એવો માર્ક જે બહારના સોકેટને ટનલની બહાર રાખે છે. પ્રશ્ન એ છે કે બીજું કંઈક તેને દૂર કર્યું કે તેના પર ચઢી ગયું.
રૂટ-આધારિત IPsec માં, કયા પેકેટ ટનલમાં પ્રવેશે તે નક્કી કરતા નીતિ-પસંદગીકર્તાઓ તપાસો અને ખાતરી કરો કે પીઅરનું સરનામું તેમાંથી બાકાત છે. WireGuard માં, ઇન્ટરફેસનો ફાયરવોલ માર્ક અને તેના નીતિ નિયમો પરિવહન પેકેટને ટનલની બહાર રાખે છે, તેથી જાતે ઉમેરાયેલો ડિફોલ્ટ રૂટ તે ગોઠવણ તોડી શકે છે. બીજી VPN પ્રોફાઇલ કે ડિફોલ્ટ રૂટ ફરી લખતી મેનેજમેન્ટ સ્ક્રિપ્ટ સામાન્ય રીતે દોષિત હોય છે. એક પછી એક ઉમેરાતા વિશાળ બાયપાસ નિયમો સામાન્ય પરિણામ છે, અને તે રૂટિંગ ભૂલને એવા ટેબલમાં ફેરવે છે જે કોઈ જાળવી શકતું નથી.
નેટવર્ક બદલાયા પછી ફરી તપાસો
Wi-Fi ગેટવે દ્વારા હોસ્ટ રૂટ ત્યાં સુધી સાચો છે જ્યાં સુધી મશીન બીજા નેટવર્ક પર ન જાય. પછી કોઈ રૂપરેખા બદલ્યા વિના એ જ લક્ષણ પાછું આવે છે.
એન્ડપોઇન્ટનું સરનામું, જોડાણ પહેલાં અને પછીનો રૂટ, અને દરેકે વાપરેલો ઇન્ટરફેસ નોંધો. આ ત્રણ હકીકતો સામાન્ય રીતે ક્લાયન્ટની ભૂલને ઓવરરાઇડથી અલગ પાડે છે, અને તેમને એકઠી કરનાર વ્યક્તિ ગયા પછી પણ ટકી રહે છે.
નવા નેટવર્ક પર ફરી જોડાઓ અને વાંચનનું પુનરાવર્તન કરો. અપવાદ ફરી ગેરહાજર હોય તો, સુધારો તે ધરાવતી પ્રોફાઇલમાં જ છે, વિક્ષેપ દરમિયાન લખાયેલી એક-વખતની આદેશમાં નહીં.