רשת מקומית ללא IPv4 – סיקור טכני על איך הדבר מתאפשר

רשת מקומית ללא פרוטוקול IPv4 עשויה לעזור למנהלי רשתות בניהול יעיל יותר של הרשת הארגונית שלהם. לא רק ניהול יעיל הוא נחלת רשת LAN ללא IPv4, אלא גם רשת כזאת תעזור באבטחת הרשת והמידע שעובר בו. השאלה המתבקשת מ"פרוייקט" מעניין שכזה – איך יתאפשר חיבור לשירותים רבים באינטרנט שנגישים רק בקישוריות IPv4? התשובה פשוטה – שימוש בטכניקת NAT64 (בשילוב של DNS64 וגם 464XLAT) פותר את הבעיה.

אז איך מארגנים דבר שכזה? קודם כל – דרוש ידע ברשתות תקשורת. ידע שהוא הרבה מעבר לידע בסיסי ברשתות. אם אתם משתמשים ביתיים, כנראה שסיקור טכני כזה הוא Overkill, למרות שניתן ליישום אם תרצו בכך כדי ללמוד. אני בתור משתמש ביתי מפעיל נתב שהוא למעשה PC ישן, אשר מפעיל הפצת לינוקס (למתעניינים, מדובר בArchlinux). אני לא אסביר על איך לבנות נתב משלכם, כי אפשר ללמוד את זה גם במקורות אחרים ולכן הדבר לא מכוסה בסיקור הטכני הזה. בהערת אגב אציין שאפשר להשתמש גם בנתבים של החברות הידועות עם Tomato וOpenWRT (והפצות לינוקס אחרות שמותאמות לנתבים, אם תרצו). אני לצורך הנוחות משתמש בנתב שאני בניתי, פשוט כי אני רגיל לעבוד עם PC קונבציונלי ונוח. המסקנה המתבקשת שדרוש ידע בלינוקס. גם זה לא מכוסה במדריך הזה מכיוון שיש הרבה מדריכים טובים (אפשר לחפש בגוגל) על לינוקס.

אז בעצם איך כל הדבר "המופלא" הזה קורה? שאלה מצויינת. נצטרך להביט בקצת מסמכים וציורים כדי להבין מי נגד מי.

תוצאת תמונה עבור ‪NAT64‬‏

תמונה של דיאגרמת רשת בשילוב NAT64

איך הדברים עובדים במצב של NAT64/DNS64 טהור? התהליך פשוט. אנחנו נבקש משרת DNS64, כמו של גוגל בכתובת:

 2001:4860:4860::6464

רשומת DNS לאתר מסויים. אם לדוגמה מדובר באתר כמו youtube.com, אנחנו נקבל רשומת AAAA עם כתובת IPv6 כזאת:

2a00:1450:4001:812::200e

מדובר ברשומת AAAA רגילה לחלוטין (במערכת הDNS, רשומת A היא רשומה שמצביעה לכתובת IPv4. רשומת AAAA, או QuadA בלשון עממית יותר, מצביעה לכתובת IPv6). הקליינט יתחבר באמצעות IPv6 ללא צורך בשימוש בתרגום NAT64. כדי להשתמש בNAT64, הוקצה תת-רשת IPv6 הזאת לפי מסמך הIETF הזה:

64:ff9b::/96

קידומת הרשת היא 96 סיביות. אורך כתובת IPv6 הוא 128 סיביות. 128 פחות 96 שווה 32, כלומר 32 סיביות – מדובר בתת רשת ש"מכילה" בתוכה את כל מרחב כתובות הIPv4.

אם ביקשנו רשומת DNS לאתר כמו ynet משרת הDNS64 של גוגל, אנחנו נקבל כתובת IPv6 כזו מכיוון שאין רשומת AAAA "רגילה" לynet היום (כי אין לynet תמיכה בIPv6 נכון לכתיבת הפוסט הזה):

64:ff9b::5f65:a0ce

הקליינט יתחבר עם הכתובת הזאת, מה שכמובן יועבר לNAT64 translator שידאג לקשר אותנו לאתר המיועד.

