Tóm lại, làm cách nào tôi có thể buộc một giao diện sử dụng địa chỉ IPv6 toàn cầu làm nguồn cho các thông báo chào mời hàng xóm thay vì địa chỉ liên kết?
Lý lịch: Nhiều nhà cung cấp VPS không cấp phát IPv6 /64 được định tuyến mà chỉ cấp phát một khối trên /48. Cổng là một địa chỉ IPv6 toàn cầu trên/48 nhưng bên ngoài/64. Cổng phản hồi các tin nhắn NS được gửi từ một địa chỉ toàn cầu, nhưng không phản hồi các tin nhắn NS trên địa chỉ liên kết (cũng như các tin nhắn RS từ bất kỳ nguồn nào). Điều này ổn khi lưu lượng truy cập toàn cầu được tạo trên VPS. Tuy nhiên, khi lưu lượng truy cập bắt nguồn bên trong bộ chứa LXC trên VPS [KVM], địa chỉ liên kết được sử dụng cho NS đến cổng và khám phá hàng xóm không hoạt động.
Vấn đề tiềm ẩn (ví dụ thực tế):
nguồn gốc LXC -> lxcbr0 -> eth0 -> Cổng nhà cung cấp VPS -> Internet
Bắt đầu với eth0. Thiết lập KVM VPS cơ bản như sau:
# ip show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast trạng thái UP nhóm mặc định qlen 1000
liên kết/ether 00:16:3c:a8:db:1b brd ff:ff:ff:ff:ff:ff
inet6 2a01:8888:1:5555::4444/64 phạm vi toàn cầu
hợp lệ_lft mãi mãi ưa thích_lft mãi mãi
liên kết phạm vi inet6 fe80::216:3cff:fea8:db1b/64
hợp lệ_lft mãi mãi ưa thích_lft mãi mãi
# ip -6r
2a01:8888:1::1 dev eth0 metric 1024 pref medium
2a01:8888:1:5555::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
mặc định qua 2a01:8888:1::1 dev eth0 metric 1024 pref medium
Điều này hoạt động theo nghĩa sau:
# ping ipv6.google.com -c 3
PING ipv6.google.com (2a00:1450:400e:810::200e): 56 byte dữ liệu
64 byte từ 2a00:1450:400e:810::200e: seq=0 ttl=117 time=36,298 ms
64 byte từ 2a00:1450:400e:810::200e: seq=1 ttl=117 time=33,580 ms
64 byte từ 2a00:1450:400e:810::200e: seq=2 ttl=117 time=33,112 ms
--- thống kê ping ipv6.google.com ---
Truyền 3 gói, nhận 3 gói, mất gói 0%
khứ hồi tối thiểu/trung bình/tối đa = 33,112/34,330/36,298 mili giây
# ndisc6 -s 2a01:8888:1:5555::4444 2a01:8888:1::1 eth0
Mời 2a01:8888:1::1 (2a01:8888:1::1) trên eth0...
Địa chỉ tầng liên kết đích: 3C:61:04:A4:1F:7C
từ 2a01:8888:1::1
Bây giờ LXC có những điều sau đây lxcbr0 cài đặt:
# ip show dev lxcbr0
3: lxcbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 trạng thái qdisc noqueue UP nhóm mặc định qlen 1000
liên kết/ether 00:16:3e:a7:17:58 brd ff:ff:ff:ff:ff:ff
inet6 2a01:8888:1:5555:216::ffff/64 phạm vi toàn cầu
hợp lệ_lft mãi mãi ưa thích_lft mãi mãi
inet6 fe80::216:3eff:fea7:1758/64 liên kết phạm vi
hợp lệ_lft mãi mãi ưa thích_lft mãi mãi
và bên trong container (sử dụng một veth liên kết đến lxcbr0) trông như thế này:
# ip một chương trình eth0
2: eth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 trạng thái qdisc noqueue UP nhóm mặc định qlen 1000
liên kết/ether 00:16:3e:2f:82:a7 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 2a01:8888:1:5555::1238/64 phạm vi toàn cầu
hợp lệ_lft mãi mãi ưa thích_lft mãi mãi
liên kết phạm vi inet6 fe80::216:3eff:fe2f:82a7/64
hợp lệ_lft mãi mãi ưa thích_lft mãi mãi
# ip -6r
2a01:8888:1:5555::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
mặc định qua fe80::216:3eff:fea7:1758 dev eth0 metric 1024 pref medium
Tuy nhiên, điều này không hoạt động:
# ping ipv6.google.com -c 3
PING 2a00:1450:400e:810::200e (2a00:1450:400e:810::200e): 56 byte dữ liệu
--- Thống kê ping 2a00:1450:400e:810::200e ---
Truyền 3 gói, nhận 0 gói, mất gói 100%
Nguyên nhân của vấn đề
Nếu tôi làm một tcpdump trên máy chủ, tôi quan sát thấy rằng khi lưu lượng truy cập bắt nguồn từ bộ chứa LXC, thông báo NS đến cổng đến từ địa chỉ liên kết:
# tcpdump ip6
tcpdump: chặn đầu ra dài dòng, sử dụng -v[v]... để giải mã giao thức đầy đủ
nghe trên eth0, loại liên kết EN10MB (Ethernet), ảnh chụp nhanh dài 262144 byte
08:41:55.229077 IP6 fe80::216:3cff:fea8:db1b > ff02::1:ff00:1: ICMP6, xúi giục hàng xóm, người có 2a01:8888:1::1, độ dài 32
08:41:56.305550 IP6 fe80::216:3cff:fea8:db1b > ff02::1:ff00:1: ICMP6, xúi giục hàng xóm, người có 2a01:8888:1::1, độ dài 32
08:41:57.345548 IP6 fe80::216:3cff:fea8:db1b > ff02::1:ff00:1: ICMP6, xúi giục hàng xóm, người có 2a01:8888:1::1, độ dài 32
# ip -6 n show dev eth0
2a01:8888:1::1 bộ định tuyến KHÔNG THÀNH CÔNG
...
Ngược lại, giống nhau tcpdump khi ping được thực hiện bên ngoài vùng chứa LXC:
# tcpdump ip6
tcpdump: đầu ra dài dòng bị chặn, sử dụng -v[v]...để giải mã giao thức đầy đủ
nghe trên eth0, loại liên kết EN10MB (Ethernet), ảnh chụp nhanh dài 262144 byte
10:06:33.926756 IP6 2a01:8888:1:5555::4444 > ff02::1:ff00:1: ICMP6, xúi giục hàng xóm, người có 2a01:8888:1::1, chiều dài 32
10:06:33.929886 IP6 2a01:8888:1::1 > 2a01:8888:1:5555::4444: ICMP6, quảng cáo hàng xóm, tgt là 2a01:8888:1::1, độ dài 32
10:06:33.929917 IP6 2a01:8888:1:5555::4444 > ams17s12-in-x0e.1e100.net: ICMP6, yêu cầu tiếng vang, id 52543, phần tiếp theo 0, độ dài 64
10:06:33.962581 IP6 ams17s12-in-x0e.1e100.net > 2a01:8888:1:5555::4444: ICMP6, phản hồi tiếng vọng, id 52543, phần tiếp theo 0, độ dài 64
10:06:34.926947 IP6 2a01:8888:1:5555::4444 > ams17s12-in-x0e.1e100.net: ICMP6, yêu cầu tiếng vang, id 52543, phần 1, độ dài 64
10:06:34.959682 IP6 ams17s12-in-x0e.1e100.net > 2a01:8888:1:5555::4444: ICMP6, phản hồi tiếng vọng, id 52543, phần tiếp theo 1, độ dài 64
10:06:35.927166 IP6 2a01:8888:1:5555::4444 > ams17s12-in-x0e.1e100.net: ICMP6, yêu cầu tiếng vang, id 52543, phần 2, độ dài 64
10:06:35.959820 IP6 ams17s12-in-x0e.1e100.net > 2a01:8888:1:5555::4444: ICMP6, phản hồi tiếng vọng, id 52543, phần tiếp theo 2, độ dài 64
# ip -6 n show dev eth0
2a01:8888:1::1 dev eth0 lladdr 3c:61:04:a4:1f:7c bộ định tuyến CÓ THỂ TẠO
...
Nhà cung cấp không cung cấp IP cổng liên kết. tôi đã thử sử dụng lxcbr0địa chỉ toàn cầu của làm cổng bên trong bộ chứa LXC mà không có bất kỳ sự khác biệt nào. Cấu hình này dường như phổ biến giữa các nhà cung cấp, do đó, việc yêu cầu họ thay đổi/sửa cấu trúc của họ không có khả năng dẫn đến giải pháp.
Làm cách nào tôi có thể giải quyết vấn đề cơ bản về kết nối IPv6 từ bên trong bộ chứa LXC trong khi vẫn sử dụng veth? Gợi ý rất được hoan nghênh.
