ปิงโหนด IPv6 ทั้งหมดบนช่องสัญญาณ

เหลือเวลาอีกไม่กี่วันจนกว่าจะเริ่มกระแสใหม่ตามอัตรา “วิศวกรเครือข่าย” จากโอทัส. ในเรื่องนี้เราต้องการแบ่งปันคำแปลเนื้อหาที่เป็นประโยชน์ในหัวข้อนี้กับคุณ

ชุดโพสต์บล็อกเกี่ยวกับคำแนะนำและเคล็ดลับในการแก้ไขปัญหาการ Ping ของ IPv6 (ICMPv6 Echo Request/Echo Reply)

โปรดทราบว่าฉันใช้ Linux (โดยเฉพาะ Fedora 31) อย่างไรก็ตาม ไวยากรณ์คำสั่ง ping สำหรับระบบปฏิบัติการอื่นน่าจะคล้ายกันมาก

ปิงโหนด IPv6 ทั้งหมดบนช่องสัญญาณ

เคล็ดลับแรกและง่ายที่สุดคือการ ping โหนด IPv6 ทั้งหมดในลิงก์

IPv6 ใช้ที่อยู่แบบหลายผู้รับสำหรับการสื่อสารแบบหนึ่งต่อกลุ่มทุกประเภท ไม่มีการออกอากาศ (หรือการออกอากาศ) ที่อยู่ IPv6 สิ่งนี้ทำให้ IPv6 แตกต่างจาก IPv4 โดยมีที่อยู่การออกอากาศหลายประเภท เช่น ที่อยู่ "การออกอากาศแบบจำกัด" 255.255.255.255 [RFC1122]

อย่างไรก็ตาม มีที่อยู่ IPv6 “ทุกโหนดมัลติคาสต์” ดังนั้นเราจะใช้ที่อยู่นั้นเพื่อ ping โหนด IPv6 ทั้งหมดในลิงก์ (ที่อยู่ "การออกอากาศ" จริงๆ แล้วเป็นเพียงที่อยู่มัลติคาสต์ที่มีชื่อพิเศษ ซึ่งเป็นกลุ่มมัลติคาสต์ที่มีโหนดทั้งหมด โปรดทราบว่า ตัวอย่างเช่น บิตที่อยู่ "กลุ่ม" หรือมัลติคาสต์ถูกเปิดใช้งานในที่อยู่การออกอากาศอีเทอร์เน็ตที่ชั้นลิงก์ ).

ที่อยู่ IPv6 แบบมัลติคาสต์ทุกโหนดสำหรับช่องสัญญาณ: ff02::1. ff หมายถึงที่อยู่ IPv6 แบบหลายผู้รับ 0 ถัดไปคือส่วนหนึ่งของแฟล็กที่มีบิตที่ไม่ได้ตั้งค่า

ต่อไป 2 กำหนดพื้นที่ของกลุ่มมัลติคาสต์ ที่อยู่ IPv4 แบบหลายผู้รับต่างจากที่อยู่ IPv6 แบบหลายผู้รับตรงที่มีขอบเขต ค่าขอบเขตระบุส่วนของเครือข่ายที่อนุญาตให้ส่งต่อแพ็กเก็ตแบบหลายผู้รับ เมื่อแพ็กเก็ตถึงขอบเขตของขอบเขตที่ระบุ แพ็กเก็ตนั้นจะต้องถูกทิ้ง โดยไม่คำนึงว่าฟิลด์ Hop Count นั้นจะไม่เป็นศูนย์หรือไม่ แน่นอนว่า หากจำนวนฮอปถึงศูนย์ก่อนที่จะถึงขอบเขตกลุ่มมัลติคาสต์ที่ระบุ ก็จะถูกรีเซ็ตทันทีเช่นกัน นี่คือรายการขอบเขตมัลติคาสต์ IPv6 ทั้งหมด

ในที่สุด ::1 ระบุกลุ่มมัลติคาสต์ทุกโหนด

เกี่ยวกับที่อยู่ ff02::1 ควรสังเกตว่ามันไม่ชัดเจน บนโฮสต์ IPv6 ที่มีหลายอินเทอร์เฟซ เช่น เราเตอร์หรือโฮสต์แบบ multihomed ที่อยู่ ff02::1 ไม่มีสิ่งใดที่คุณสามารถระบุได้ว่าอินเทอร์เฟซใดที่จะส่งคำขอ ICMPv6 echo ไปยังหรือคาดว่าจะได้รับการตอบกลับ ICMPv6 echo เมื่อมาถึง ff02::1 ถูกต้องและสามารถใช้ได้กับอินเทอร์เฟซและช่องสัญญาณใด ๆ ที่เชื่อมต่อกับโหนดหลายอินเทอร์เฟซ

