WireGuard કોઈ નવીનતમ હેન્ડશેક બતાવતું નથી: પહેલાં શું તપાસવું

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

પરીક્ષણ એ peer એ વહન કરવાનું હોય તેવા ગંતવ્ય તરફનું માન્ય પેકેટ છે. તે સ્થિતિ સ્ક્રીન પરનું બાકીનું બધું પ્રવૃત્તિને નહીં, ઉદ્દેશને વર્ણવે છે.

નિષ્ક્રિય ઇન્ટરફેસ પાસે જણાવવા જેવું કંઈ નથી

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

જો બંને બાજુ કાઉન્ટર શૂન્ય પર હોય, તો સમસ્યા ટનલની ઉપર છે. ઇન્ટરફેસ સુધી કંઈ પહોંચ્યું નહીં જે કંઈક શરૂ કરે.

peer ને વહન કરવાની પરવાનગી હોય તેવો ટ્રાફિક ટ્રિગર કરો

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

ip route get 10.60.9.5
ping -c 3 -W 2 10.60.9.5
wg show wg0 latest-handshakes
wg show wg0 transfer

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

કી જોડી અને એન્ડપોઇન્ટની સરખામણી કરો

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

એન્ડપોઇન્ટને પણ એ જ તપાસ જોઈએ: હોસ્ટનામ, સરનામું, UDP પોર્ટ અને ત્યાં પહોંચવા માટે વપરાતું કુટુંબ. જૂનું સરનામું કે ખોટો પોર્ટ સંદેશને બદલે મૌન આપે છે.

બાહ્ય UDP માર્ગ પર નજર રાખો

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

ss -lunp | grep 51820
sudo tcpdump -ni eth0 udp port 51820
wg show wg0 endpoints
conntrack -L -p udp | grep 51820

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

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