איך מחלקים את כתובות ה IP
- פותח הנושא הפרבולה
- פורסם בתאריך
IPv6
עד עכשיו זה עדיין לא תפס מספיק ומשתמשים ב-IPv4 אבל רוב המשתמשים הם מאחורי NAT.
 
אתה למשל בבית כנראה משתמש בראוטר אלחוטי שלו יש כתובת אחת מול העולם וכל דיירי הבית משתמשים בו.
 
זה קורה גם במקומות עבודה עם אלפי עובדים, יושבים מאחורי NAT וכולם יוצאים אל האינטרנט דרך מספר יחיד של כתובות אינטרנט.
עד עכשיו זה עדיין לא תפס מספיק ומשתמשים ב-IPv4 אבל רוב המשתמשים הם מאחורי NAT.
 
אתה למשל בבית כנראה משתמש בראוטר אלחוטי שלו יש כתובת אחת מול העולם וכל דיירי הבית משתמשים בו.
 
זה קורה גם במקומות עבודה עם אלפי עובדים, יושבים מאחורי NAT וכולם יוצאים אל האינטרנט דרך מספר יחיד של כתובות אינטרנט.
לדעתי יש להם טעות בהסבר
ציטוט:
פורט המקור המקורי מתורגם לפורט מקור גבוה הניתן על ידי הנתב. פורט זה משמש כאינדקס לטבלת ה-NAT כדי שהנתב יידע להתאים את מנת החזור ל-IP הפנימי אליו היא שייכת (שימוש זה בפורטים גבוהים הוא הפתרון לבעיה של הסתרת מספר כתובות פנימיות על ידי כתובת אחת).
לדעתי התרגום הוא לא רק מפורט המקור המקורי אלה גם על סמך ה IP המקורי בגלל שיכולים להגיע לנתב 2 הודעות משני מחשבים פנימיים שונים ( כלומר שני IP שונים ) אבל עם אותו מספר פורט מקור.
ציטוט:
פורט המקור המקורי מתורגם לפורט מקור גבוה הניתן על ידי הנתב. פורט זה משמש כאינדקס לטבלת ה-NAT כדי שהנתב יידע להתאים את מנת החזור ל-IP הפנימי אליו היא שייכת (שימוש זה בפורטים גבוהים הוא הפתרון לבעיה של הסתרת מספר כתובות פנימיות על ידי כתובת אחת).
לדעתי התרגום הוא לא רק מפורט המקור המקורי אלה גם על סמך ה IP המקורי בגלל שיכולים להגיע לנתב 2 הודעות משני מחשבים פנימיים שונים ( כלומר שני IP שונים ) אבל עם אותו מספר פורט מקור.
נראה לי שבשיטה הזאת של NAT מגדילים את מרחב הכתובות
של יחידות הקצה מ 32 ביט ל 48 ביט ( כיוון שמשתמשים בשדה פורט המקור שהוא 16 ביט גם לזיהוי יחידת הקצה ).
מסקנה: בפרוטוקול מבוסס IPv4 ושימוש ב NAT מכסימום התאורטי של האפליקציות ( קליינטים) שמתחברות לאינטרנט העולמי ( ביחידת קצה \ מחשב יכולות להיות כמה כאלו שנבדלות במספר פורט המקור) הוא רק 2 בחזקת 48 ( 281,474,976,710,656 ) .
של יחידות הקצה מ 32 ביט ל 48 ביט ( כיוון שמשתמשים בשדה פורט המקור שהוא 16 ביט גם לזיהוי יחידת הקצה ).
מסקנה: בפרוטוקול מבוסס IPv4 ושימוש ב NAT מכסימום התאורטי של האפליקציות ( קליינטים) שמתחברות לאינטרנט העולמי ( ביחידת קצה \ מחשב יכולות להיות כמה כאלו שנבדלות במספר פורט המקור) הוא רק 2 בחזקת 48 ( 281,474,976,710,656 ) .
החישוב שלך לא נכון.
תסתכל על כתובות פנימיות שהשרת שלך מחלק:
הן בד"כ מתחילות ב- 192.168.1
 
לא תראה כתובת "חיצונית" - כזו שקיבלת מספר האינרטנט שלך, שמתחילה בקידומת הזו.
 
