Dynamic Host Configuration Protocol
 | |
| תפריט הגדרות בשרת DHCP פשוט | |
| סוג |
פרוטוקול רשת מחשבים, פרוטוקול תקשורת  |
|---|---|
| שכבה |
שכבת היישום של מודל ה-OSI |
| פורט |
56 |
| מקור |
|
  | |
Dynamic Host Configuration Protocol (בראשי תיבות: DHCP; בתרגום חופשי: פרוטוקול הגדרת מארחים דינמי) הוא פרוטוקול תקשורת המשמש להקצאה של כתובות IP ייחודיות למחשבים ברשת מקומית (LAN). בנוסף לכתובת ה-IP, שרת DHCP בדרך כלל יספק למחשב גם נתונים כמו ה-Subnet mask, כתובת שרת ה-DNS וכתובת שער הגישה (Gateway), כך שהמחשב יוכל להתחיל לתפקד ברשת ללא צורך בנתונים נוספים. DHCP הוגדר לראשונה ב-1531 RFC[1] באמצע שנות ה-90.
DHCP מתפקד בשכבת היישום של מודל ה-OSI ובשכבת היישום של מודל ה-TCP/IP. הוא פועל מעל פרוטוקול התעבורה UDP על גבי פורטים 67 (שרת) ו-68 (לקוח) ומעל פרוטוקול הרשת IP, כאשר כל עוד הלקוח לא קיבל כתובת IP הוא משתמש באפסים (0) על־מנת לייצג את כתובתו והוא מזוהה על פי הכתובת הפיזית.
בעוד שאופן פעולת הפרוטוקול נשאר זהה, ברוב המוחלט של המקרים בימינו אין שימוש בשרתי DHCP ייעודיים - שרת DHCP יהיה בדרך כלל באותו הרכיב המאפשר שירותים נוספים, כמו נתב, שרת DNS ועוד.
השימוש ב-DHCP ברשתות מקומיות פתח צוהר להתקפות שונות כגון הונאת DHCP. טכניקה זו יכולה להיות חלק מלוחמת סייבר. כדי לבצע מעקב אחר השימוש ב-DHCP ולוודא שלא נעשה בו שימוש לרעה ניתן להפעיל על מתגי הרשת המקומית אפשרות הנקראת DHCP snooping.
אופן פעולת הפרוטוקול
[עריכת קוד מקור | עריכה]שלבי הפרוטוקול
[עריכת קוד מקור | עריכה]
להלן החבילות שנשלחות במהלך הפרוטוקול, בין הלקוח (המחשב המבקש כתובת) לבין שרת DHCP:
- הלקוח שולח חבילת discovery ב־broadcast לכל המחשבים ברשת המקומית על מנת לאתר שרת DHCP. בפאקטה זו אין המחשב מכניס כתובת IP של היעד, ועל כן היא תגיע אל המחשבים ב-LAN בלבד.
- אם קיימים שרתי DHCP ברשת המקומית בעלי כתובת פנויה לחלוקה, הלקוח יקבל חבילת offer עם כתובת IP מכל אחד מהם (בהנחה שאין חסימה של מעבר חבילות DHCP בין השרת ללקוח, למשל על ידי חומת אש).
- הלקוח שולח חבילת request עם הנתונים אותם בחר, גם כן בשידור broadcast - על מנת לעדכן את כל השרתים בכתובת שנבחרה; כך השרתים שהצעתם לא התקבלה יודעים שהם יכולים להקצות את הכתובת למחשב אחר, ויודעים את הכתובת שהמחשב קיבל (כדי שלא יקצו אותה למחשבים אחרים).
- השרת שולח acknowledge - אישור שהוא קיבל את הבקשה. לאחר בקשה זו המחשב מתחיל להשתמש בנתונים שקיבל. מעבר לכתובת שקיבל הלקוח, בחבילה זו נשלחים לרוב הפרטים המאפשרים למחשב להתנהל ברשת - כמו ה-subnet mask,שרת ה-DNS, שער הגישה ועוד (ראו בהמשך).
זמן הקצאה
[עריכת קוד מקור | עריכה]לשרת DHCP קיימת אפשרות להקצות כתובת עבור לקוח ברשת המקומית לזמן מוגבל - זהו זמן ההקצאה (lease time). אם השרת אכן פועל באופן זה, הוא שולח את זמן ההקצאה בפאקטת ה-acknowledge. על פי שיטה זו, למחשב אין כתובת IP קבועה, אלא הוא 'שוכר' כתובת מהשרת.
במקרה של השכרת כתובת, המחשב חייב לפנות אל השרת שוב, כדי לקבל את הכתובת לזמן נוסף, או לקבל כתובת חלופית. פנייה כזו תתבצע כתלות בזמן, וגם בעת עליית המחשב. במקרה הראשון, כאשר מגיע חצי מזמן ההקצאה, פונה המחשב בבקשה נוספת אל השרת, על מנת להאריך את זמן השכרת הכתובת. במקרה שהשרת לא עונה (למשל כי הוא נפל), יחכה המחשב עוד חצי מהזמן הנותר (כלומר שלושת-רבעי (3/4) הזמן מזמן ההקצאה הכולל) וינסה לפנות שוב. כך ימשיך המחשב עד שיענה לו השרת. אם השרת לא עונה לו, ינסה המחשב לפנות אל שרת אחר במטרה להאריך את זמן ההקצאה של הכתובת. אם גם תהליך זה כשל, יפנה המחשב בבקשה לכתובת חדשה.
למרות שמקובל לחשוב שכתובות DHCP הן "דינמיות", בפועל לאחר שהונפקה כתובת למערכת היא תשתנה במקרה שמתבצע שחרור כתובת (Release) והשרת מספק את הכתובת למחשב אחר לפני בקשת החידוש, או במקרה של זמן חיבור ארוך מהמותר על פי הגדרות ה-Lease time בשרת ה-DHCP, או במקרה של אי חיבור לרשת במשך זמן רב.
שחרור כתובת
[עריכת קוד מקור | עריכה]אפשרות נוספת בפרוטוקול היא השחרור (release), בו הלקוח שולח פאקטה ב-unicast אל השרת ממנו קיבל את הכתובת בבקשה לשחרר את הכתובת, ומוחק אותה אצלו. זהו לא חלק סטנדרטי מהפרוטוקול - בדרך כלל השאיפה של המשתמש היא לשמור על אותה הכתובת לאורך זמן ארוך ככל האפשר.
המשתמש יכול לבצע שחרור באופן עצמאי. מצב כזה קורה למשל כאשר המשתמש קיבל כתובת לזמן אינסופי אך הוא מתכוון לעזוב את הרשת המקומית, או לצורך טיפול בבעיית רשת כלשהי. כאשר המשתמש שולח בקשה לשחרור כתובת, אין הוא צריך לקבל תשובה על הצלחה/כישלון - שכן שחרור כתובות איננו חלק רשמי של הפרוטוקול, והלקוח "עושה טובה" לשרת שהוא משחרר את הכתובת.
גם כאשר המשתמש איננו משחרר כתובת באופן עצמאי, לשרת יש יכולת לדעת שכתובת מסוימת איננה בשימוש זמן רב, ולקחת אותה מהמשתמש הנוכחי. לדוגמה כאשר לשרת לא נותרו כתובות פנויות לחלוקה הוא יכול לבדוק מי הן הכתובות שלא ביצעו בקשה לחידוש הקצאה תקופה ארוכה, ולהעביר אחת מהן עבור הבקשה החדשה. יכולת זו משחררת את מנהל הרשת מהצורך לעדכן את השרת לגבי מערכות שיצאו משימוש.
אופן פעולת שרת DHCP
[עריכת קוד מקור | עריכה]חלוקת כתובות
[עריכת קוד מקור | עריכה]שרת DHCP יכול לעבוד באחד משלושה מצבים:
- הקצאה ידנית (manual allocation) – במצב הזה מנהל הרשת מנהל בשרת טבלה עם כתובות MAC של ממשקים של מכשירים ברשת, וה־IP שהוא רוצה להקצות עבור כל אחד מהממשקים.
- הקצאה אוטומטית (automatic allocation) – מנהל הרשת מגדיר לשרת ה־DHCP תחום כתובות וכל מכשיר ברשת יכול לבקש מהשרת את כתובת ה־IP מתוך התחום.
- הקצאה דינמית (dynamic allocation) – זהה להקצאה אוטומטית, פרט לכך שהכתובות מוקצות לזמן מוגבל (Lease Time). אם המחשב לא מבקש לחדש את הכתובת לאחר פרק הזמן שהוקצה, הכתובת תחזור למאגר כתובות ה־IP הזמינות על מנת שהשרת יוכל לתת אותה למחשב אחר שיבקש לקבל כתובת ברשת. מנגנון זה מאפשר הוספה והסרה של מחשבים שונים מהרשת בקלות יחסית.
בשרת DHCP ישנה אפשרות לעבוד בכל הדרכים לעיל בו זמנית - ניתן להגדיר כתובות לחלק מהמחשבים באופן ידני, והשאר באופן אוטומטי, עם או בלי הגבלת זמן.
תקשורת בין שרתי DHCP
[עריכת קוד מקור | עריכה]אף על פי שלכל רשת מקומית מספיק שרת DHCP אחד, לעיתים מנהל רשת יכלול מספר שרתי DHCP - בעיקר לצורך גיבוי, שכן אם שרת DHCP יחיד נופל הרשת לא תוכל להתנהל באופן סדיר לאורך זמן. במקרה כזה, עלולה להיווצר התנגשות - למשל כאשר לקוח יבצע שחרור כתובת מהשרת שהקצה לו אותה.
כדי למנוע בעיות כאלה, לפרוטוקול נוספו במקרים מסוימים אפשרויות של תקשורת בין השרתים לצורך סנכרון.
תחלופה ל-DHCP
[עריכת קוד מקור | עריכה]APIPA
[עריכת קוד מקור | עריכה]
ערך מורחב – APIPA
אם מחשב המבקש כתובת לא מקבל אותה לאחר זמן מסוים, הלקוח רשאי להקצות לעצמו כתובת מסוג APIPA - זוהי כתובת IP בטווח 169.254.0.1-169.254.254.254, אותה בוחר המחשב באופן אקראי. גם לאחר הקצאת הכתובת, ישאף המחשב לקבל כתובת חוקית ברשת משרת DHCP.
DHCP relaying
[עריכת קוד מקור | עריכה]מקרה נוסף בו לא יוכל מחשב ברשת מקומית לקבל כתובת הוא כאשר אין ברשת שרת DHCP - שכן הפנייה היא ב-broadcast ועל כן לא עוברת נתב. מקרה כזה עלול לקרות כאשר השרת המקומי נפל, או כאשר יש רצון להרים שרת אחד למספר רשתות מקומיות שונות - כדי לחסוך ברכיבי רשת.
כדי להתמודד עם מקרה זה ולאפשר למחשבים להשיג כתובת גם ללא פנייה ישירה אל שרת DHCP, מוגדרים רכיבים ברשת בתור 'סוכני DHCP' - הם יקבלו את תעבורת ה-DHCP שמגיע מלקוח ברשת, ויידעו להעביר אותה ישירות אל שרת DHCP מוגדר; רכיבים אלו ידעו גם לקבל חזרה את התעבורה ולהחזיר אותה אל הלקוח, כך שהם מהווים מעין שרת פרוקסי לתעבורת DHCP.
במקרה שבו שרת DHCP אחד מוקצה למספר רשתות מקומיות, עליו לדעת מאיזו רשת מגיעה אליו הבקשה, כדי להקצות כתובת בהתאם - מידע זה ייקבע על פי הכתובת של הסוכן, שתועבר בשדה בפאקטה הנקרא GIADDR.
ראו גם
[עריכת קוד מקור | עריכה]קישורים חיצוניים
[עריכת קוד מקור | עריכה]
הערות שוליים
[עריכת קוד מקור | עריכה]
| סיווג פרוטוקולים על פי מודל ה־OSI | ||
|---|---|---|
| שכבת היישום | HTTP • SMTP • FTP • RTP • IRC • SNMP • SIP • DNS • DHCP | |
| שכבת הייצוג | MIME • ASCII • Unicode • TLS | |
| שכבת השיחה | ASP • PPTP • SSH • NFS • RPC • SOCKS | |
| שכבת התעבורה | TCP • UDP • SCTP • DCCP | |
| שכבת הרשת | IP (IPv4 • IPv6) • ICMP • IPX • ניתוב | |
| שכבת הקו | אתרנט • Token ring • FDDI | |
| השכבה הפיזית | E1 • 10Base-T • RS-232 • DSL • SONET | |
| פרוטוקולים במודל TCP/IP | ||
|---|---|---|
| שכבת יישום | HTTP • SMTP • FTP • DNS • DHCP • SSH • RTP • RTSP • IRC • SNMP • SIP • IMAP4 • MIME • Telnet • RPC • SOAP • LDAP | |
| שכבת תעבורה | TCP • UDP • SCTP • DCCP | |
| שכבת רשת | IP • IPv4 • IPv6 • ICMP • IPX • IGMP | |
| שכבת קשר | אתרנט • 10BASE-T • 802.11 WiFi • Token ring • FDDI • ARP | |