ดังนั้นเมื่อเรา ping โหนด IPv6 ทั้งหมดบนลิงก์ เราจำเป็นต้องบอกยูทิลิตี้ด้วย ping สำหรับ IPv6 จะใช้อินเทอร์เฟซใด

การกำหนดอินเทอร์เฟซ - ตัวเลือกบรรทัดคำสั่ง

ดังที่เราได้เห็นแล้ว ที่อยู่มัลติคาสต์โหนดทั้งหมดที่เราต้องการใช้คือ − ff02::1 - ไม่ได้ให้ข้อมูลใดๆ เกี่ยวกับอินเทอร์เฟซที่จะส่งและรับคำขอ ICMPv6 echo และแพ็กเก็ตตอบกลับ echo

แล้วเราจะระบุอินเทอร์เฟซที่จะใช้สำหรับพื้นที่ที่อยู่แบบหลายผู้รับหรือพื้นที่ที่อยู่แบบลิงก์-ท้องถิ่นแบบผู้รับเดียวได้อย่างไร

วิธีแรกและชัดเจนที่สุดคือให้มันเป็นพารามิเตอร์ให้กับแอปพลิเคชันที่เราใช้

เพื่อประโยชน์ใช้สอย ping เราจัดหาให้ผ่านตัวเลือก -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 ~]$

การใช้ Ping แบบมัลติคาสต์ทุกโหนดนี้ ทำให้เราได้รับการตอบสนองจากโหนด IPv6 จำนวน 6 โหนด การตอบกลับมาจากที่อยู่โหนด Link-Local IPv6 โดยเริ่มจากคำนำหน้า fe80::/10.

ที่ ping จะไม่ส่งคำขอ ICMPv6 echo ต่อไปอย่างไม่มีกำหนดจนกว่าเราจะขัดจังหวะ โดยปกติเราจะระบุจำนวนแพ็กเก็ตที่จะส่งผ่านตัวเลือก -c อย่างไรก็ตาม วิธีนี้จะป้องกันไม่ให้ ping ยอมรับและแสดงการตอบกลับ ICMPv6 echo มากกว่าหนึ่งรายการเมื่อส่งคำขอ echo ICMPv6 แบบหลายผู้รับ แต่เรากลับใช้ตัวเลือก -w เพื่อระบุว่าการ ping ควรเสร็จสิ้นหลังจากผ่านไป 1 วินาที ไม่ว่าคำขอ ICMPv6 echo หรือการตอบกลับ echo จะถูกส่งหรือรับกี่ครั้งก็ตาม

อีกสิ่งหนึ่งที่ควรใส่ใจคือ (DUP!) เอาต์พุตสำหรับคำตอบที่สองและคำตอบถัดไป แพ็กเก็ตเหล่านี้ถูกระบุว่าเป็นการตอบกลับที่ซ้ำกันเนื่องจากมีค่าลำดับ ICMP เดียวกันกับคำขอ ICMPv6 echo แต่ละรายการที่ถูกส่งตั้งแต่แรก ปรากฏขึ้นเนื่องจากการร้องขอ multicast echo ของ ICMPv6 ส่งผลให้เกิดการตอบสนองแบบ unicast แต่ละรายการ จำนวนรายการที่ซ้ำกันยังระบุอยู่ในสรุปสถิติด้วย

การกำหนดอินเทอร์เฟซ - รหัสโซน

อีกวิธีหนึ่งในการเปิดเผยอินเทอร์เฟซสำหรับการใช้งานคือเป็นส่วนหนึ่งของพารามิเตอร์ที่อยู่ IPv6

เราเห็นตัวอย่างนี้ได้ในเอาต์พุต ping โดยที่ที่อยู่ของโฮสต์ IPv6 ที่ตอบสนองจะมีส่วนต่อท้ายด้วย %enp3s2ตัวอย่างเช่น:

64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms

วิธีการระบุอินเทอร์เฟซนี้มีอธิบายอย่างเป็นทางการใน [RFC4007], "สถาปัตยกรรมที่อยู่ที่กำหนด IPv6" แม้ว่าโดยทั่วไปจะเรียกว่าส่วนต่อประสานระบบปฏิบัติการ แต่จริงๆ แล้วพวกมันกำหนดบางสิ่งที่กว้างกว่านั่นคือ "โซน" หรือ "ขอบเขต"

เหตุผลในการมีโซนทั่วไปหรือโซนขอบเขตมากขึ้นก็คือ ตามที่กล่าวไว้ใน [RFC4007] โหนด IPv6 สามารถมีอินเทอร์เฟซ IPv6 ที่แตกต่างกันหลายรายการที่เชื่อมต่อกับช่องสัญญาณเดียวกัน อินเทอร์เฟซเหล่านี้เป็นสมาชิกของโซนเดียวกัน

ควรเป็นไปได้ที่จะจัดกลุ่มอินเทอร์เฟซหลายรายการภายในโซนภายใต้ระบบปฏิบัติการ ขณะนี้ฉันไม่รู้ว่าสิ่งนี้เป็นไปได้บน Linux หรือทำอย่างไร

การใช้คำต่อท้าย %<zone_id>เราสามารถลบตัวเลือกบรรทัดคำสั่งได้ -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 ~]$

การตอบสนองที่อยู่ลิงค์ภายในเครื่อง

จาก multicast ping ของโหนดทั้งหมดนี้ เราได้รับการตอบกลับที่ไม่ซ้ำกันทั้งหมด 6 รายการ

การตอบสนองเหล่านี้มาจากที่อยู่โฮสต์ IPv6 ของ unicast Link-Local ตัวอย่างเช่น นี่คือคำตอบแรก:

64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms

จำเป็นต้องมีที่อยู่ IPv6 แบบ Unicast Link-Local บนอินเทอร์เฟซที่เปิดใช้งาน IPv6 ทั้งหมด [RFC4291] “สถาปัตยกรรมการกำหนดที่อยู่ IP เวอร์ชัน 6” เหตุผลก็คือโหนด IPv6 จะมีที่อยู่ IPv6 แบบผู้รับเดียวโดยอัตโนมัติเสมอ ซึ่งอย่างน้อยก็สามารถใช้เพื่อสื่อสารกับโหนดอื่นๆ บนลิงก์ที่เชื่อมต่อโดยตรงได้ ซึ่งรวมถึงการสื่อสารกับแอปพลิเคชันบนโฮสต์อื่นผ่านที่อยู่โฮสต์ Link-Local

ซึ่งช่วยลดความยุ่งยากในการออกแบบและการใช้งานโปรโตคอล เช่น IPv6 Neighbor Discovery และ OSPFv3 นอกจากนี้ยังอนุญาตให้แอปพลิเคชันผู้ใช้ปลายทางบนโฮสต์สามารถสื่อสารผ่านช่องทางโดยไม่ต้องใช้โครงสร้างพื้นฐาน IPv6 ที่รองรับอื่น ๆ บนช่องทาง การสื่อสารโดยตรงระหว่างโฮสต์ IPv6 ที่เชื่อมต่อไม่จำเป็นต้องใช้เราเตอร์ IPv6 หรือเซิร์ฟเวอร์ DHCPv6 ในการเชื่อมต่อ

ที่อยู่ Link-Local เริ่มต้นด้วยคำนำหน้า 10 บิต fe80ตามด้วยศูนย์บิต 54 บิต และตัวระบุอินเทอร์เฟซ (IID) 64 บิต ในคำตอบแรกข้างต้น 2392:6213:a15b:66ff เป็น IID 64 บิต

มัลติคาสต์แบบวนซ้ำ

ตามค่าเริ่มต้น แพ็กเก็ตแบบหลายผู้รับจะถูกส่งกลับภายในไปยังโหนดที่ส่งแพ็กเก็ตเหล่านั้น สิ่งนี้เกิดขึ้นกับทั้งการกำหนดที่อยู่ IPv6 และ IPv4

เหตุผลสำหรับลักษณะการทำงานเริ่มต้นนี้คือ เมื่อมีการส่งแพ็กเก็ตแบบหลายผู้รับ อาจมีแอปพลิเคชันมัลติคาสต์ภายในเครื่องที่กำลังฟังทำงานบนโฮสต์ที่ส่งเอง เช่นเดียวกับที่ใดที่หนึ่งบนเครือข่าย แอปพลิเคชันภายในเครื่องนี้ยังต้องได้รับแพ็กเก็ตแบบหลายผู้รับด้วย