הבעיה במצב של NAT64/DNS64 טהור – אם אפליקציה לא משתשמת בDNS אלא מבקשת מידע מכתובת IPv4 בלי DNS – הדבר ייכשל כי אין קישוריות IPv4 אצל הלקוח ולכן החיבור יכשל. כדי לתקן את הבעיה הזו, אנו מוסיפים את מנגנון ה464XLAT, כך שכל תהליך קבלת הכתובת מתבצע כמתואר למעלה כרגיל, אך במידה ונבקש לשלוח מידע לכתובת IPv4 ללא שימוש בDNS, הקליינט ידאג לתרגם את כתובת הIPv4 לכתובת IPv6 (שיתורגמו בהמשך בחזרה לIPv4 ויועברו לרשת האינטרנט), כפי שניתן להבין ככה:

תוצאת תמונה עבור ‪464XLAT‬‏

תמונה של דיאגרמת רשת בשילוב NAT64 עם 464XLAT

לדוגמה – אם שלחנו מידע אל 8.8.8.8, למעשה המחשב שלנו יעשה המרה אוטומטית לכתובת IPv6 שהיא:

 64:ff9b::808:808

וכל זה ללא התערבות שלנו. לאחר מכן, המידע יגיע אל הNAT64 translator שנמצא על הGateway – ויעביר את מנת המידע בחזרה אל IPv4 – לכתובת 8.8.8.8, ומשם המידע יועבר אל רשת האינטרנט בפרוטוקול IPv4.

רשתות סלולר שמשתמשות בפרוטוקול IPv6 בלבד, משתמשות במנגנון NAT64/DNS64 בצירוף של 464XLAT (כמנגנון משלים). כך למעשה המכשיר הסלולרי מקבל כתובת IPv6 בלבד, אבל יכול להתחבר לשירותי אינטרנט בפרוטוקול IPv4 ללא כל בעיה.

כלומר – כך נראה התהליך בצורה המופשטת שלו:

8.8.8.8 (Client sends data to that IP) ---> 64:ff9b::808:808 (A CLAT client on the the Client Device turns 8.8.8.8 into fake IPv6 address) 
--> 8.8.8.8 (NAT64 translator on the gateway gets the fake IPv6 address and turns it back to IPv4 address, 
then forwards the data to the public IPv4 Internet)

זה התהליך. לאחר שהבנו, נצטרך להבין איך ממשים את זה. הדרישות הן פשוטות:

  • נתב שניתן לשליטה מרחוק. לכל הפחות, צריך שתהיה לכם אפשרות להתחבר בSSH (לא רצוי בכלל להשתמש בTelnet) לנתב.
  • נתב מבוסס הפצת לינוקס כלשהיא, בלי תלות בארכטיקטורת המעבד של הנתב. Debian, Ubuntu, OpenWRT או Tomato (והפצות לינוקס אחרות) עומדים לבחירתכם בהתאם לארכיטקטורה וסוג הנתב. אני בוחר כמובן בArchlinux על PC ישן. אני מניח כמובן שסידרתם את החייגן (PPPoE, אם אתם עדיין משתמשים בחייגן כמובן), הiptables (חוקי NAT לIPv4), יש לכם dhcpv6-pd שעובד באופן תקין (לקבלת קידומת רשת של IPv6 מהISP) ויש לכם מנגנון להפצת RAs (פרסומי נתב IPv6, בדרך ממומש באמצעות תוכנה בשם radvd).
  • יכולת שליטה בסיסית בטרמינל (מסך שחור לא מפחיד), ידע ביוניקס יעזור מאוד.
  • זמן פנוי – זה לא עובד בהכרח בניסיון ראשון.
  • רצון להשקיע וללמוד. תצטרכו לחקור כדי להבין. לא מבטיח שזה יהיה קל.
  • מחשב (או מכונה וירטואלית) על בסיס הפצת לינוקס. לצערי – לא מצאתי Client לCLAT בשביל Windows. מכשירי Android לא תומכים ב464XLAT על גבי WiFi (וגם לא תומכים ברשתות WiFi ללא קישוריות IPv4). מכשירי Windows יוכלו להנות ממנגנון NAT64/DNS64 טהור בלבד.

