פינג לכל צמתי IPv6 בערוץ

נותרו מספר ימים עד לתחילת זרימה חדשה בקצב "מהנדס רשת" מ-OTUS. בהקשר זה, ברצוננו לשתף אתכם בתרגום של חומר שימושי בנושא.

סדרה של פוסטים בבלוג על טיפים וטריקים לפתרון בעיות של פינג IPv6 (ICMPv6 Echo Request/Echo Reply)

שים לב שאני משתמש בלינוקס (במיוחד בפדורה 31), אולם תחביר פקודת ה-ping עבור מערכות הפעלה אחרות אמור להיות מאוד דומה.

פינג לכל צמתי IPv6 בערוץ

הטיפ הראשון והפשוט ביותר הוא לעשות פינג לכל צמתי ה-IPv6 בקישור.

IPv6 משתמש בכתובות ריבוי שידור עבור כל סוגי התקשורת של אחד לרבים. אין כתובות IPv6 לשידור (או שידור). זה מבדיל את ה-IPv6 מ-IPv4, שבו ישנם מספר סוגים של כתובות שידור, למשל, כתובת "השידור מוגבל" 255.255.255.255 [RFC1122].

עם זאת, קיימת כתובת IPv6 של "כל הצמתים מרובי שידור", אז נשתמש בה כדי לבצע פינג לכל צמתי ה-IPv6 בקישור. (כתובת "שידור" היא למעשה רק כתובת מרובת שידור בעלת שם מיוחד, שהיא קבוצת שידור מרובת שידור הכוללת את כל הצמתים. שימו לב, למשל, סיבית הכתובת "קבוצה" או מרובת שידור מופעלת בכתובות שידור Ethernet בשכבת הקישור. ).

כתובת IPv6 של כל הצמתים לריבוי שידורים עבור הערוץ: ff02::1. ff מציין כתובת IPv6 לשידור רב. ה-0 הבא הוא החלק של הדגל עם ביטים לא מוגדרים.

המשך 2 מגדיר את השטח של קבוצת ריבוי שידורים. שלא כמו כתובות IPv4 לשידורים מרובי שידור, לכתובות IPv6 שידור רב שידור יש היקף. ערך ה-scope מציין את החלק של הרשת שעבורו מותר להעביר חבילת ריבוי שידור. ברגע שחבילה מגיעה לגבול ההיקף שצוין, יש לשחרר את החבילה, ללא קשר לשאלה אם שדה ספירת ההופ שלה אינו אפס. כמובן, אם ספירת הקפיצות מגיעה לאפס לפני שהיא מגיעה לגבול קבוצת ריבוי השידורים שצוין, היא גם מאופסת מיד. הנה רשימה מלאה של היקף IPv6 multicast.

לבסוף, ::1 מציין קבוצת ריבוי שידורים של כל הצמתים.

לגבי הכתובת ff02::1 יש לציין שזה מעורפל. במארח IPv6 עם ממשקים מרובים, כגון נתב או מארח רב-הומי, הכתובת ff02::1 אין שום דבר שבו אתה יכול לציין לאיזה ממשק לשלוח בקשות ICMPv6 echo או לצפות לקבל תשובות ICMPv6 echo כשהן מגיעות. ff02::1 תקף וניתן להשתמש בו בכל אחד מהממשקים והערוצים המחוברים לצומת מרובה הממשקים.

אז כשאנחנו עושים פינג לכל צמתי ה-IPv6 בקישור, אנחנו צריכים איכשהו לספר גם לתוכנית השירות ping עבור IPv6, באיזה ממשק להשתמש.

הגדרת ממשקים - אפשרות שורת פקודה

כפי שכבר ראינו, כתובת ה-multicast של כל הצמתים שבה אנו רוצים להשתמש היא - ff02::1 - אינו מספק מידע לגבי איזה ממשק לשלוח ולקבל מנות ICMPv6 echo request והד תשובות.

אז, כיצד אנו מציינים את הממשק שישמש עבור מרחב הכתובות של ריבוי שידורים או מרחב הכתובות של unicast Link-Local?

הדרך הראשונה והברורה ביותר היא לספק אותו כפרמטר לאפליקציה בה אנו משתמשים.

לתועלת 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 multicast הכולל של כל הצמתים, קיבלנו תגובות מ-6 צמתים IPv6. התגובות הגיעו מכתובות של צומת IPv6 של Link-Local, החל בקידומת fe80::/10.

כי ping אינו ממשיך לשלוח בקשות ICMPv6 echo ללא הגבלת זמן עד שאנו מפריעים לו, בדרך כלל אנו מציינים את מספר החבילות שיש לשלוח באמצעות האפשרות -c. עם זאת, זה גם מונע מ-ping לקבל ולהציג יותר מתשובת ICMPv6 echo אחת בעת שליחת בקשת הד ICMPv6 multicast. במקום זאת, השתמשנו באפשרות -w כדי לציין שה-ping צריך להסתיים לאחר שנייה אחת, לא משנה כמה בקשות הד ICMPv1 או תשובות הד נשלחו או התקבלו.

דבר נוסף שצריך לשים לב אליו הוא (DUP!) פלט על התשובות השנייה והאחריות. מנות אלו מזוהות כתגובות כפולות מכיוון שיש להן אותו ערך רצף ICMP כמו בקשות ההד הבודדות של ICMPv6 שנשלחו מלכתחילה. הם מופיעים מכיוון שבקשת הד ICMPv6 מרובה שידור גורמת למספר תגובות חד-שידור בודדות. מספר הכפילויות מצוין גם בסיכום הסטטיסטיקה.

