તમારા IPv6 ટનલ પીઅરનું ping નિષ્ફળ? :: સરનામું તપાસો

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

જે લક્ષણ સરનામા તરફ ઇશારો કરે છે

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

બધા-શૂન્ય ઓળખકર્તા anycast તરીકે અનામત છે

RFC 4291 બધા-શૂન્ય ઇન્ટરફેસ ઓળખકર્તાને સબનેટ-રાઉટર anycast સરનામા તરીકે રાખે છે, તેથી /64 જેવું 2001:db8:4a::/64 માં કોઈ વપરાયોગ્ય હોસ્ટ નથી 2001:db8:4a::. આ અનામત પોતાનું સ્થાન યોગ્ય ઠેરવે છે: રાઉટર જાહેરાતો અને પડોશી શોધ તે સ્વરૂપને સંબોધે છે, અને રાઉટર જે પ્રીફિક્સ પર સેવા આપે છે તેના વતી જવાબ આપે છે. તે મૂલ્ય ટનલ છેડાને સોંપવાથી એક પર્ણને રાઉટરની ભૂમિકા મળે છે, અને તેથી જ કંઈ પાછું આવતું નથી. પ્રીફિક્સમાંનો બીજો કોઈ પણ ઓળખકર્તા હોસ્ટ તરીકે કામ કરે છે, તેથી સુધારો સામાન્ય રીતે એક અંકનો હોય છે.

આ અનામતને એવી ભૂમિકા તરીકે ગણો જે ટનલ છેડેથી લેવાનો તમને હક નથી, રૂટ વડે ટાળવાની વિચિત્રતા તરીકે નહીં.

હોસ્ટ સરનામાં સોંપો અને પ્રીફિક્સ રૂટ કરો

બે છેડા માટે ::1 અને ::2 પસંદ કરો, એક ઉમેરો ip -6 addr add 2001:db8:4a::2/64 dev tun0, અને પછી દૂરના પ્રીફિક્સને સરનામું આપવાનો પ્રયાસ કરવાને બદલે તેને રૂટ કરો. 2001:db8:4a::/64 માટે ટનલમાંથી નીકળતો રૂટ દૂરના ભાગને પહોંચયોગ્ય બનાવે છે; એકલું સરનામું માત્ર સ્થાનિક ઇન્ટરફેસને ગોઠવે છે.

સંપૂર્ણ ટનલ માટે ત્રીજું પગલું છે, ઉપકરણ દ્વારા ગ્લોબલ unicast માટે ડિફૉલ્ટ રૂટ, જે બધું ટનલમાં મોકલવાનું IPv6 સમકક્ષ છે. તેને છોડી દો તો IPv4 ટનલની અંદર મુસાફરી કરે છે ત્યારે IPv6 ભૌતિક લિંક વાપરવાનું ચાલુ રાખે છે, તેથી હોસ્ટ બરાબર એ જ ટ્રાફિક લીક કરે છે જે તમે ઢંકાયેલું માન્યું હતું. આની પુષ્ટિ કરો ip -6 route get 2001:4860:4860::8888 અને જવાબ ધારવાને બદલે તે કયું ઉપકરણ નામ આપે છે તે વાંચો.

રૂટિંગ પહેલાં multicast નકારવામાં આવે છે

Android VpnService.Builder માટે સરનામાં અને રૂટ LinkAddress દ્વારા માન્ય કરે છે, અને તે કન્સ્ટ્રક્ટર multicast સીધું જ નકારે છે. તેને રૂટ તરીકે multicast પ્રીફિક્સ આપો તો પરિણામ રૂટ નહીં, પણ ખરાબ LinkAddress પરિમાણોની નિષ્ફળતા હોય છે, જે માન્યતાનો જવાબ છે, નેટવર્કનો નહીં. આ નકાર માધ્યમ સાથે મેળ ખાય છે: પોઇન્ટ-ટુ-પોઇન્ટ tun ઉપકરણમાં લિંક-સ્તરીય multicast નથી, તેથી તેના પરના જૂથ રૂટ પાસે સ્થાપિત કરવા માટે કોઈ ડિલિવરી મોડેલ નથી. જૂથ સરનામાં સ્ટેક પોતે બનાવે છે અને વાપરે છે, હાથે ગોઠવાતાં નથી.

IPv6 all-nodes અને solicited-node સરનામાં એ જ નિયમ હેઠળ આવે છે. ઇન્ટરફેસ તેમને વહન કરે છે કારણ કે સ્ટેકે તેમને ત્યાં મૂક્યાં છે, કોઈ નીતિનો ઇરાદો હતો તેથી નહીં.

ટનલ તેના બદલે શું વહન કરી શકે

ટનલ આરપાર multicast શોધ ખસેડવા માટે જૂથ સભ્યપદ સમજતું સ્તર જોઈએ: Ethernet સેગમેન્ટ રજૂ કરતો TAP બ્રિજ, એપ્લિકેશન-સ્તરીય રિલે, અથવા એવો રૂટિંગ પ્રોટોકોલ જેને સ્પષ્ટ કહેવાયું હોય કે કયા પીઅર્સને નકલ કરવી. VpnService મોડેલમાં આમાંથી કંઈ નથી, જ્યાં એપ્લિકેશન પેકેટ વાંચે-લખે છે અને ટનલ માટે જૂથમાં જોડાતું કોઈ કૉલ નથી. કાં તો જૂથ સમજતો ઘટક ઉમેરો, અથવા ડિઝાઇનમાંથી આ આવશ્યકતા કાઢી નાખો.

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

કંઈ પણ સોંપતાં પહેલાં ત્રણ તપાસ

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

પ્લેટફોર્મે કદી સ્થાપિત ન કરેલો રૂટ વધુ વાર રાહ જોઈને ડિબગ કરી શકાતો નથી, અને જે સરનામું કદી હોસ્ટ ન હતું તે વધુ સારા ping થી સુધારી શકાતું નથી.