אז מה הדרך המימוש שאני אציג בסיקור הטכני הזה? הנה להלן מה שנעשה:

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

ראוי לציין שאני מסביר את תהליך ההתקנה וההגדרה מניסיוני האישי (יתכן גם שמה שעובד בשבילי לא בדיוק יעבוד בשבילכם – לכן דרוש לחקור). אינני לוקח כל אחריות על כל נזק כלשהו שייגרם מקריאת סיקור טכני זה.

קודם כל – עלינו להתקין tayga (מתרגם NAT64) על גבי הנתב שלנו כדי שיווצר מצב של NAT64/DNS64 רגיל. את הקוד אפשר למצוא כאן. אני ממליץ בחום כן להשתמש במנהל החבילות שלכם, אם הוא תומך בכך. בArchlinux נאלצתי לקמפל את הקוד, אבל יתכן שבהפצות לינוקס אחרות (כדוגמת Debian או Ubuntu) תוכלו להתקין באמצעות מנהל החבילות apt את החבילה ולא תצטרכו לקמפל את קוד המקור. בהנחה ואתם מקמפלים את הקוד על גבי הנתב, הנה התהליך –

אחרי שהורדתם את הקוד מקור וחילצתם את הקוד החוצה, עליכם לבצע את פעולת הקמפול (ויצירת תקייה שנדרשת לtayga):

./configure && make && make install && mkdir -p /var/db/tayga

לאחר מכן, תצטרכו לפתוח קובץ חדש, אפשרי בהחלט לעשות זאת ככה:

nano /usr/local/etc/tayga.conf

ושם תצטרכו לכתוב את הקונפיגורציה של הTranslator – מה שתצטרכו לשנות זה בפרמטר של ipv6-addr – לשים כתובת IPv6 חוקית בהתאם לקידומת רשת שהוקצתה לכם על ידי הISP:

tun-device nat64 # No need for changing
ipv4-addr 192.168.255.1 # this is the internal IPv4 address of Tayga, not the router address!
prefix 64:ff9b::/96 # this is the NAT64 prefix assigned by IETF document
ipv6-addr 2a02:XXXX::8 # You should assign a public IPv6 address if you use the NAT64 prefix assigned by IETF
dynamic-pool 192.168.255.0/24 # this is the dynamic pool so each device that needs NAT64 service, the translator will assign an IPv4 address
# from this pool for the session
data-dir /var/db/tayga # A needed data directory for TAYGA. Don't change.

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

נכין Interface לTranslator על ידי הרצת הפקודה הזאת:

tayga --mktun && ip link set nat64 up

ונגדיר לו את הכתובת IPv4 שלו (מבדיקתי, אין צורך בהגדרת כתובת IPv6 לinterface, אבל אם משהו משתבש – אצרף את הפקודה המתאימה):

