DNS ફેરફારો પછી પણ WireGuard જૂનું એન્ડપોઇન્ટ વાપરે છે

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

નામ એક જ વાર રિઝોલ્વ થાય છે, સતત નહીં

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

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

રેકોર્ડની સરખામણી વપરાતા સરનામા સાથે કરો

ક્લાયન્ટ જે રિઝોલ્વર વાપરે છે તેના દ્વારા દસ્તાવેજીકૃત નામ પૂછો, પછી ઇન્ટરફેસને પૂછો કે તે કયું એન્ડપોઇન્ટ રાખે છે. બે જવાબો એ સરખામણી છે જે આ પૃષ્ઠનો બાકીનો ભાગ નક્કી કરે છે:

dig +short vpn.example.net
wg show wg0 endpoints
wg show wg0 latest-handshakes

આ લીટીઓ જે show સબકમાન્ડ વાપરે છે તે wg(8) મેન્યુઅલ તેમને દસ્તાવેજીકૃત કરે છે. સરનામા સાથે સરનામાની ફેમિલી પણ સરખાવો, કારણ કે IPv6 એન્ટ્રી મેળવનાર રેકોર્ડ એ IPv4 સરનામું બદલાયેલા રેકોર્ડ કરતાં અલગ સરખામણી છે. જો એન્ડપોઇન્ટ રેકોર્ડથી અલગ હોય, તો ઇન્ટરફેસ જૂની માહિતી પર ચાલે છે અને નામ ક્યારેય સમસ્યા ન હતું. જો બંને મળે અને ટનલ હજી નિષ્ફળ જાય, તો પ્રોફાઇલને બદલે લિસનર અને નિયમો તરફ જાઓ.

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

ઇન્ટરફેસના મેનેજર દ્વારા ફરી શરૂ કરો

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

wg-quick down wg0 && wg-quick up wg0
systemctl restart wg-quick@wg0

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

પહેલાં હેન્ડશેક, પછી ડેટા માર્ગ

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

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