ડ્યુઅલ-સ્ટેક VPN: એડ્રેસ ફેમિલી ક્લાયન્ટ પસંદ કરે છે, તમે નહીં

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

પસંદગી એ કવરેજનું વચન નથી

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

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

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

વિનંતીએ ખરેખર કઈ ફેમિલી વાપરી તે શોધો

ટનલથી નહીં, નામથી શરૂ કરો. બંને પ્રકારના રેકોર્ડ પૂછો અને શું પાછું આવ્યું તે નોંધો:

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

જો v4 વિનંતી સફળ થાય અને v6 વિનંતી નિષ્ફળ જાય, તો તમે સમસ્યાને ડિબગ કરી શકાય તેવા સ્વરૂપમાં ફરી ઉત્પન્ન કરી છે. જો શેલમાંથી બંને સફળ થાય અને બ્રાઉઝર તોપણ નિષ્ફળ જાય, તો ટનલને અડકતા પહેલાં એપ્લિકેશનના પોતાના રિઝોલ્વર અથવા કેશ થયેલા જવાબ તપાસો.

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

તે ફેમિલી માટે માર્ગ તપાસો

નિષ્ફળ જતી ફેમિલી માટે કર્નલને પૂછો કે તે કયો માર્ગ વાપરશે અને તેની ટનલના ગોઠવેલા સરનામાંઓ સાથે સરખામણી કરો. Linux પર, ip -6 route get ગંતવ્ય માટે પસંદ થનાર ઇન્ટરફેસ અને સ્રોત બતાવે છે.

પછી ટનલ પોતે તપાસો. WireGuard પીઅર્સ માન્ય IP ની યાદી રાખે છે, અને 0.0.0.0/0 માટેની એન્ટ્રી IPv6 વિશે કંઈ કહેતી નથી. જો પીઅરની યાદીમાં IPv6 પ્રીફિક્સ ન હોય, તો ક્લાયન્ટને AAAA ટ્રાફિક ટનલમાં મોકલવાનું કોઈ કારણ નથી, અને પેકેટ હોસ્ટ અન્યથા જે કરે તે માર્ગે બહાર નીકળે છે.

ફાયરવોલ નિયમો અને NAT નીતિ દરેક ફેમિલી માટે એ જ તપાસને પાત્ર છે. IPv4 માટે લખાયેલો નિયમ કોઈપણ પ્લેટફોર્મ પર IPv6 આવરી લેતો નથી, અને એ જ સૌથી સામાન્ય કારણ છે કે એક ફેમિલી કામ કરે છે જ્યારે બીજી નહીં.

સ્ક્રીનશોટ સરળ બનાવવા IPv6 બંધ કરશો નહીં

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

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

ટિકિટમાં શું લખવું

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

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