נושא כתובות ה-IP מורכב יותר ממה שאתה חושב, כי "אינטרנט" היא "רשת של רשתות".
ה-IP מחולק לתחומים, ל-sub net ועוד כל מיני.
 
יש טווחים שלמים ששמורים למטרות מסוימות.
תסתכל על כתובות פנימיות שהשרת שלך מחלק:
הן בד"כ מתחילות ב- 192.168.1
 
לא תראה כתובת "חיצונית" - כזו שקיבלת מספר האינרטנט שלך, שמתחילה בקידומת הזו.
 
נושא כתובות ה-IP מורכב יותר ממה שאתה חושב, כי "אינטרנט" היא "רשת של רשתות".
ה-IP מחולק לתחומים, ל-sub net ועוד כל מיני.
 
יש טווחים שלמים ששמורים למטרות מסוימות.
חשבתי שכל אפלקיציה מזוהה בצורה יחידה בעולם
על ידי IP ומספר פורט שזה סה"כ 48 ביטים.
אבל כעת אני לא בטוח, למשל הסוגיה הבאה:
יש שתי יחידות קצה \אפליקציה במקומות שונים בעולם עם אותו IP פנימי ואותו מספר פורט ( סביר שיש הרבה כאלו, למשל מי שמתחבר דרך בזק מקבל תמיד משהו כמו 10.0.0.1 ) ושמחוברות כל אחד לנתב אחר שמדבר עם העולם דרך IP שונה.
וכעת אני רוצה להתחבר אל אחד מהם , הרי בפרטוקול TCP אני מציין את ה IP והפורט של מחשב היעד בלבד ( לא של הנתב(ים) שדרכם הוא מתחבר לעולם ).
כיצד הרשת תדע לנתב אותי ליחידית הקצה הנכונה ?
על ידי IP ומספר פורט שזה סה"כ 48 ביטים.
אבל כעת אני לא בטוח, למשל הסוגיה הבאה:
יש שתי יחידות קצה \אפליקציה במקומות שונים בעולם עם אותו IP פנימי ואותו מספר פורט ( סביר שיש הרבה כאלו, למשל מי שמתחבר דרך בזק מקבל תמיד משהו כמו 10.0.0.1 ) ושמחוברות כל אחד לנתב אחר שמדבר עם העולם דרך IP שונה.
וכעת אני רוצה להתחבר אל אחד מהם , הרי בפרטוקול TCP אני מציין את ה IP והפורט של מחשב היעד בלבד ( לא של הנתב(ים) שדרכם הוא מתחבר לעולם ).
כיצד הרשת תדע לנתב אותי ליחידית הקצה הנכונה ?
היא לא תדע, זה בדיוק העניין.
אתה לא יכול ליזום תקשורת מבחוץ למשהו שנמצא מאחורי NAT.
זו הסיבה למשל שתוכנות כמו Skype צריכים להעביר את כל התקשורת בינך לבין מי שאתה משוחח איתו דרך שרתים של MS, במקום לעשות חיבור ישיר.
 
יש כל מיני שיטות לתת לזה פתרון, אבל למיטב הבנתי הן עדיין דורשות משהו חיצוני:
https://en.wikipedia.org/wiki/NAT_traversal
 
לכן, שרת שאמורים ליזום תקשורת אליו, למשל כזה שמארח אתר, לעולם לא ישב מאחורי NAT.
אתה לא יכול ליזום תקשורת מבחוץ למשהו שנמצא מאחורי NAT.
זו הסיבה למשל שתוכנות כמו Skype צריכים להעביר את כל התקשורת בינך לבין מי שאתה משוחח איתו דרך שרתים של MS, במקום לעשות חיבור ישיר.
 
יש כל מיני שיטות לתת לזה פתרון, אבל למיטב הבנתי הן עדיין דורשות משהו חיצוני:
https://en.wikipedia.org/wiki/NAT_traversal
 
