Per què la descoberta de veïns IPv6 falla a través d'una VPN encaminada

La descoberta de veïns IPv6 pertany a un enllaç, i un túnel encaminat és una frontera entre dos enllaços. Aquesta sola frase explica gairebé tots els informes d'un amfitrió remot que respon per adreça i no es pot trobar per cap altre mitjà. Comprova l’abast de l’adreça que estàs provant abans de comprovar el túnel. Una adreça local d’enllaç només té sentit al seu propi enllaç, i un grup de multicast de node sol·licitat té el mateix abast. Cap dels dos travessa un encaminador, i per això un ping a una adreça global pot tenir èxit mentre la descoberta per al mateix amfitrió no.

L’abast va abans de la configuració

La sol·licitud i l’anunci de veí porten un límit de salts de 255 i no es reenvien, per disseny. L’encaminador entre el teu túnel i la LAN remota reenvia paquets IPv6 i no retransmet missatges de veïns en nom seu. Així, la memòria cau de veïns a la interfície del túnel conté el parell i poca cosa més, que és un comportament correcte i no un defecte a corregir.

Una adreça local d’enllaç com una entrada fe80:: també té abast de zona, i el mateix text pot designar un amfitrió diferent en un enllaç diferent. Provar-ne una des de l’altre costat del túnel no demostra res excepte que l’adreça és ambigua.

El parany és la suposició que el prefix és a l’enllaç

Un amfitrió que creu que un prefix és a l’enllaç envia una sol·licitud de veí en lloc de lliurar el paquet al seu encaminador, i això inclou un /64 encaminat a un lloc remot. Quan aquest prefix arriba com a «a l’enllaç», l’amfitrió pregunta a l’enllaç local per un amfitrió que viu en un altre lloc, i res no respon. Encamina una cosa més petita cap a l’amfitrió remot, o acaba el prefix a l’encaminador que respondrà per ell.

Un /128 per a un sol servei és la disposició que sorprèn menys, i elimina l’ambigüitat del tot. L’especificació de descoberta de veïns descriu el conjunt de missatges i el flag «a l’enllaç» que ho decideix.

El pont canvia les regles expressament

Quan el túnel transporta trames Ethernet, els segments remot i local esdevenen un sol enllaç, el multicast arriba als dos costats i la descoberta de veïns es comporta com ho faria en un commutador. Les conseqüències arriben amb això: inundació de broadcast i multicast, detecció d’adreces duplicades a través del pont i anuncis d’encaminador que es filtren en un segment que no els hauria de veure. El domini de fallada ara també abasta dos llocs. Res d’això no és un argument contra fer un pont, i cada punt és una raó per fer-lo deliberadament i no incidentalment.

Canviar un perfil de TUN a TAP per fer aparèixer la descoberta és l’ordre d’operacions equivocat. El servidor, el client i el pla d’adreçament han de coincidir, i els clients mòbils no ofereixen cap interfície TAP, així que aquest disseny funciona en un portàtil i falla en un telèfon. Els proxys i relés de veïns són mecanismes separats amb requisits propis, i pertanyen a la disposició documentada de l’administrador de xarxa i no a la configuració d’una aplicació.

Prova amb l’adreça que fa servir l’aplicació

Confirma la ruta amb ip -6 route get, inspecciona l’entrada de veí amb ip -6 neigh i després confirma el servei pel camí encaminat. El DNS i el camí de tornada són comprovacions separades, i una entrada de veí saludable no demostra cap de les dues.

Si l’aplicació insisteix en una destinació local d’enllaç o basada en descoberta, això és una conversa de disseny i no un exercici de calibratge, perquè cap paràmetre del client fa que un mecanisme limitat a l’enllaç funcioni a través d’un encaminador.

Anota quin disseny tens

Registra si és encaminat o amb pont abans de l’incident, perquè els dos desplegaments responen aquestes preguntes de manera diferent i un enginyer de guàrdia no hauria de deduir-ho d’un perfil.

Llegir el conjunt de missatges una vegada elimina la temptació d’explicar una propietat d’abast d’enllaç com un error de la VPN, que és el diagnòstic equivocat més car en aquest àmbit.