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

એમને એક જ સ્થિતિ તરીકે વાંચવું એ જ બે મિનિટની નિદાનને આખી બપોરની સેવા પુનઃશરૂ કરવામાં ફેરવે છે.

હેન્ડશેક પીઅરની ઘટના છે, સરનામાંની ઘટના નહીં

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

તેથી જ wg show એવા ઇન્ટરફેસ પર સેકન્ડો જૂનો હેન્ડશેક જાણ કરી શકે છે જે એપ્લિકેશનનું એક પણ પેકેટ સ્વીકારી શકતું નથી.

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

ObservationWhich layer it belongs toWrong conclusion it invites
Handshake a few seconds oldPeer and keysThe tunnel is usable for application traffic
Address present on wg0Interface configurationTraffic actually egresses through it
Route points at wg0Forwarding tableThe outer packet uses the intended uplink

ઇન્ટરફેસના સરનામાનો પોતાનો માલિક છે

ટનલ ઉપકરણ પરનું સરનામું સહાયકની Address લાઇનમાંથી, ઇન્ટરફેસ પર ચાલતા DHCP ક્લાયન્ટમાંથી, અથવા જોડાણ સમયે તેને બનાવતા વ્યવસ્થાપન ડિમનમાંથી આવી શકે છે. જે પણ હોય, એ ઘટક સરનામાનો માલિક છે અને પોતાના તર્ક મુજબ તેને પુનઃસ્થાપિત કરશે કે નહીં. માલિકનું નામ લીધા વિના સરનામું વાંચવાથી તે કેમ અદૃશ્ય થયું તે સમજાવી શકશો નહીં.

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

એક માલિક પસંદ કરો અને બીજા સાધનને સંચાલનને બદલે નિરીક્ષણ કરવા દો. એ નિર્ણય લખવા યોગ્ય છે, કારણ કે લક્ષણ અઠવાડિયાં પછી દેખાય છે અને અવ્યવસ્થિત સરનામું ગુમાવવા જેવું લાગે છે.

રૂટ અપલિંક પસંદ કરે છે, ઇન્ટરફેસ નહીં

wg0 તરફ નિર્દેશ કરતો આંતરિક રૂટ નક્કી કરે છે કે ટ્રાફિક ટનલમાં પ્રવેશે છે. અલગ નિર્ણય એન્ક્રિપ્ટ થયેલા બાહ્ય પેકેટને પીઅર તરફ મોકલે છે, અને ઘણી અપલિંક ધરાવતા હોસ્ટ પર એ નિર્ણય ફોરવર્ડિંગ ટેબલ અને નીતિ નિયમોમાંથી આવે છે. Wi-Fi રોમિંગ આંતરિક સરનામાને અડ્યા વિના બાહ્ય માર્ગ બદલી શકે છે.

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

ત્રણ સ્થિતિઓની એક જ પાસમાં સરખામણી કરો

ત્રણ ફક્ત-વાંચન આદેશો ત્રણ પ્રશ્નોના જવાબ એ ક્રમમાં આપે છે જે નિષ્ફળતાને સૌથી ઝડપથી અલગ કરે છે. તેમને વચ્ચે કંઈ બદલ્યા વિના ચલાવો.

ip address show dev wg0
ip route get 10.80.0.1
wg show wg0 latest-handshakes transfer

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

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

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

સંબંધિત લેખો