IPv6 tunelaren bikotekidearen ping-ak huts egiten du? Egiaztatu :: helbidea

Zure IPv6 tunelaren mutur batek besteari ping egiten dio, eta norabide bakarra erantzuten du beti. Interfazea aktibo dago, bidea zuzena dirudi, eta erregistroan ezerk ez du hori azaltzen. Esleitu duzun helbidea azpisarearen router-aren anycast helbidea da, ez da inolaz ere host helbidea, eta bi muturreko lotura batean helburu bakarra du entregatzeko: igorlea. Inolako timeout baliok ez du konpontzen, helbideak ez baitu uste duzuna egiten.

Helbidera seinalatzen duen sintoma

Loturako host guztiek erantzuten dute, interfaze-identifikatzailea zero hutsa duenak izan ezik. Forma horretara zuzendutako paketea azpisareko router batera entregatzen da definizioz, beraz puntutik puntuko tunel batean bidali zuen makinara itzultzen da. Urrutiko muturretik bikotekide iristezina bezala irakurtzen da; hurbileko muturretik isiltasun bezala. Prefijo bereko beste identifikatzaile bat sartu eta sintoma desagertu egiten da beste aldaketarik gabe, eta hori da bideak ukitu aurretik lortu behar duzun berrespena.

Zero guztiz osatutako identifikatzailea anycast gisa erreserbatuta dago

RFC 4291-ek zero guztiz osatutako interfaze-identifikatzailea azpisarearen router-aren anycast helbide gisa gordetzen du, beraz /64 batek, adibidez 2001:db8:4a::/64 ez du host erabilgarririk 2001:db8:4a:: helbidean. Erreserbak bere lekua merezi du: router iragarkiek eta auzokideen aurkikuntzak forma hori zuzentzen dute, eta router batek zerbitzatzen duen prefijoaren erantzuna ematen du. Balio hori tunel baten muturrari esleitzeak router rola host soil bati ematen dio, eta horregatik ez da ezer itzultzen. Prefijoko beste edozein identifikatzaile host gisa dabil, beraz konponketa normalean digitu bat da.

Trata ezazu erreserba tunelaren muturretik hartzeko eskubiderik ez duzun rol gisa, bide batekin saihesteko bitxikeria gisa baino.

Esleitu host helbideak eta bideratu prefijoa

Aukeratu ::1 eta ::2 bi muturretarako, gehitu bat honekin: ip -6 addr add 2001:db8:4a::2/64 dev tun0, eta gero bideratu urrutiko prefijoa, hari helbidea eman beharrean. 2001:db8:4a::/64 bideak tunelaren bidez urrutiko aldea irisgarri egiten du; helbideak bakarrik interfaze lokala konfiguratuta uzten du.

Tunel oso baterako hirugarren urratsa dago, gailutik zehar unicast globalerako defektuzko bidea, dena tunelera bidaltzearen IPv6 baliokidea dena. Hau saihesten baduzu, IPv6-k lotura fisikoa erabiltzen jarraitzen du IPv4 tunelaren barnean doan bitartean, beraz host-ak estalita uste zenuen trafikoa isurtzen du. Egiaztatu honekin: ip -6 route get 2001:4860:4860::8888 eta irakurri zein gailu aipatzen duen, erantzuna suposatu beharrean.

Multicast bideraketaren aurretik ukatzen da

Android-ek helbideak eta bideak balioztatzen ditu VpnService.Builder rako LinkAddress bidez, eta eraikitzaile horrek multicast erabat ukatzen du. Ematen badiozu multicast prefijoa bide gisa, emaitza LinkAddress parametro txarren hutsa da, ez bidea, hau da, balioztatze-erantzuna da, ez sare-erantzuna. Ukatzeak euskarriari egiten dio bat: puntutik puntuko tun gailuak ez du lotura-geruzako multicast-ik, beraz haren gaineko talde-bideak ez du entregatzeko eredurik instalatzeko. Talde-helbideak stack-ak berak sortzen eta kontsumitzen ditu, ez dira eskuz konfiguratzen.

IPv6 all-nodes eta solicited-node helbideak arau beraren menpe daude. Interfazeak haiek daramatza stack-ak han jarri zituelako, ez politikak halakorik nahi izan zuelako.

Tunelak horren ordez zer eraman dezakeen

tunel baten bidez multicast aurkikuntza lekuz aldatzeak talde-mintzagaiak ulertzen dituen geruza bat behar du: Ethernet segmentu bat aurkezten duen TAP zubia, aplikazio-mailako errele bat edo zein bikotekidera erreplikatu esplizituki esaten zaion bideratze-protokolo bat. Horietako bat ere ez da existitzen VpnService ereduan, non aplikazioak paketeak irakurtzen eta idazten dituen eta ez duen tunelerako talde batera elkartzen den deirik. Edo gehitu taldeak ulertzen dituen osagaia, edo kendu baldintza diseinutik.

Unicast-ak, aldiz, ez du ezer gehigarririk behar goiko helbide eta bideez gain, horregatik tunelak hura eramatea espero ohi da, eta gero haiek erruduntzat jotzen dira aurkikuntza-protokolo batek huts egiten duenean.

Hiru egiaztapen ezer esleitu aurretik

Egiaztatu helbidea ez dela anycast forma, egiaztatu ez dela multicast, eta egiaztatu prefijoa bideratuta dagoela, gailuari bakarrik esleitua egon beharrean. Gero bidali zure proba host erreala den helmuga batera, anycast helbidera zuzendutako ping-ak igorlea neurtzen baitu eta ez baitu bideari buruz ezer esaten. Atxiki hiru egiaztapen horiek aldaketen erregistroan, hurrengo hedapenak berriro aurkitu ez ditzan.

Plataformak inoiz instalatu ez zuen bidea ezin da luzaroago itxaronez araztu, eta inoiz host izan ez zen helbidea ezin da ping hobearekin konpondu.