לכן, שרת שאמורים ליזום תקשורת אליו, למשל כזה שמארח אתר, לעולם לא ישב מאחורי NAT.
בידיוק כך ויש גם אפשרות נוספת...
כמו שכבר הסברת את זה, האפשרות הראשונה היא שרת שיושב על כתובת ציבורית ועליו נרשמים ( מתחברים או במילים אחרות יוזמים את החיבור ) לקוחות שחלקם גם יושבים מאחורי NAT והשרת הוא זה שיודע לנתב את התקשורת בין הלקוחות אלו ברמה של SESSIONS שהוא מנהל בין הלקוחות. כך נוצר המצב שהלקוחות לא יכולים לתקשר ישירות אחד עם השני, אבל יכולים לתקשר עם השרת ושם "להיפגש"
ואפשרות השנייה, היא שימוש במנגנון מסויים של NAT. מנגנון זה הוא PAT. במקרה זה ממפים פורט מסויים של כתובת פרטית שיושבת אחרי NAT לפורט של כתובת ציבורית שמקושרת למנגנון NAT. כך נוצר המצב שמי שפונה לפורט מוגדר זה של כתובת ציבורית מצד האינטרנט מגיעה בסופו של דבר לפורט של כתובת פרטית שמאחורי NAT.
למשל יש לנו לקוח שיושב על כתובת פרטית של 10.0.0.1 שמאחורי כתובת ציבורית 81.1.1.1 ושרת שיושב גם הוא על כתובת פרטית של 10.0.0.1 , אבל ברשת פרטית אחרת, שנמצאת מאחורי כתובת 81.1.1.2 ופורט 80 בכתובת זו מופנה לפורט 80 של 10.0.0.1. במקרה זה, אם לקוח פונה לפורט 80 של כתובת 81.1.1.2 , הוא בסופו של דבר יגיעה לשרת שנמצא מאחורי כתובת זו.
כך ניתן למפות גם מספר רב של שרתים שיושבים מאחורי אותה כתובת ציבורית ולאפשר גישה עליהם מהאינטרנט.
https://supportforums.cisco.com/t5/security-documents/pat/ta-p/3114711
כמו שכבר הסברת את זה, האפשרות הראשונה היא שרת שיושב על כתובת ציבורית ועליו נרשמים ( מתחברים או במילים אחרות יוזמים את החיבור ) לקוחות שחלקם גם יושבים מאחורי NAT והשרת הוא זה שיודע לנתב את התקשורת בין הלקוחות אלו ברמה של SESSIONS שהוא מנהל בין הלקוחות. כך נוצר המצב שהלקוחות לא יכולים לתקשר ישירות אחד עם השני, אבל יכולים לתקשר עם השרת ושם "להיפגש"
ואפשרות השנייה, היא שימוש במנגנון מסויים של NAT. מנגנון זה הוא PAT. במקרה זה ממפים פורט מסויים של כתובת פרטית שיושבת אחרי NAT לפורט של כתובת ציבורית שמקושרת למנגנון NAT. כך נוצר המצב שמי שפונה לפורט מוגדר זה של כתובת ציבורית מצד האינטרנט מגיעה בסופו של דבר לפורט של כתובת פרטית שמאחורי NAT.
למשל יש לנו לקוח שיושב על כתובת פרטית של 10.0.0.1 שמאחורי כתובת ציבורית 81.1.1.1 ושרת שיושב גם הוא על כתובת פרטית של 10.0.0.1 , אבל ברשת פרטית אחרת, שנמצאת מאחורי כתובת 81.1.1.2 ופורט 80 בכתובת זו מופנה לפורט 80 של 10.0.0.1. במקרה זה, אם לקוח פונה לפורט 80 של כתובת 81.1.1.2 , הוא בסופו של דבר יגיעה לשרת שנמצא מאחורי כתובת זו.
כך ניתן למפות גם מספר רב של שרתים שיושבים מאחורי אותה כתובת ציבורית ולאפשר גישה עליהם מהאינטרנט.
https://supportforums.cisco.com/t5/security-documents/pat/ta-p/3114711
יש גם דרכים לעבוד על ה-NAT בעזרתו של שרת חיצוני
זה מין hack לא מומלץ כזה, אבל יש תוכנות שמשתמשות בו.
זה נקרא UPD hole punching:
https://en.wikipedia.org/wiki/UDP_hole_punching
 
