Ping-u drejt skajit tjetër të tunelit IPv6 dështon? Kontrolloni adresën ::

Njëri skaj i tunelit tuaj IPv6 i bën ping tjetrit dhe përgjigjet gjithmonë vetëm një drejtim. Ndërfaqja është e ngritur, rruga duket e saktë dhe asgjë në regjistër nuk e shpjegon atë. Adresa që keni caktuar është adresa subnet-router anycast, e cila nuk është aspak adresë hosti, dhe në një lidhje me dy skaje ka saktësisht një objektiv dërgimi: dërguesin. Asnjë vlerë e afatit kohor nuk e rregullon këtë, sepse adresa nuk bën atë që mendoni se bën.

Simptoma që të çon te adresa

Çdo host në lidhje përgjigjet, përveç atij identifikuesi i ndërfaqes së të cilit është tërësisht zero. Një paketë e adresuar në atë formë dërgohet sipas përkufizimit te një rrugëtues në nënrrjet, prandaj në një tunel pikë-për-pikë kthehet te makina që e dërgoi. Nga skaji i largët kjo lexohet si partner i paarritshëm; nga skaji i afërt lexohet si heshtje. Zëvendësoni një identifikues tjetër nga i njëjti prefiks dhe simptoma zhduket pa asnjë ndryshim tjetër, dhe kjo është konfirmimi që duhet marrë përpara se të prekni rrugët.

Identifikuesi me të gjitha zero është i rezervuar si anycast

RFC 4291 e mban identifikuesin e ndërfaqes me të gjitha zero si adresën subnet-router anycast, prandaj një /64 si 2001:db8:4a::/64 nuk përmban asnjë host të përdorshëm në 2001:db8:4a::. Rezervimi e meriton vendin: router advertisements dhe neighbour discovery i drejtohen asaj forme dhe një rrugëtues përgjigjet për prefiksin që shërben. Caktimi i asaj vlere një skaji tuneli i jep rolin e rrugëtuesit një gjetheje, dhe kjo është arsyeja pse asgjë nuk kthehet. Çdo identifikues tjetër në prefiks funksionon si host, prandaj rregullimi është zakonisht një shifër.

Trajtoni rezervimin si një rol që nuk ju takon ta zëni nga një skaj tuneli, jo si një veçori që duhet anashkaluar me rrugë.

Caktoni adresat e hosteve dhe rrugëtoni prefiksin

Zgjidhni ::1 dhe ::2 për dy skajet, shtoni një me ip -6 addr add 2001:db8:4a::2/64 dev tun0 dhe pastaj rrugëtoni prefiksin e largët në vend që të përpiqeni t'i jepni adresë. Një rrugë për 2001:db8:4a::/64 jashtë tunelit e bën anën e largët të arritshme; adresa vetëm e konfiguron ndërfaqen lokale.

Për një tunel të plotë ka një hap të tretë, një rrugë të parazgjedhur për unicast global përmes pajisjes, që është ekuivalenti IPv6 i dërgimit të gjithçkaje në tunel. Nëse e kaloni, IPv6 vazhdon të përdorë lidhjen fizike ndërsa IPv4 udhëton brenda tunelit, kështu që hosti rrjedh pikërisht trafikun që besonit se ishte i mbuluar. Konfirmoni me ip -6 route get 2001:4860:4860::8888 dhe lexoni cilën pajisje përmend, në vend që ta supozoni përgjigjen.

Multicast refuzohet përpara rrugëtimit

Android vërteton adresat dhe rrugët për VpnService.Builder përmes LinkAddress dhe ai konstruktor e refuzon multicast-in plotësisht. Jepini një prefiks multicast si rrugë dhe rezultati është një dështim bad LinkAddress parameters në vend të një rruge, që është përgjigje vërtetimi dhe jo përgjigje rrjeti. Refuzimi përputhet me mjedisin: një pajisje tun pikë-për-pikë nuk ka multicast në shtresën e lidhjes, prandaj një rrugë grupi mbi të nuk ka model dërgimi për t'u instaluar. Adresat e grupeve krijohen dhe konsumohen nga vetë stack-u, nuk konfigurohen me dorë.

Adresat IPv6 all-nodes dhe solicited-node bien nën të njëjtin rregull. Ndërfaqja i mban sepse stack-u i vendosi aty, jo sepse ndonjë politikë i synoi.

Çfarë mund të mbajë tuneli në vend të kësaj

Zhvendosja e zbulimit multicast përmes një tuneli kërkon një shtresë që kupton anëtarësimin në grup: një urë TAP që paraqet një segment Ethernet, një relay në nivel aplikacioni ose një protokoll rrugëtimi që i thuhet shprehimisht se cilëve partnerë t'u replikojë. Asnjë prej tyre nuk ekziston në modelin VpnService, ku aplikacioni lexon dhe shkruan paketa dhe nuk ka thirrje që bashkon një grup për tunelin. Ose shtoni komponentin që i kupton grupet, ose hiqni kërkesën nga projektimi.

Unicast-i, përkundrazi, nuk kërkon asgjë shtesë përtej adresave dhe rrugëve më sipër, prandaj tunelit zakonisht i kërkohet ta mbajë atë dhe pastaj fajësohet kur dështon një protokoll zbulimi.

Tre kontrolle para se të caktoni gjithçka

Konfirmoni që adresa nuk është forma anycast, konfirmoni që nuk është multicast dhe konfirmoni që prefiksi është rrugëtuar e jo thjesht i caktuar pajisjes. Pastaj dërgoni testin te një destinacion që është host i vërtetë, sepse një ping drejt adresës anycast mat dërguesin dhe nuk të thotë asgjë për rrugën. Këto tre kontrolle shkruajini në regjistrin e ndryshimeve që vendosja tjetër të mos i rizbulojë.

Një rrugë që platforma nuk e instaloi kurrë nuk mund të korrigjohet duke pritur më gjatë, dhe një adresë që nuk ishte kurrë host nuk mund të rregullohet me një ping më të mirë.