Pse zbulimi i fqinjëve IPv6 dështon përmes një VPN të rrugëtuar

Zbulimi i fqinjëve IPv6 i përket një lidhjeje, dhe një tunel i rrugëtuar është një kufi mes dy lidhjeve. Ai një fjali shpjegon pothuajse çdo raport për një host të largët që përgjigjet sipas adresës dhe nuk gjendet në asnjë mënyrë tjetër. Kontrollo shtrirjen e adresës që po teston përpara se të kontrollosh tunelin. Një adresë lokale për lidhjen ka kuptim vetëm në lidhjen e vet, dhe grupi multicast i nyjës së kërkuar është i kufizuar në të njëjtën mënyrë. Asnjëra nuk kalon një ruter, dhe për këtë arsye një ping drejt një adrese globale mund të ketë sukses ndërsa zbulimi për të njëjtin host jo.

Shtrirja vjen para konfigurimit

Kërkesa dhe njoftimi i fqinjit mbajnë një kufi hops prej 255 dhe nuk përçohen, sipas projektimit. Ruteri mes tunelit tënd dhe LAN-it të largët përçon paketat IPv6 dhe nuk i ritransmeton mesazhet e fqinjëve në emrin e tij. Kështu cache-i i fqinjëve në ndërfaqen e tunelit përmban homologun dhe pak gjë tjetër, që është sjellje e saktë dhe jo një defekt për t’u rregullar.

Një adresë lokale për lidhjen, si një zë fe80::, është gjithashtu e kufizuar nga zona, dhe i njëjti tekst mund të tregojë një host tjetër në një lidhje tjetër. Testimi i njërës nga ana tjetër e tunelit nuk provon asgjë përveçse që adresa është e paqartë.

Kurthi është supozimi se prefiksi është në lidhje

Një host që beson se një prefiks është në lidhje dërgon një kërkesë fqinji në vend që t’ia dorëzojë paketën ruterit të vet, dhe kjo përfshin një /64 të rrugëtuar drejt një vendi të largët. Kur një prefiks i tillë vjen si në lidhje, hosti pyet lidhjen lokale për një host që jeton diku tjetër, dhe asgjë nuk përgjigjet. Rrugëto diçka më të vogël drejt hostit të largët, ose përfundo prefiksin te ruteri që do të përgjigjet për të.

Një /128 për një shërbim të vetëm është rregullimi më pak i befasishëm, dhe e heq paqartësinë plotësisht. Specifikimi i zbulimit të fqinjëve përshkruan grupin e mesazheve dhe flamurin në lidhje që e vendos këtë.

Urat ndryshojnë rregullat me qëllim

Kur tuneli transporton korniza Ethernet, segmentet e largët dhe lokal bëhen një lidhje e vetme, multicast arrin në të dyja anët, dhe zbulimi i fqinjëve sillet si në një komutator. Pasojat vijnë bashkë me të: përmbytje transmetimi dhe multicast, zbulim adresash të dyfishta përmes urës, dhe njoftime ruteri që rrjedhin në një segment që nuk duhet t’i shohë. Domeni i dështimit tani përfshin edhe dy site. Asnjëra nga këto nuk argumenton kundër urës, dhe çdo pikë është arsye për të ndërtuar urë me qëllim e jo rastësisht.

Kalimi i një profili nga TUN në TAP për të bërë që zbulimi të shfaqet është rendi i gabuar i veprimeve. Serveri, klienti dhe plani i adresimit duhet të bien dakord, dhe klientët celularë nuk ofrojnë fare ndërfaqe TAP, prandaj një projekt i tillë funksionon në një laptop dhe dështon në një telefon. Proksitë dhe rele-të e fqinjëve janë mekanizma të veçantë me kërkesat e tyre, dhe i përkasin rregullimit të dokumentuar të administratorit të rrjetit e jo cilësimeve të një aplikacioni.

Testo me adresën që përdor aplikacioni

Konfirmo rrugën me ip -6 route get, shiko zërin e fqinjit me ip -6 neigh, pastaj konfirmo shërbimin përgjatë rrugës së rrugëtuar. DNS dhe rruga e kthimit janë kontrolle të veçanta, dhe një zë i shëndoshë fqinji nuk provon asnjërën.

Nëse aplikacioni këmbëngul për një destinacion lokal për lidhjen ose të bazuar në zbulim, ky është një bisedë projektimi dhe jo një ushtrim akordimi, sepse asnjë cilësim klienti nuk e bën një mekanizëm të kufizuar në lidhje të funksionojë përmes një ruteri.

Shkruaj çfarë projekti ke

Regjistro përpara incidentit nëse është i rrugëtuar ose me urë, sepse dy vendosjet u përgjigjen këtyre pyetjeve ndryshe dhe një inxhinier në detyrë nuk duhet ta nxjerë atë nga një profil.

Leximi një herë i grupit të mesazheve heq tundimin për të shpjeguar një veti të shtrirjes së lidhjes si defekt i VPN-së, që është diagnoza e gabuar më e kushtueshme në këtë fushë.