Descoperirea vecinilor IPv6 aparține unei legături, iar un tunel rutat este o graniță între două legături. Acea singură propoziție explică aproape fiecare raport despre o gazdă îndepărtată care răspunde pe adresă și nu poate fi găsită prin niciun alt mijloc. Verifică domeniul adresei pe care o testezi înainte de a verifica tunelul. O adresă locală la legătură are sens doar pe propria legătură, iar un grup multicast al nodului solicitat este limitat în același fel. Niciuna nu traversează un router, motiv pentru care un ping către o adresă globală poate reuși în timp ce descoperirea pentru aceeași gazdă nu.

Domeniul vine înaintea configurației

Solicitarea și anunțul de vecin poartă o limită de salturi de 255 și nu sunt transmise mai departe, prin proiectare. Routerul dintre tunelul tău și LAN-ul îndepărtat transmite pachete IPv6 și nu retransmite mesaje de vecini în numele lui. Astfel, cache-ul de vecini de pe interfața tunelului conține partenerul și puțin altceva, ceea ce este un comportament corect și nu un defect de reparat.

O adresă locală la legătură, cum ar fi o intrare fe80::, este de asemenea limitată la zonă, iar același text poate desemna altă gazdă pe altă legătură. Testarea uneia din cealaltă parte a tunelului nu dovedește nimic în afară de faptul că adresa este ambiguă.

Capcana este presupunerea că prefixul este pe legătură

O gazdă care crede că un prefix este pe legătură trimite o solicitare de vecin în loc să predea pachetul routerului său, iar asta include un /64 rutat către un sit îndepărtat. Când un astfel de prefix ajunge ca fiind pe legătură, gazda întreabă legătura locală despre o gazdă care locuiește în altă parte, și nimic nu răspunde. Rutează ceva mai mic către gazda îndepărtată, sau încheie prefixul la routerul care va răspunde pentru el.

Un /128 pentru un singur serviciu este aranjamentul cel mai puțin surprinzător și elimină complet ambiguitatea. Specificația descoperirii vecinilor descrie setul de mesaje și steagul pe-legătură care decide acest lucru.

Bridge-ul schimbă regulile intenționat

Când tunelul transportă cadre Ethernet, segmentele îndepărtat și local devin o singură legătură, multicastul ajunge pe ambele părți, iar descoperirea vecinilor se comportă ca pe un switch. Consecințele vin împreună: inundare de broadcast și multicast, detectarea adreselor duplicate prin bridge și anunțuri de router care se scurg într-un segment care nu ar trebui să le vadă. Domeniul de defectare acoperă acum și două situri. Nimic din toate acestea nu pledează împotriva bridge-ului, și fiecare punct este un motiv pentru a face bridge deliberat, nu incidental.

Schimbarea unui profil din TUN în TAP pentru ca descoperirea să apară este ordinea greșită a operațiunilor. Serverul, clientul și planul de adresare trebuie să fie de acord, iar clienții mobili nu oferă deloc interfață TAP, așa că un astfel de proiect funcționează pe un laptop și eșuează pe un telefon. Proxy-urile și releele de vecini sunt mecanisme separate cu cerințele lor, și aparțin aranjamentului documentat al administratorului de rețea, nu setărilor unei aplicații.

Testează cu adresa pe care o folosește aplicația

Confirmă ruta cu ip -6 route get, inspectează intrarea de vecin cu ip -6 neigh, apoi confirmă serviciul pe calea rutată. DNS și calea de întoarcere sunt verificări separate, iar o intrare de vecin sănătoasă nu le dovedește pe niciuna.

Dacă aplicația insistă pe o destinație locală la legătură sau bazată pe descoperire, este o conversație de proiectare și nu un exercițiu de reglaj, pentru că nicio setare de client nu face un mecanism limitat la legătură să funcționeze printr-un router.

Notează ce proiectare ai

Înregistrează dacă este rutat sau cu bridge înainte de incident, deoarece cele două implementări răspund diferit la aceste întrebări și un inginer de gardă nu ar trebui să deducă asta dintr-un profil.

Citirea o singură dată a setului de mesaje înlătură tentația de a explica o proprietate de domeniu al legăturii ca defect al VPN-ului, care este cea mai costisitoare diagnosticare greșită din acest domeniu.

Articole similare