Forțați sursa IPv6 NS să fie globală în loc de link

În rezumat, cum pot forța o interfață să folosească adresa IPv6 globală ca sursă pentru mesajele de solicitare a vecinilor, mai degrabă decât adresa de legătură?

Fundal: Mulți furnizori de VPS nu alocă un IPv6 /64 rutat, ci doar atribuie un bloc pe un /48. Gateway-ul este o adresă IPv6 globală pe /48, dar în afara /64. Gateway-ul răspunde la mesajele NS trimise de la o adresă globală, dar nu răspunde la mesajele NS de pe adresa de legătură (și nici la mesajele RS din orice sursă). Acest lucru este OK atunci când traficul global este generat pe VPS. Cu toate acestea, atunci când traficul provine din interiorul unui container LXC pe VPS-ul [KVM], adresa de legătură este utilizată pentru NS către gateway și descoperirea vecinilor nu funcționează.

Problemă de bază (exemplu din viața reală):

origine LXC -> lxcbr0 -> eth0 -> Gateway furnizor VPS -> Internet

Incepand cu eth0. Configurația de bază KVM VPS este astfel:

# ip a show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:16:3c:a8:db:1b brd ff:ff:ff:ff:ff:ff
    inet6 2a01:8888:1:5555::4444/64 domeniu global
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
    inet6 fe80::216:3cff:fea8:db1b/64 scope link
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
# ip -6 r
2a01:8888:1::1 dev eth0 metric 1024 pref mediu
2a01:8888:1:5555::/64 dev eth0 proto kernel metric 256 pref mediu
fe80::/64 dev eth0 proto kernel metric 256 pref mediu
implicit prin 2a01:8888:1::1 dev eth0 metric 1024 pref mediu

Aceasta funcționează în următorul sens:

# ping ipv6.google.com -c 3
PING ipv6.google.com (2a00:1450:400e:810::200e): 56 de octeți de date
64 de octeți din 2a00:1450:400e:810::200e: seq=0 ttl=117 time=36.298 ms
64 de octeți din 2a00:1450:400e:810::200e: seq=1 ttl=117 timp=33,580 ms
64 de octeți din 2a00:1450:400e:810::200e: seq=2 ttl=117 time=33.112 ms

--- ipv6.google.com statistici ping ---
3 pachete transmise, 3 pachete primite, 0% pierdere de pachete
dus-întors min/medie/max = 33,112/34,330/36,298 ms
# ndisc6 -s 2a01:8888:1:5555::4444 2a01:8888:1::1 eth0
Se solicită 2a01:8888:1::1 (2a01:8888:1::1) pe eth0...
Adresa stratului de legătură țintă: 3C:61:04:A4:1F:7C
 de la 2a01:8888:1::1

Acum LXC are următoarele lxcbr0 înființat:

# ip a show dev lxcbr0
3: lxcbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue stare UP grup implicit qlen 1000
    link/ether 00:16:3e:a7:17:58 brd ff:ff:ff:ff:ff:ff
    inet6 2a01:8888:1:5555:216::ffff/64 scope global
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
    inet6 fe80::216:3eff:fea7:1758/64 scope link
       valid_lft pentru totdeauna preferred_lft pentru totdeauna

și în interiorul recipientului (folosind a veth link către lxcbr0) arata asa:

# ip a show eth0
2: eth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue stare UP grup implicit qlen 1000
    link/ether 00:16:3e:2f:82:a7 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 2a01:8888:1:5555::1238/64 domeniu global
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
    inet6 fe80::216:3eff:fe2f:82a7/64 scope link
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
# ip -6 r
2a01:8888:1:5555::/64 dev eth0 proto kernel metric 256 pref mediu
fe80::/64 dev eth0 proto kernel metric 256 pref mediu
implicit prin fe80::216:3eff:fea7:1758 dev eth0 metric 1024 pref mediu

Cu toate acestea, acest lucru nu funcționează:

