169.254 a través d’una VPN: l’adreça mai no va ser encaminable
Una destinació link-local es descarta abans d’arribar al túnel, així que afegir rutes només amplia la fallada. Trieu entre reparar la subxarxa i fer un pont.
Afegiu la ruta, el túnel s’aixeca i el ping a la banda remota continua morint amb pèrdua total en lloc de «xarxa inabastable». Aquesta diferència importa, perquè allunya l’atenció de la taula d’encaminament i la porta cap a l’adreça mateixa. Una destinació 169.254 és link-local, i l’abast link-local acaba al primer salt per disseny, no per una mala configuració.
La decisió que se segueix és estreta i val la pena prendre-la explícitament: reparar la subxarxa del costat del servidor, o ampliar el segment de capa 2 perquè l’adreça torni a tenir sentit localment. Tota la resta, inclosa l’addició d’una ruta més àmplia, és una manera de fer que la mateixa fallada afecti més destinacions.
L’adreça no és sense ruta, és inencaminable
Les adreces IPv4 link-local s’autoassignen quan no respon res millor, i d’aquí ve el comportament d’adreçament privat automàtic a Windows i el mecanisme de reserva equivalent en altres sistemes. El rang s’utilitza en tots els enllaços alhora, i precisament per això funciona: dos amfitrions del mateix segment poden parlar sense cap coordinació.
Aquesta mateixa propietat és la raó per la qual un encaminador no ha de reenviar aquests paquets entre xarxes. Rebre un paquet adreçat a una destinació link-local i enviar-lo per una altra interfície crearia ambigüitat, perquè el «local» de l’emissor i el «local» del receptor són llocs diferents. No hi ha cap consulta que pugui resoldre quin dels dos volia dir l’emissor. El reenviament no és una opció de política que l’administrador pugui activar aquí; la classe d’adreces l’exclou.
Així, una passarel·la que instal·la 169.254.1.10 com a accessible a través del túnel demana al nucli que faci una cosa que el format d’adreça prohibeix. El paquet es descarta molt abans d’arribar a l’amfitrió remot, i cap grau de precisió de ruta no canvia aquest resultat.
Per què un túnel fa visible el problema d’abast
Una interfície TUN transporta paquets IP entre dos parells i no té cap segment compartit al darrere. No hi ha difusió, ni ARP per a la banda remota, ni descobriment de veïns que pugui resoldre una destinació link-local en una adreça de capa d’enllaç. Fins i tot si el reenviament estigués permès, el client no tindria manera de saber quin parell hauria de respondre.
Els símptomes encaixen perfectament quan saps què buscar. La ruta és a la taula, el ping informa de pèrdua total en lloc d’una xarxa inabastable, i la taula de veïns mostra una entrada incompleta o fallida per a la destinació. Una captura al túnel mostra el paquet que surt, cosa que porta a mirar l’extrem remot en lloc de la classe d’adreces.
A Windows hi ha un segon símptoma, aparentment sense relació, amb la mateixa arrel: un adaptador que només té una adreça link-local no té cap passarel·la utilitzable, així que la identificació de xarxa no pot classificar la connexió i el perfil del tallafoc acaba en públic. El túnel no n’és la causa; l’adreça sí.
Decidiu amb tres preguntes
L’elecció entre reparar la subxarxa i fer un pont sobre l’enllaç depèn de tres condicions, i qualsevol d’elles pot resoldre-la abans que obriu cap fitxer de configuració.
| Question | If yes | If no |
|---|---|---|
| Can the far-side host be given a routable address? | Change the host or fix DHCP and route normally | Continue to the next question |
| Does the device accept a static address at all? | Assign one from the site's real prefix | Bridging is the only remaining option |
| Can you accept broadcast crossing the tunnel? | A bridge is viable for a small segment | Replace the device or accept no remote access |
La majoria dels casos s’aturen a la primera pregunta. Un amfitrió que mostra una adreça link-local normalment vol dir que el DHCP no va respondre, que un cable o una VLAN està malament, o que algú va escriure l’adreça a mà. Reparar-ho és més barat que qualsevol treball al túnel, i elimina el problema per a tots els clients futurs i no només per a aquest. També deixa el lloc amb un àmbit DHCP que funciona, que és el que realment volíeu.
Comproveu el costat del servidor abans de suposar res. Executeu ip addr show i ip route a l’amfitrió, i arp -n o route print -4 al client, per veure si el prefix existeix de debò o si una entrada obsoleta és l’única cosa que ho afirma.
Què costa un pont quan és la resposta correcta
Fer un pont entre un adaptador físic i un adaptador TAP converteix el client remot en part del domini de difusió local. Aleshores la difusió i el descobriment de veïns funcionen, i una adreça link-local torna a tenir sentit perquè el client és realment local en aquell enllaç.
Els costos són reals i cal explicar-los abans que ningú hi estigui d’acord. El trànsit de difusió travessa el túnel, el client queda exposat al segment local per a tots els propòsits i no només per als serveis que necessita, i el servidor ara ha de reenviar trames en lloc d’encaminar paquets. És un intercanvi raonable per a un banc de proves o un dispositiu sense cap camí de configuració encaminable, i un mal valor per defecte per a l’accés remot.
Quan feu un pont, calen les dues meitats: el pont al servidor, i una ruta al perfil del client que li digui quines destinacions viuen a la banda remota. Un pont sol deixa el client endevinant, i una ruta sola no pot arreglar una classe d’adreces.