זה מין hack לא מומלץ כזה, אבל יש תוכנות שמשתמשות בו.
זה נקרא UPD hole punching:
https://en.wikipedia.org/wiki/UDP_hole_punching
 
eladts
New member
הטריק הזה הוא חלק מסטנדרט WebRTC
שמשמש לישום VoIP בדפדפנים.
 
https://www.avaya.com/blogs/archive...brtc-media-connections-ice-stun-and-turn.html
שמשמש לישום VoIP בדפדפנים.
 
https://www.avaya.com/blogs/archive...brtc-media-connections-ice-stun-and-turn.html
למה לא תפס, יש מקומות שזה תפס גם תפס...
למה לא תפס, יש מקומות שזה תפס גם תפס. למשל אני כבר ברוב המקומות וגם בבית משתמש ב IPv6 כבר יותר מעשור ויש חלק מתחומים שבלי IPV6 מתחיל להיות די בלתי אפשרי. למשל כל הנושא של SIP ששם NAT הוא בלתי נסבל או במערכות של מצלמות אבטחה גדולות שגם שם לצורך גישה ישירה לרכיבים נדרשת כתובת מנותבת אמתית. גם מערכות של video conference מתפקדות יותר טוב על IPV6 ואפילו שיתוף קבצים PTP, כמו TORRENT וכו' עובד יותר טוב בלי NAT. כמובן שעדיין ברוב הרשתות שאני מתכנן אני עוד משתמש ב dual stack , אבל יותר ויותר שירותים כבר עוברים ל IPV6, כך שרוב התעבורה שלי היום היא כבר IPv6. הבעיה שבישראל נושא זה, כמו שאר דברים שקשורים לטכנולוגייה או לקידמה נשארו מאחרו שנות דור, אבל בסופו של דבר בשלב כלשהו גם לכאן זה יגיעה.
למה לא תפס, יש מקומות שזה תפס גם תפס. למשל אני כבר ברוב המקומות וגם בבית משתמש ב IPv6 כבר יותר מעשור ויש חלק מתחומים שבלי IPV6 מתחיל להיות די בלתי אפשרי. למשל כל הנושא של SIP ששם NAT הוא בלתי נסבל או במערכות של מצלמות אבטחה גדולות שגם שם לצורך גישה ישירה לרכיבים נדרשת כתובת מנותבת אמתית. גם מערכות של video conference מתפקדות יותר טוב על IPV6 ואפילו שיתוף קבצים PTP, כמו TORRENT וכו' עובד יותר טוב בלי NAT. כמובן שעדיין ברוב הרשתות שאני מתכנן אני עוד משתמש ב dual stack , אבל יותר ויותר שירותים כבר עוברים ל IPV6, כך שרוב התעבורה שלי היום היא כבר IPv6. הבעיה שבישראל נושא זה, כמו שאר דברים שקשורים לטכנולוגייה או לקידמה נשארו מאחרו שנות דור, אבל בסופו של דבר בשלב כלשהו גם לכאן זה יגיעה.
כל מדינה והבריכה שלה
https://www.iana.org/numbers
 
אני רק חצי צוחק, הארגון הזה אחראי לחלק "מאגרים" - באנגלית pool של כתובות לפי מדינות, ומשם לספקי אינטרנט.
 
זו כמובן תשובה לשאלה הראשונה שלך שלך "איך מחלקים", לא לשאלה השנייה ש-selalerer כבר ענה עליה.
https://www.iana.org/numbers
 
אני רק חצי צוחק, הארגון הזה אחראי לחלק "מאגרים" - באנגלית pool של כתובות לפי מדינות, ומשם לספקי אינטרנט.
 