# ping ipv6.google.com -c 3
PING 2a00:1450:400e:810::200e (2a00:1450:400e:810::200e): 56 de octeți de date

--- 2a00:1450:400e:810::200e statistici ping ---
3 pachete transmise, 0 pachete primite, 100% pierdere de pachete

Cauza problemei

Dacă fac o tcpdump pe gazdă, observ că atunci când traficul provine din containerul LXC, mesajul NS către gateway vine de la adresa linkului:

# tcpdump ip6
tcpdump: ieșire verbosă suprimată, utilizați -v[v]... pentru decodarea completă a protocolului
ascultare pe eth0, tip link EN10MB (Ethernet), lungime instantanee 262144 octeți
08:41:55.229077 IP6 fe80::216:3cff:fea8:db1b > ff02::1:ff00:1: ICMP6, solicitare vecin, care are 2a01:8888:1::1, lungime 32
08:41:56.305550 IP6 fe80::216:3cff:fea8:db1b > ff02::1:ff00:1: ICMP6, solicitare vecin, care are 2a01:8888:1::1, lungime 32
08:41:57.345548 IP6 fe80::216:3cff:fea8:db1b > ff02::1:ff00:1: ICMP6, solicitare vecin, care are 2a01:8888:1::1, lungime 32
# ip -6 n show dev eth0
2a01:8888:1::1 router-ul EȘECT
...

În schimb, la fel tcpdump când ping-ul este efectuat în afara containerului LXC:

# tcpdump ip6
tcpdump: ieșirea verbosă a fost suprimată, utilizați -v[v]...pentru decodarea completă a protocolului
ascultare pe eth0, tip link EN10MB (Ethernet), lungime instantanee 262144 octeți
10:06:33.926756 IP6 2a01:8888:1:5555::4444 > ff02::1:ff00:1: ICMP6, solicitare vecin, care are 2a01:8888:1::1, lungime 32
10:06:33.929886 IP6 2a01:8888:1::1 > 2a01:8888:1:5555::4444: ICMP6, reclama vecinului, tgt este 2a01:8888:1::1, lungime 32
10:06:33.929917 IP6 2a01:8888:1:5555::4444 > ams17s12-in-x0e.1e100.net: ICMP6, cerere ecou, ​​id 52543, secv 0, lungime 64
10:06:33.962581 IP6 ams17s12-in-x0e.1e100.net > 2a01:8888:1:5555::4444: ICMP6, răspuns ecou, ​​id 52543, secv 0, lungime 64
10:06:34.926947 IP6 2a01:8888:1:5555::4444 > ams17s12-in-x0e.1e100.net: ICMP6, cerere echo, id 52543, secv 1, lungime 64
10:06:34.959682 IP6 ams17s12-in-x0e.1e100.net > 2a01:8888:1:5555::4444: ICMP6, răspuns ecou, ​​id 52543, secv 1, lungime 64
10:06:35.927166 IP6 2a01:8888:1:5555::4444 > ams17s12-in-x0e.1e100.net: ICMP6, cerere echo, id 52543, secv 2, lungime 64
10:06:35.959820 IP6 ams17s12-in-x0e.1e100.net > 2a01:8888:1:5555::4444: ICMP6, răspuns ecou, ​​id 52543, secv 2, lungime 64
# ip -6 n show dev eth0
2a01:8888:1::1 dev eth0 lladdr 3c:61:04:a4:1f:7c router ACCESIBIL
...

Furnizorul nu oferă un IP de gateway de legătură. Am incercat sa folosesc lxcbr0adresa globală a lui ca gateway în interiorul containerului LXC fără nicio diferență. Această configurație pare să fie predominantă în rândul furnizorilor, așa că nu este probabil ca să le cereți să-și schimbe/remedieze arhitectura să aibă ca rezultat o soluție.

Cum pot rezolva problema de bază a conectivității IPv6 din interiorul containerului LXC în timp ce încă folosesc veth? Sugestii foarte binevenite.