IPv6 d'enllaç local no funciona per VPN: per què fe80 es queda a l'enllaç
Una adreça fe80:: només vol dir alguna cosa en un enllaç. Vegeu per què una VPN encaminada no la pot transportar, com es veu la fallada i quina adreça cal fer servir en lloc seu.
Pugeu el túnel, feu ping a fe80::1 amb el túnel com a interfície d'origen i no rebeu res. No és cap regla de tallafoc que hàgiu oblidat. Una adreça d'enllaç local només vol dir alguna cosa a l'únic enllaç on s'ha format, i una VPN encaminada no és aquell enllaç. La fe80::1 del router remot viu al segment remot de la LAN; vós sou a un salt de distància en un segment diferent, i IPv6 no té cap mecanisme perquè un router reenviï paquets d'enllaç local de cap manera.
El prefix fe80 descriu un abast, no un rang
L'unicast d'enllaç local és fe80::/10, i la propietat que el defineix no és el número sinó l'abast. L'adreça només és vàlida en un enllaç, i cada interfície en forma una a partir del seu propi identificador; per això dues màquines sense relació en dues xarxes sense relació poden respondre totes dues a fe80::1 sense el més mínim conflicte. El prefix diu bàsicament “en algun enllaç”; l'enllaç mateix ve del context.
En un amfitrió, aquest context és la zona, o l'ID d'abast, que afegiu després d'un signe de percentatge: fe80::1%eth0 a Linux, fe80::1%3 o fe80::1%12 a Windows i en eines que exposen índexs d'interfície. El nucli resol l'adreça juntament amb l'índex d'interfície i després envia. Traieu la zona i la destinació queda ambigua, així que la pila no té manera de triar un segment.
Per què un túnel encaminat no la pot lliurar
Una VPN encaminada és una interfície punt a punt que porta les seves pròpies adreces, normalment un /64 d'espai IPv6 únic-local o privat dins del túnel. La LAN remota és un enllaç separat, abastat per l'extrem del túnel que encamina i reenvia en nom vostre. Són dos segments diferents, així que una adreça d'un no és una destinació vàlida a l'altre.
La regla de reenviament és explícita a l'estàndard i no pas una raresa del vostre client: els routers no reenvien paquets amb origen o destinació d'enllaç local. Per això el paquet mor fins i tot quan la taula d'encaminament sembla correcta. Afegiu una ruta per a fe80::/64 cap al túnel i una pila conforme a l'estàndard o bé la rebutja o bé l'accepta i descarta tots els paquets que hi coincideixin: l'abast de la destinació diu “només aquest enllaç”, i la interfície de sortida no és aquell enllaç.
El descobriment de veïns reforça la mateixa frontera. Els amfitrions resolen els salts següents d'enllaç local amb una sol·licitud de veí enviada a multicast d'abast d'enllaç amb un límit de salts de 255, de manera que els routers poden rebutjar qualsevol cosa reenviada. Fer-ho funcionar per un túnel voldria dir fer de proxy del descobriment per a un segment remot, que és un pont de capa 2 amb un altre barret.
Hi ha una segona fallada més silenciosa, i fa ensopegar qui intenta forçar la ruta de totes maneres: la zona. Quina zona que escriviu localment anomena la interfície del túnel, mentre que l'adreça que voleu està lligada a la interfície remota de la LAN. Les dues no coincideixen mai, així que el paquet no es pot dirigir a la interfície correcta a l'extrem oposat.
Com es veu la fallada a la pràctica
La sortida d'eines per a un error d'abast es llegeix com un error d'encaminament o de tallafoc, i és exactament per això que la gent passa una tarda a la 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 |
La tercera fila és la que fa perdre més temps, perquè un client ssh sense sortida sembla un problema del servei que escolta. Si teniu qualsevol via d'entrada, mireu el costat remot i confirmeu si sshd està lligat a totes les adreces o només a una.
Feu servir una adreça pensada per ser encaminada
Per a qualsevol cosa a què hàgiu d'arribar a través del túnel, feu servir l'adreça que es va donar al servei per a aquest propòsit: una adreça unicast global, o una adreça únic-local de fc00::/7, el rang reservat exactament per a aquest cas intern. Confirmeu que l'oient l'enllaça de veritat, i confirmeu el camí de tornada i qualsevol regla de tallafoc de l'amfitrió.
Mireu l'amfitrió remot en lloc d'endevinar. ip -6 addr show llista les adreces que existeixen, i ss -6 -ltn llista a què escolta el dimoni. Un servei lligat només a fe80:: és abastable només des del seu segment, cosa que normalment és una opció per defecte que ningú no va triar expressament i es pot canviar amb l'acord de l'administrador.
Quan el servei realment no es pot tornar a lligar, moveu el pont a la capa d'aplicació en lloc de la de xarxa. Un repetidor a l'amfitrió remot que escolta en una adreça encaminable i es connecta a la d'enllaç local resol el problema sense estendre cap segment:
socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80Aquí la zona seu al costat correcte, a l'amfitrió que realment té eth0 en aquell enllaç. El vostre client parla amb fd00:1:2::10, que s'encamina normalment, i el repetidor fa local el salt d'enllaç local. El mateix truc funciona per a la interfície web d'un aparell o un BMC antic que només anuncia una adreça d'enllaç local.
Quan el pont és realment la resposta, i què cal comprovar
Alguns desplegaments sí que necessiten un segment compartit: un dispositiu que només parla descobriment d'enllaç local, un aparell que depèn de multicast, un laboratori que reprodueix una LAN plana. Això és un problema de capa 2 i necessita una resposta de capa 2, com ara un dispositiu tap pontat a la interfície remota o un producte client amb un mode pont explícit. Us costa trànsit de difusió i multicast travessant el túnel, a més de descobriment de veïns que ha de funcionar d'extrem a extrem.
No ho aproximeu afegint fe80::/64 a un perfil encaminat. Això produeix el pitjor estat de tots: la configuració sembla acabada, la taula d'encaminament mostra una entrada, i cada paquet encara es descarta en algun lloc entre dues piles que totes dues es comporten correctament.
Verifiqueu amb la interfície, no amb el ping. ip -6 addr show tun0 us diu si l'enllaç del túnel ha format una adreça d'enllaç local pròpia, i ip -6 route get fe80::1%tun0 us diu què faria realment el nucli amb una destinació amb abast. Quan el nucli diu que la destinació no és abastable en aquella interfície, cap paràmetre del túnel ho canviarà, i és hora de deixar d'editar el perfil.
Una seqüència curta que resol la qüestió:
- Llegiu l'adreça a l'amfitrió remot i fixeu-vos si és fe80:: o un prefix encaminable.
- Si és fe80::, torneu a lligar el servei, repetiu en aquell amfitrió o ponteu el segment; si és encaminable, arregleu la ruta, el tallafoc o l'adreça d'enllaç.
- Reviseu la zona cada vegada que torneu a provar, perquè una ordre copiada sol conservar la interfície equivocada.