הגדרת ממשקים - מזהה אזור

דרך נוספת לחשוף ממשק לשימוש היא כחלק מפרמטר כתובת IPv6.

אנו יכולים לראות דוגמה לכך בפלט הפינג, שבו גם הכתובות של מארח ה-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 שונים המחוברים לאותו ערוץ. ממשקים אלה חברים באותו אזור.

זה אמור להיות אפשרי לקבץ מספר ממשקים בתוך אזור תחת מערכת ההפעלה; כרגע אני לא יודע אם זה אפשרי תחת לינוקס או איך לעשות את זה.

שימוש בסיומת %<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 ~]$

קישור-כתובת מקומית תגובות

מהפינג מרובה-שידור הכל-צמתים הזה קיבלנו בסך הכל 6 תגובות ייחודיות.

התגובות הללו הגיעו מכתובות מארח unicast Link-Local IPv6. לדוגמה, הנה התשובה הראשונה:

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 Version 6". הסיבה לכך היא שלצומת IPv6 יש תמיד באופן אוטומטי כתובת IPv6 unicast, שבה הוא יכול לפחות להשתמש כדי לתקשר עם צמתים אחרים בקישורים המחוברים ישירות שלו. זה כולל תקשורת עם יישומים במארחים אחרים באמצעות כתובות מארח Link-Local.

זה מפשט את התכנון והיישום של פרוטוקולים כגון IPv6 Neighbor Discovery ו-OSPFv3. זה גם מאפשר ליישומי משתמש קצה במארחים לתקשר דרך הערוץ מבלי לדרוש תשתית IPv6 תומכת אחרת בערוץ. תקשורת ישירה בין מארחי IPv6 מחוברים אינה דורשת נתב IPv6 או שרת DHCPv6 בחיבור.

כתובות קישור מקומיות מתחילות בקידומת של 10 סיביות fe80, ואחריו 54 אפס סיביות ולאחר מכן מזהה ממשק של 64 סיביות (IID). בתשובה הראשונה לעיל 2392:6213:a15b:66ff הוא IID של 64 סיביות.

Multicast בלולאה

כברירת מחדל, מנות ריבוי שידור מוחזרות באופן פנימי לצומת ששלח אותן. זה קורה גם עבור כתובת IPv6 וגם עבור IPv4.

הסיבה להתנהגות ברירת מחדל זו היא שכאשר נשלחות מנות ריבוי שידור, ייתכן שיש גם יישום ריבוי שידור מקומי מאזין הפועל על המארח השולח עצמו, כמו גם במקום כלשהו ברשת. יישום מקומי זה חייב לקבל גם חבילות שידור רב-שידור.

אנו יכולים לראות את הלולאה המקומית של ריבוי שידורים בפלט הפינג שלנו:

[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 אלפיות השנייה לעומת 0,453 אלפיות השנייה) מגיעה מהכתובת 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. אם אנו שולחים פינג מרובה שידור של כל הצמתים עם הדגל הזה, אז התגובות מוגבלות לצמתים מרוחקים. איננו מקבלים תשובה מהכתובת 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!)
...

פינג קישור-כתובות מקומיות

כפי שאתה יכול לנחש, כתובות unicast Link-Local כשלעצמן גם אינן מספקות מספיק מידע כדי לציין באיזה ממשק להשתמש כדי להגיע אליהן. כמו ב-all-nodes multicast ping, אנחנו צריכים גם לציין את הממשק כפרמטר שורת פקודה ping או מזהה אזור עם כתובת בעת פינג כתובות Link-Local.

הפעם נוכל להשתמש -cלהגביל את מספר החבילות והתגובות שנשלחו והתקבלו ping, מכיוון שאנו מבצעים 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 ~]$

פינג (כל) כתובות IPv6 אחרות?

במאמר זה ראינו כיצד לבצע פינג לכל צמתי ה-IPv6 בערוץ באמצעות כתובת IPv6 של כל הצמתים. ff02::1. ראינו גם כיצד לציין באיזה ממשק להשתמש עם כתובת IPv6 של כל הצמתים, מכיוון שהכתובת עצמה אינה יכולה לספק מידע זה. השתמשנו או באפשרות שורת הפקודה ping, או ציינו את הממשק באמצעות הסיומת %<zone_id>.

לאחר מכן למדנו על כתובות unicast Link-Local, שהן כתובות המשמשות להגיב לבקשות הד של ICMPv6 multicast של כל הצמתים.

ראינו גם כיצד מנות שידור מרובות מוחזרות לצומת השליחה כברירת מחדל וכיצד להשבית זאת עבור כלי השירות ping.

לבסוף, פינגנו כתובת Link-Local אחת באמצעות הסיומת %<zone_id>, שכן גם כתובות Link-Local עצמן אינן מספקות מידע על הממשק היוצא.

אז מה לגבי פינג לכל הצמתים האחרים ולקבל את כתובות ה-unicast העולמיות (GUA) (כלומר, הכתובות הציבוריות שלהם באינטרנט) או כתובות unicast המקומיות הייחודיות (ULAs)? נסתכל על זה בפוסט הבא בבלוג.

זה הכל.

תוכל לברר עוד על הקורס שלנו בכתובת הערות יום פתוח.

מקור: www.habr.com