זו כמובן תשובה לשאלה הראשונה שלך שלך "איך מחלקים", לא לשאלה השנייה ש-selalerer כבר ענה עליה.
computer helper
New member
למעשה זה הרבה פחות מ32
יש קלאסים שונים שתפוסים ועוד
יש קלאסים שונים שתפוסים ועוד
למעשה כבר מאז 1993 הסיפור של קלאסים נגמר והשימוש הוא ב CIDR
למעשה כבר מאז 1993 הסיפור של קלאסים נגמר והשימוש לצורך ההקצאות באינטרנט הוא ב CIDR, כשמו כן הוא, ללא שום כלאסים. דבר זה מקטין בצורה משמעותית ביותר את הביזבוז של חלוקת הכתובות. כך שבמשך שלוש עשורים כבר אין שום משמאות למונח של קלאסים בהקשר של IP או אינטרנט. גם חלק מ CIDRs שתפוסים לצרכים שונים, זה לצורך זה שאפשר יהיה למחזר את אותן הכתובות הפרטיות לשימוש חוזר אינסופי חלק אחר לצורך קבוצות תקשורת Multicast , דבר שנותן אפשרות של הורדת עומסים וצימצום של רוחב פס בתקשורת IP.
למעשה כבר מאז 1993 הסיפור של קלאסים נגמר והשימוש לצורך ההקצאות באינטרנט הוא ב CIDR, כשמו כן הוא, ללא שום כלאסים. דבר זה מקטין בצורה משמעותית ביותר את הביזבוז של חלוקת הכתובות. כך שבמשך שלוש עשורים כבר אין שום משמאות למונח של קלאסים בהקשר של IP או אינטרנט. גם חלק מ CIDRs שתפוסים לצרכים שונים, זה לצורך זה שאפשר יהיה למחזר את אותן הכתובות הפרטיות לשימוש חוזר אינסופי חלק אחר לצורך קבוצות תקשורת Multicast , דבר שנותן אפשרות של הורדת עומסים וצימצום של רוחב פס בתקשורת IP.
זה קצת יותר מורכב מזה, מצד אחד באמת ולא טעית ו ISP לא יכולים
זה קצת יותר מורכב מזה. מצד אחד באמת ולא טעית ו ISP לא יכולים לחלק כתובות "ציבוריות" בטווח של 192.168.0.0 או מטווח של 10.0.0.0 או טווחים פרטיים אחרים או טווחים כמו: 224.0.0.0 ועד ל 239.255.255.255 ששמור לתקשורת מולטיקסאט, אבל הספקים יכולים להשתמש בטווחים פרטיים לצורך שימוש במערכות ניתוב שלהם עד ללקוח. כך יוצא שהלקוח מקבל כתובת מנותבת, אבל בדרך קיימים כמה צמתים עם כתובות פרטיות ועדיין הניתוב מהלקוח לאינטרנט והפוך קיימים בצורה תקינה וה ISP חוסכים עוד כתובות אמיתיות.
אבל התגובה הקודמת שלי היתה על שימוש במונח של קלאס, מונח שלא קיים יותר כשלושה עשורים בגלל שהיום משתמשים בניתוב classless , דבר שנותן אפשרות לא לבזבז כתובתות סתם בגלל שימוש במנגנון של VLSM . מצורף הסבר פשוט:
https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing
מצורף גם צילום מסך של ניתוב שבו מסלול באחד ההופים עובר בכתובת פרטית ברשת של ISP.
זה קצת יותר מורכב מזה. מצד אחד באמת ולא טעית ו ISP לא יכולים לחלק כתובות "ציבוריות" בטווח של 192.168.0.0 או מטווח של 10.0.0.0 או טווחים פרטיים אחרים או טווחים כמו: 224.0.0.0 ועד ל 239.255.255.255 ששמור לתקשורת מולטיקסאט, אבל הספקים יכולים להשתמש בטווחים פרטיים לצורך שימוש במערכות ניתוב שלהם עד ללקוח. כך יוצא שהלקוח מקבל כתובת מנותבת, אבל בדרך קיימים כמה צמתים עם כתובות פרטיות ועדיין הניתוב מהלקוח לאינטרנט והפוך קיימים בצורה תקינה וה ISP חוסכים עוד כתובות אמיתיות.
אבל התגובה הקודמת שלי היתה על שימוש במונח של קלאס, מונח שלא קיים יותר כשלושה עשורים בגלל שהיום משתמשים בניתוב classless , דבר שנותן אפשרות לא לבזבז כתובתות סתם בגלל שימוש במנגנון של VLSM . מצורף הסבר פשוט:
https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing
מצורף גם צילום מסך של ניתוב שבו מסלול באחד ההופים עובר בכתובת פרטית ברשת של ISP.
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.