Un dispozitiv dispare din lista IPv6 a routerului: ce s-a schimbat?

Un player media cade din lista de clienți IPv6 a routerului în timp ce fluxurile sale continuă să funcționeze, iar concluzia naturală este că ceva s-a stricat. Cel mai des, lista doar și-a schimbat părerea despre ce afișează. Pagina de stare a routerului poate afișa o concesiune DHCPv6, o asociere wireless, o intrare de vecin sau o vedere unificată, iar fiecare răspunde la o altă întrebare.

Pagina afișează un singur tip de înregistrare, nu un inventar

Gazdele IPv6 au de obicei mai multe adrese simultan: o adresă link-local, una sau mai multe adrese globale și adrese temporare de confidențialitate care se rotesc. Descoperirea vecinilor păstrează un cache al vecinilor folosiți recent pe legătura locală, cu stări de accesibilitate care expiră. Un dispozitiv poate fi perfect accesibil în timp ce intrarea sa din cache îmbătrânește, și poate apărea într-un tabel de concesiuni în timp ce traficul său merge pe altă cale. Niciuna dintre aceste surse nu este un registru al tuturor adreselor pe care le-a avut vreodată un dispozitiv.

Deci prima întrebare nu este de ce a dispărut dispozitivul, ci din ce sursă de date preia pagina.

Trei vederi ale gazdei răspund la trei întrebări diferite

Pe o gazdă Linux autorizată, citiți cele trei obiecte separat. Lista de adrese arată ce este configurat, tabelul de rutare arată încotro ar merge traficul, iar tabelul de vecini arată cu cine a vorbit recent gazda pe legătură. Amestecarea lor produce răspunsuri greșite cu încredere, pentru că o intrare de vecin lipsă arată exact ca o adresă lipsă.

ip -6 address show
ip -6 route show
ip -6 neighbour show

Rulați-le în spațiul de nume de rețea real care transportă traficul. Într-un container, lista de interfețe poate diferi de cea pe care o vede gazda, iar un client VPN poate locui în oricare dintre ele.

Comparați aceleași trei ieșiri înainte și după tranziția VPN și notați momentele de timp. O intrare de vecin care dispare în timp ce adresele și rutele rămân pe loc descrie îmbătrânirea cache-ului, nu o schimbare de configurație.

Separați o schimbare de afișare de o schimbare de conectivitate

Apoi testați ceea ce contează cu adevărat: accesibilitatea resursei IPv6 de care are nevoie dispozitivul. Dacă serviciul răspunde prin IPv6 pe calea aprobată, un rând care lipsește dintr-un panou este un defect de monitorizare. Dacă eșuează, schimbarea de afișare poate fi un simptom, iar pasul următor este calea de rutare și firewall, nu lista în sine. Un VPN rutat nu mută de obicei interfața LAN a gazdei pe legătura la distanță, așa că țineți adresele LAN și adresele de tunel în coloane separate ale gândirii dumneavoastră.

O interfață poate purta mai multe adrese, iar o pagină de stare poate afișa doar una dintre ele. De aceea un dispozitiv poate părea că își schimbă adresa după reconectare fără ca ceva să fie greșit. Extensiile de confidențialitate fac asta mai vizibil, pentru că adresele temporare se rotesc după un program pe care pagina nu îl arată.

Verificați resursa, apoi lăsați tabelele în pace

Dacă starea gazdei și conectivitatea par ambele corecte, investigați sursa de date a listei și comportamentul de reîmprospătare înainte de a atinge rețeaua. Căutați o durată de concesiune, un timeout de cache sau un filtru de afișare care ascunde adrese pe care pagina nu le clasifică.

Nu goliți tabelele de vecini, nu dezactivați IPv6 și nu realocați adrese ca să reapară un rând din panou. Acele acțiuni întrerup traficul funcțional și de obicei readuc rândul doar până la următoarea expirare a cache-ului. ip -6 neigh flush dev br-lan este cel mult un diagnostic și cel puțin o cădere pe care v-ați provocat-o singur.

Notați ce sursă folosește pagina, iar întrebarea dacă dispozitivul funcționează nu mai depinde de un rând dintr-un tabel.