เราจะเห็น multicast local loop ในเอาต์พุต 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!)
...

การตอบสนองครั้งแรกและเร็วที่สุด (0,106 ms เทียบกับ 0,453 ms) มาจากที่อยู่ Link-Local ที่กำหนดค่าไว้บนอินเทอร์เฟซ enp3s2.

[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
    inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute 
[mark@opy ~]$

คุณประโยชน์ ping จัดเตรียมวิธีการระงับการตอบรับมัลติคาสต์ในเครื่องโดยใช้พารามิเตอร์ -L. หากเราส่ง Ping แบบหลายผู้รับทุกโหนดด้วยแฟล็กนี้ การตอบสนองจะถูกจำกัดไว้ที่โหนดระยะไกล เราไม่ได้รับการตอบกลับจากที่อยู่ Link-Local ของอินเทอร์เฟซการส่ง

[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!)
...

Ping Link-ที่อยู่ท้องถิ่น

ดังที่คุณอาจเดาได้ว่าที่อยู่ Link-Local แบบผู้รับเดียวไม่ได้ให้ข้อมูลเพียงพอที่จะระบุว่าจะใช้อินเทอร์เฟซใดในการเข้าถึงที่อยู่เหล่านั้น เช่นเดียวกับ multicast ping ของโหนดทั้งหมด เรายังต้องระบุอินเทอร์เฟซเป็นพารามิเตอร์บรรทัดคำสั่งด้วย ping หรือรหัสโซนพร้อมที่อยู่เมื่อส่ง Ping ไปยังที่อยู่ Link-Local

ครั้งนี้เราสามารถใช้ได้ -cเพื่อจำกัดจำนวนแพ็กเก็ตและการตอบกลับที่ส่งและรับ pingเนื่องจากเรากำลังดำเนินการ ping แบบผู้รับเดียว

[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 ~]$

ปิง (ทั้งหมด) ที่อยู่ IPv6 อื่น ๆ หรือไม่

ในบทความนี้ เราได้เห็นวิธีการ ping โหนด IPv6 ทั้งหมดบนช่องสัญญาณโดยใช้ที่อยู่ IPv6 แบบหลายผู้รับทุกโหนด ff02::1. นอกจากนี้เรายังได้เห็นวิธีการระบุอินเทอร์เฟซที่จะใช้กับที่อยู่ IPv6 แบบมัลติคาสต์ทุกโหนด เนื่องจากตัวที่อยู่ไม่สามารถให้ข้อมูลนี้ได้ เราใช้ตัวเลือกบรรทัดคำสั่งอย่างใดอย่างหนึ่ง pingหรือระบุอินเทอร์เฟซโดยใช้ส่วนต่อท้าย %<zone_id>.

จากนั้นเราได้เรียนรู้เกี่ยวกับที่อยู่ Link-Local แบบผู้รับเดียว ซึ่งเป็นที่อยู่ที่ใช้ในการตอบสนองต่อคำขอ echo ICMPv6 แบบหลายผู้รับแบบหลายผู้รับโหนดทั้งหมด

นอกจากนี้เรายังเห็นว่าแพ็กเก็ตมัลติคาสต์ถูกส่งคืนไปยังโหนดการส่งตามค่าเริ่มต้นอย่างไร และวิธีปิดใช้งานสิ่งนี้สำหรับยูทิลิตี้ ping.

ในที่สุด เราก็ส่ง Ping ไปยังที่อยู่ Link-Local เดียวโดยใช้ส่วนต่อท้าย %<zone_id>เนื่องจากที่อยู่ Link-Local เองก็ไม่ได้ให้ข้อมูลเกี่ยวกับอินเทอร์เฟซขาออกด้วย

แล้วการ ping โหนดอื่นๆ ทั้งหมดและรับที่อยู่ Unicast ทั่วโลก (GUA) (นั่นคือ ที่อยู่สาธารณะบนอินเทอร์เน็ต) หรือที่อยู่ Unicast ในพื้นที่เฉพาะ (ULA) ล่ะ เราจะดูสิ่งนี้ในโพสต์บล็อกถัดไป

นั่นคือทั้งหมดที่

คุณสามารถหาข้อมูลเพิ่มเติมเกี่ยวกับหลักสูตรของเราได้ที่ บันทึกวันเปิด.

ที่มา: will.com