ip addr add 192.168.0.1 dev nat64      (replace with your router's IPv4 address)
ip route add 192.168.255.0/24 dev nat64 (replace with your the assigned dynamic pool configured for TAYGA)
ip route add 64:ff9b::/96 dev nat64
tayga

אם יש צורך גם בכתובת הIPv6 של הנתב שלכם בinterface של הtranslator, הוסיפו אותו ככה:

ip addr add 2001:db8:1::1 dev nat64    (replace with your router's IPv6 address)

לאחר מכן, תוכלו לבדוק אם הtranslator עובד על ידי הרצת הפקודה הבאה על הנתב או באמצעות מכשיר אחר שמחובר לרשת:

ping 64:ff9b::808:808

אם אתם רואים שהכול תקין, ברכותיי! שירות NAT64 עובד. מנהלי רשת נבונים יבחינו מייד שהמצב הזה לא ישאר אחרי Reboot של הנתב והם צודקים. אני ממליץ בחום רב להמשיך לחקור על הפעלת שירותי מערכת במערכות Linux (רמז: חפשו בGoogle על systemd service) מכיוון שהסיקור הטכני הזה לא מכסה את העניין.

יכולתם עכשיו לבטל במחשב שלכם (בין אם מדובר על מחשב Windows או מחשב Linux) את הIPv4 stack, לשים בהגדרות הDNS את הכתובת:

 2001:4860:4860::6464

ולמעשה מעתה לעבוד עם השירות החדש. זה נכון שככה אפשר לעשות אם יש לכם מחשב עם מערכת הפעלה Windows. אם מערכת ההפעלה היא מבוססת Linux, יתכן ותרצו להמשיך עוד קצת.
מה בעצם נשאר לעשות, אם ברשותכם מחשב Linux? אתם יכולים להתקין קליינט CLAT, כך שבמקום לעבוד בסביבת NAT64/DNS64 טהור תפעילו את מנגנון 464XLAT.

איך הדבר יעשה? בפשטות. עליכם להוריד את הקבצים מכאן. מה שמעניין אותנו כרגע זה קובץ הclatd. מדובר בסקריפט שנכתב בשפה Perl. אני השתשמתי בקליינט Lubuntu ולכן דאגתי להתקנת הDependencies המתאימים להרצת הסקריפט כך (לא לשכוח להקיש את סיסמת המשתמש שלכם, בהנחה ואינכם משתמשים במשתמש root):

sudo apt-get install libnet-ip-perl && sudo apt-get install libnet-netmask-perl && sudo apt-get install libnet-dns-perl

תצטרכו גם שיהיה לכם TAYGA על המחשב שלכם. אתם יכולם לקמפל גם על המחשב של הלקוח TAYGA, אבל אם מדובר בהפצה מבוססת Debian, תוכלו להריץ את הפקודה הזאת:

sudo apt-get install tayga

לאחר מכן, העבירו את הסקריפט המחולץ למקום נוח יותר במערכת:

sudo mv clatd /usr/bin/

ולבסוף, כאשר הכול מוכן – הריצו:

sudo clatd

בהנחה שלא קיבלתם שום שגיאה, הכול מוכן! כך הדבר צריך להראות –


המחשב מחובר עם כתובת IPv6 בלבד. קליינט CLAT דואג להפעלת מנגנון 464XLAT

שימו לב בתמונה שכתובת הIPv4 היא Link-local, כלומר אין קישוריות IPv4 במחשב. בגלל המצאות שירות NAT64 על גבי הנתב שלי וקליינט CLAT על גבי המכונה, אין כל בעיה להתחבר לשירותי אינטרנט בפרוטוקול IPv4 אפילו כשלמחשב עצמו אין קישוריות IPv4 "אמיתית".

במידה ולא נפעיל את קליינט CLAT על המכונה, זאת תהיה התוצאה:

ככל הנראה, משתמשים ישימו לב שלאחר הפעלה מחדש של המחשב, המחשב יחזור לפעול עם שירות NAT64/DNS64 טהור. אז מה עושים? בקבצים שהורדתם שבין היתר כללו את הסקריפט של clatd, תמצאו גם קבצי שירות systemd. אני כמובן מפנה את הקוראים להמשיך לחקור על הפעלת שירותים באמצעות systemd, אם ירצו בכך.

לסיכום, בפוסט זה, הטכנולוגיה NAT64/DNS64 הוסברה בצורה הפשוטה ביותר לקוראינו. הוסבר על מנגנון 464XLAT וכמובן הוסבר על התקנה של המנגנון הזה על גבי הנתב שלכם ועל גבי מחשב שמחובר לרשת. המנגנון הזה משומש מאוד ברשתות סלולר שמפעילות קישוריות IPv6 בלבד כדי להמשיך לתת אפשרות להתחבר לשירותי אינטרנט בפרוטוקול IPv4, אך אפשר כפי שראיתם ליישמו גם ברשת שלכם.

סגירת תפריט