Còn vài ngày nữa là bắt đầu luồng mới với tốc độ từ OTUS. Về vấn đề này, chúng tôi muốn chia sẻ với bạn bản dịch tài liệu hữu ích về chủ đề này.
Một loạt bài đăng trên blog về mẹo và thủ thuật khắc phục sự cố ping IPv6 (Yêu cầu tiếng vang/Trả lời tiếng vang ICMPv6)
Xin lưu ý rằng tôi đang sử dụng Linux (cụ thể là Fedora 31), tuy nhiên cú pháp lệnh ping cho các hệ điều hành khác hy vọng sẽ rất giống nhau.
Ping tất cả các nút IPv6 trên một kênh
Mẹo đầu tiên và đơn giản nhất là ping tất cả các nút IPv6 trên liên kết.
IPv6 sử dụng địa chỉ multicast cho tất cả các loại hình giao tiếp một-nhiều. Không có địa chỉ IPv6 quảng bá (hoặc quảng bá). Điều này phân biệt IPv6 với IPv4, trong đó có một số loại địa chỉ quảng bá, ví dụ: địa chỉ “quảng bá giới hạn” 255.255.255.255 [RFC1122].
Tuy nhiên, có một địa chỉ IPv6 “multicast tất cả các nút”, vì vậy chúng tôi sẽ sử dụng địa chỉ đó để ping tất cả các nút IPv6 trên liên kết. (Địa chỉ "broadcast" thực chất chỉ là một địa chỉ multicast được đặt tên đặc biệt, là một nhóm multicast bao gồm tất cả các nút. Lưu ý rằng, ví dụ: bit địa chỉ "nhóm" hoặc multicast được bật trong các địa chỉ multicast Ethernet ở lớp liên kết ).
Địa chỉ IPv6 multicast của tất cả các nút cho kênh: ff02::1. ff biểu thị một địa chỉ IPv6 multicast. Số 0 tiếp theo là phần cờ có các bit chưa được đặt.
Tiếp theo 2 xác định khu vực của một nhóm multicast. Không giống như địa chỉ IPv4 multicast, địa chỉ IPv6 multicast có phạm vi. Giá trị phạm vi cho biết phần mạng mà gói multicast được phép chuyển tiếp. Khi một gói đạt đến ranh giới của phạm vi được chỉ định, gói đó phải bị loại bỏ, bất kể trường Hop Count của nó có khác 6 hay không. Tất nhiên, nếu số bước nhảy đạt đến XNUMX trước khi đạt đến ranh giới nhóm multicast được chỉ định thì nó cũng ngay lập tức được đặt lại. Dưới đây là danh sách đầy đủ về phạm vi phát đa hướng của IPvXNUMX.
Cuối cùng, ::1 chỉ định một nhóm multicast tất cả các nút.
Về địa chỉ ff02::1 Cần lưu ý rằng nó là mơ hồ. Trên máy chủ IPv6 có nhiều giao diện, chẳng hạn như bộ định tuyến hoặc máy chủ đa điểm, địa chỉ ff02::1 không có nơi nào bạn có thể chỉ định giao diện nào sẽ gửi yêu cầu tiếng vang ICMPv6 tới hoặc mong đợi nhận được phản hồi tiếng vang ICMPv6 khi chúng đến. ff02::1 hợp lệ và có thể được sử dụng trên bất kỳ giao diện và kênh nào được gắn vào nút đa giao diện.
Vì vậy, khi chúng tôi ping tất cả các nút IPv6 trên một liên kết, bằng cách nào đó chúng tôi cũng cần thông báo cho tiện ích ping cho IPv6, nên sử dụng giao diện nào.
Xác định giao diện - Tùy chọn dòng lệnh
Như chúng ta đã thấy, địa chỉ multicast tất cả các nút mà chúng ta muốn sử dụng là − ff02::1 - không cung cấp bất kỳ thông tin nào về giao diện nào sẽ gửi và nhận gói yêu cầu tiếng vang ICMPv6 và gói trả lời tiếng vang.
Vì vậy, làm cách nào để chúng ta chỉ định giao diện được sử dụng cho không gian địa chỉ multicast hoặc không gian địa chỉ Link-Local unicast?
Cách đầu tiên và rõ ràng nhất là cung cấp nó làm tham số cho ứng dụng chúng ta đang sử dụng.
Đối với tiện ích ping chúng tôi cung cấp nó thông qua tùy chọn -I.
[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Warning: source address might be selected on device other than: enp3s2
PING ff02::1(ff02::1) from :: enp3s2: 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.589 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=5.15 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=58.0 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=62.3 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=62.8 ms (DUP!)
--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, +5 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$Bằng cách sử dụng ping phát đa hướng tất cả các nút này, chúng tôi đã nhận được phản hồi từ 6 nút IPv6. Phản hồi đến từ các địa chỉ nút IPv6 liên kết cục bộ, bắt đầu bằng tiền tố fe80::/10.
Đó ping không tiếp tục gửi yêu cầu tiếng vang ICMPv6 vô thời hạn cho đến khi chúng tôi làm gián đoạn nó, chúng tôi thường chỉ định số lượng gói cần gửi qua tùy chọn -c. Tuy nhiên, điều này cũng ngăn ping chấp nhận và hiển thị nhiều hơn một phản hồi tiếng vang ICMPv6 khi gửi yêu cầu tiếng vang ICMPv6 đa hướng. Thay vào đó, chúng tôi đã sử dụng tùy chọn -w để chỉ định rằng ping sẽ hoàn thành sau 1 giây, bất kể có bao nhiêu yêu cầu tiếng vang ICMPv6 hoặc phản hồi tiếng vang được gửi hoặc nhận.
Một điều nữa cần chú ý là (DUP!) xuất ra ở câu trả lời thứ hai và các câu trả lời tiếp theo. Các gói này được xác định là phản hồi trùng lặp vì chúng có cùng giá trị chuỗi ICMP với các yêu cầu tiếng vang ICMPv6 riêng lẻ được gửi ngay từ đầu. Chúng xuất hiện do yêu cầu tiếng vang đa hướng ICMPv6 dẫn đến nhiều phản hồi đơn hướng riêng lẻ. Số lượng trùng lặp cũng được chỉ định trong bản tóm tắt thống kê.
Xác định giao diện - ID vùng
Một cách khác để hiển thị giao diện để sử dụng là một phần của tham số địa chỉ IPv6.
Chúng ta có thể thấy một ví dụ về điều này trong đầu ra ping, trong đó địa chỉ của các máy chủ IPv6 phản hồi cũng có hậu tố %enp3s2, ví dụ:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msPhương pháp chỉ định giao diện này được mô tả chính thức trong [RFC4007], "Kiến trúc địa chỉ được xác định IPv6". Mặc dù chúng thường được gọi là giao diện hệ điều hành, nhưng chúng thực sự định nghĩa một cái gì đó tổng quát hơn - một "vùng" hoặc "phạm vi".
Lý do có nhiều vùng hoặc vùng phạm vi chung hơn là vì, như đã đề cập trong [RFC4007], một nút IPv6 có thể có một số giao diện IPv6 khác nhau được kết nối với cùng một kênh. Các giao diện này là thành viên của cùng một khu vực.
Có thể nhóm nhiều giao diện trong một vùng của hệ điều hành; Hiện tại tôi không biết liệu điều này có khả thi trong Linux hay không và cách thực hiện.
Sử dụng hậu tố %<zone_id>, chúng ta có thể loại bỏ tùy chọn dòng lệnh -I ping.
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.606 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=6.23 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=157 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=159 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=161 ms (DUP!)
64 bytes from fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 time=179 ms (DUP!)
--- ff02::1%enp3s2 ping statistics ---
1 packets transmitted, 1 received, +7 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
[mark@opy ~]$Phản hồi địa chỉ liên kết cục bộ
Từ ping phát đa hướng tất cả các nút này, chúng tôi đã nhận được tổng cộng 6 phản hồi duy nhất.
Những phản hồi này đến từ các địa chỉ máy chủ IPv6 liên kết cục bộ đơn hướng. Ví dụ: đây là câu trả lời đầu tiên:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msCần có địa chỉ IPv6 liên kết cục bộ Unicast trên tất cả các giao diện hỗ trợ IPv6 [RFC4291], “Kiến trúc địa chỉ IP phiên bản 6”. Lý do cho điều này là một nút IPv6 luôn tự động có một địa chỉ IPv6 unicast, ít nhất nó có thể sử dụng địa chỉ này để liên lạc với các nút khác trên các liên kết được kết nối trực tiếp của nó. Điều này bao gồm việc giao tiếp với các ứng dụng trên các máy chủ khác thông qua địa chỉ máy chủ Liên kết cục bộ.
Điều này giúp đơn giản hóa việc thiết kế và triển khai các giao thức như IPv6 Neighbor Discovery và OSPFv3. Nó cũng cho phép các ứng dụng của người dùng cuối trên máy chủ giao tiếp qua kênh mà không yêu cầu bất kỳ cơ sở hạ tầng IPv6 hỗ trợ nào khác trên kênh. Giao tiếp trực tiếp giữa các máy chủ IPv6 được kết nối không yêu cầu bộ định tuyến IPv6 hoặc máy chủ DHCPv6 trên kết nối.
Địa chỉ liên kết cục bộ bắt đầu bằng tiền tố 10 bit fe80, theo sau là 54 bit 64 và sau đó là mã định danh giao diện XNUMX bit (IID). Trong câu trả lời đầu tiên ở trên 2392:6213:a15b:66ff là IID 64 bit.
Multicast lặp lại
Theo mặc định, các gói multicast được trả về nội bộ cho nút đã gửi chúng. Điều này xảy ra đối với cả địa chỉ IPv6 và IPv4.
Lý do cho hành vi mặc định này là khi các gói multicast được gửi đi, cũng có thể có một ứng dụng multicast cục bộ đang lắng nghe đang chạy trên chính máy chủ gửi cũng như ở đâu đó trên mạng. Ứng dụng cục bộ này cũng phải nhận các gói multicast.
Chúng ta có thể thấy vòng lặp cục bộ multicast này trong đầu ra ping của mình:
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
...Phản hồi đầu tiên và nhanh nhất (0,106 ms so với 0,453 ms) đến từ địa chỉ Link-Local được định cấu hình trên chính giao diện enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Tính thiết thực ping cung cấp một cách để ngăn chặn phản hồi multicast cục bộ bằng cách sử dụng tham số -L. Nếu chúng tôi gửi ping phát đa hướng đến tất cả các nút bằng cờ này thì phản hồi sẽ bị giới hạn ở các nút từ xa. Chúng tôi không nhận được phản hồi từ địa chỉ Link-Local của giao diện gửi.
[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.383 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.467 ms (DUP!)
...Địa chỉ liên kết cục bộ Ping
Như bạn có thể đoán, bản thân các địa chỉ Link-Local unicast cũng không cung cấp đủ thông tin để chỉ ra giao diện nào sẽ sử dụng để tiếp cận chúng. Giống như ping multicast tất cả các nút, chúng ta cũng cần chỉ định giao diện làm tham số dòng lệnh ping hoặc ID vùng có địa chỉ khi ping các địa chỉ Link-Local.
Lần này chúng ta có thể sử dụng -cđể giới hạn số lượng gói và phản hồi được gửi và nhận ping, vì chúng tôi đang thực hiện ping unicast.
[mark@opy ~]$ ping -c 1 fe80::f31c:ccff:fe26:a6d9%enp3s2
PING fe80::f31c:ccff:fe26:a6d9%enp3s2(fe80::fad1:11ff:feb7:3704%enp3s2) 56 data bytes
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.395 ms
--- fe80::f31c:ccff:fe26:a6d9%enp3s2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$Ping (tất cả) địa chỉ IPv6 khác?
Trong bài viết này, chúng ta đã biết cách ping tất cả các nút IPv6 trên một kênh bằng địa chỉ IPv6 multicast tất cả các nút ff02::1. Chúng tôi cũng đã thấy cách chỉ định giao diện nào sẽ sử dụng với địa chỉ IPv6 multicast tất cả các nút, vì bản thân địa chỉ đó không thể cung cấp thông tin này. Chúng tôi đã sử dụng tùy chọn dòng lệnh pinghoặc chỉ định giao diện bằng hậu tố %<zone_id>.
Sau đó, chúng ta đã tìm hiểu về các địa chỉ Link-Local unicast, là những địa chỉ được sử dụng để đáp ứng các yêu cầu tiếng vang ICMPv6 đa hướng của tất cả các nút.
Chúng tôi cũng đã thấy cách các gói multicast được trả về nút gửi theo mặc định và cách tắt tính năng này cho tiện ích ping.
Cuối cùng, chúng tôi đã ping một địa chỉ Link-Local duy nhất bằng hậu tố %<zone_id>, vì bản thân các địa chỉ Link-Local cũng không cung cấp thông tin về giao diện gửi đi.
Vậy còn việc ping tất cả các nút khác và nhận địa chỉ unicast toàn cầu (GUA) (nghĩa là địa chỉ công khai của chúng trên Internet) hoặc địa chỉ unicast cục bộ (ULA) duy nhất của chúng thì sao? Chúng ta sẽ xem xét điều này trong bài viết blog tiếp theo.
Đó là tất cả.
Bạn có thể tìm hiểu thêm về khóa học của chúng tôi tại.
Nguồn: www.habr.com