IPv6 de enlace local non funciona por VPN: por que fe80 queda no enlace
Un enderezo fe80:: só significa algo nun enlace. Vexa por que unha VPN encamiñada non pode transportalo, como se ve o fallo e que enderezo usar no seu lugar.
Levanta o túnel, fai ping a fe80::1 co túnel como interface de orixe e non recibe nada. Non é unha regra de cortalumes que esquecera. Un enderezo de enlace local só significa algo no único enlace onde se formou, e unha VPN encamiñada non é ese enlace. O fe80::1 do router remoto vive no segmento remoto da LAN; vostede está a un salto de distancia noutro segmento, e IPv6 non ten ningún mecanismo para que un router reenvíe paquetes de enlace local.
O prefixo fe80 describe un ámbito, non un rango
O unicast de enlace local é fe80::/10, e a propiedade que o define non é o número senón o ámbito. O enderezo só é válido nun enlace, e cada interface forma un a partir do seu propio identificador; por iso dúas máquinas sen relación en dúas redes sen relación poden responder ambas a fe80::1 sen o menor conflito. O prefixo basicamente di «nalgún enlace»; o enlace mesmo vén do contexto.
Nun host, ese contexto é a zona, ou o ID de ámbito, que engade tras un signo de porcentaxe: fe80::1%eth0 en Linux, fe80::1%3 ou fe80::1%12 en Windows e en ferramentas que expoñen índices de interface. O núcleo resolve o enderezo xunto co índice de interface e despois envía. Quite a zona e o destino queda ambiguo, así que a pila non ten forma de escoller un segmento.
Por que un túnel encamiñado non pode entregala
Unha VPN encamiñada é unha interface punto a punto que leva os seus propios enderezos, normalmente un /64 de espazo IPv6 único-local ou privado dentro do túnel. A LAN remota é un enlace aparte, alcanzado porque o extremo do túnel encamiña e reenvía no seu nome. Son dous segmentos distintos, así que un enderezo dun non é un destino válido no outro.
A regra de reenvío é explícita no estándar e non unha rareza do seu cliente: os routers non reenvían paquetes con orixe ou destino de enlace local. Por iso o paquete morre mesmo cando a táboa de rutas parece correcta. Engada unha ruta para fe80::/64 cara ao túnel e unha pila conforme ao estándar ou ben a rexeita ou ben a acepta e descarta todos os paquetes que coincidan: o ámbito do destino di «só este enlace», e a interface de saída non é ese enlace.
O descubrimento de veciños reforza a mesma fronteira. Os hosts resolven os seguintes saltos de enlace local cunha solicitude de veciño enviada a multicast de ámbito de enlace cun límite de saltos de 255, de modo que os routers poden rexeitar calquera cousa reenviada. Facer que isto funcione por un túnel significaría facer de proxy do descubrimento para un segmento remoto, que é unha ponte de capa 2 con outro sombreiro.
Hai un segundo fallo máis silencioso, e fai tropezar a quen intenta forzar a ruta de todos os xeitos: a zona. Calquera zona que escriba localmente nomea a interface do túnel, mentres que o enderezo que quere está ligado á interface da LAN remota. As dúas nunca coinciden, así que o paquete non se pode dirixir á interface correcta no extremo oposto.
Como se ve o fallo na práctica
A saída das ferramentas ante un erro de ámbito lese como un erro de encamiñamento ou de cortalumes, e é exactamente por iso que a xente pasa unha tarde na capa equivocada.
| What you run | What you see | What it means |
|---|---|---|
| ping fe80::1 with no zone | Invalid argument on Linux, or a transmit failure on Windows | The stack cannot pick an interface for an ambiguous destination |
| ping -6 -I tun0 fe80::1 | Destination unreachable, or a silent timeout | The address is not on the tunnel link, so there is nothing on-link to answer |
| ssh user@fe80::1 after the tunnel is up | Hangs, then no route to host | The SYN never left the machine in a deliverable form; the server logs nothing |
| ip -6 neigh show dev tun0 | Empty table | No neighbor entry can exist for a link-local host that is not on this link |
| fe80::/64 inside AllowedIPs or route-ipv6 | Config accepted, traffic still dropped | The tunnel carried the packet; the receiving stack refused to forward it |
A terceira fila é a que máis tempo fai perder, porque un cliente ssh sen saída parece un problema do servizo que escoita. Se ten calquera vía de entrada, mire o lado remoto e confirme se sshd está ligado a todos os enderezos ou só a un.
Use un enderezo pensado para ser encamiñado
Para calquera cousa á que deba chegar polo túnel, use o enderezo que se deu ao servizo para ese propósito: un enderezo unicast global, ou un enderezo único-local de fc00::/7, o rango reservado exactamente para este caso interno. Confirme que o oínte o liga de verdade, e confirme a ruta de volta e calquera regra de cortalumes do host.
Mire o host remoto no canto de adiviñar. ip -6 addr show lista os enderezos que existen, e ss -6 -ltn lista en que escoita o daemon. Un servizo ligado só a fe80:: é alcanzable só desde o seu propio segmento, o que normalmente é unha opción por defecto que ninguén escolleu a propósito e que se pode cambiar co acordo do administrador.
Cando o servizo realmente non se pode volver ligar, suba a ponte á capa de aplicación en lugar da de rede. Un repetidor no host remoto que escoita nun enderezo encamiñable e se conecta ao de enlace local resolve o problema sen estender ningún segmento:
socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80Aquí a zona está no lado correcto, no host que realmente ten eth0 nese enlace. O seu cliente fala con fd00:1:2::10, que se encamiña con normalidade, e o repetidor fai local o salto de enlace local. O mesmo truco funciona para a interface web dun aparello ou un BMC antigo que só anuncia un enderezo de enlace local.
Cando a ponte é realmente a resposta, e que comprobar
Algúns despregamentos si necesitan un segmento compartido: un dispositivo que só fala descubrimento de enlace local, un aparello que depende de multicast, un laboratorio que reproduce unha LAN plana. Iso é un problema de capa 2 e necesita unha resposta de capa 2, como un dispositivo tap pontado á interface remota ou un produto cliente cun modo ponte explícito. Cóstanos tráfico de difusión e multicast atravesando o túnel, ademais de descubrimento de veciños que debe funcionar de extremo a extremo.
Non o aproxime engadindo fe80::/64 a un perfil encamiñado. Iso produce o peor estado de todos: a configuración parece rematada, a táboa de rutas mostra unha entrada e cada paquete segue descartándose nalgún lugar entre dúas pilas que ambas se comportan correctamente.
Verifique coa interface, non co ping. ip -6 addr show tun0 dille se o enlace do túnel formou un enderezo de enlace local propio, e ip -6 route get fe80::1%tun0 dille que faría realmente o núcleo cun destino con ámbito. Cando o núcleo di que o destino non é alcanzable nesa interface, ningunha configuración do túnel o cambiará, e é hora de deixar de editar o perfil.
Unha secuencia breve que resolve a cuestión:
- Lea o enderezo no host remoto e anote se é fe80:: ou un prefixo encamiñable.
- Se é fe80::, volva ligar o servizo, repita nese host ou pontee o segmento; se é encamiñable, corrixa a ruta, o cortalumes ou o enderezo de ligazón.
- Revise a zona cada vez que volva probar, porque un comando copiado adoita conservar a interface equivocada.