Chapter 09: Network Configuration - Asset A (Instructor Reference)¶
AGENT INSTRUCTION / SYSTEM NOTE: This document strictly follows the 4-part structural mandate for EVERY syllabus heading as requested. It represents the "Book-Book" theoretical depth for Instructor Reference. Content is in Hebrew, using exact English terms from the Glossary.
1. ממשקים וסדרי עדיפויות: ניהול מיקומי רשת (Network Locations) ו-Service Order¶
1. High-Level Theory & History¶
מערכת ההפעלה macOS מתוכננת לאפשר ניידות מרבית עבור משתמשים המדלגים בין סביבות עבודה שונות (בית, משרד, בתי קפה). כדי למנוע את הצורך בהגדרה ידנית מחדש של כתובות IP, שרתי DNS והגדרות Proxy בכל פעם, אפל פיתחה את מנגנון ה-Network Location (מיקום רשת). מיקומי רשת מאפשרים לשמור קבוצות של הגדרות רשת תחת פרופילים נפרדים (למשל "Office" לעומת "Automatic") ולדלג ביניהם בלחיצת כפתור. בנוסף, מנגנון ה-Service Order (סדר שירותים) קובע את סדר העדיפויות שבו המערכת תנסה לנתב את התעבורה כאשר מספר ממשקי רשת (כגון Wi-Fi, Ethernet וחיבור סלולרי) פעילים ומחוברים במקביל. המערכת תמיד תעביר תעבורה דרך הממשק שנמצא בראש הרשימה, אלא אם כן הוא נכשל או אינו מסוגל לנתב החוצה.
2. Deep Technical Architecture¶
הניהול המערכתי של ממשקי הרשת והתצורות השונות מבוצע על ידי תהליך הרקע (Background Process) המרכזי שנקרא configd (חלק מ-SystemConfiguration framework). תהליך זה מאזין לשינויים בסטטוס החיבור הפיזי (Link State) ומעדכן באופן דינמי את טבלת הניתוב (Routing Table) של הקרנל. כאשר מתבצע שינוי של Service Order, התהליך configd מעדכן את ה-Default Gateway בהתאם לממשק בעל העדיפות הגבוהה ביותר שיש לו חיבור חוקי (Link Up). המידע נשמר מבחינה היררכית במאגר SystemConfiguration, כך שאפליקציות שזקוקות לחיבור יכולות לשאול את ה-framework איזה ממשק רשת פעיל כעת מבלי לנהל את הניתוב בעצמן.
3. Terminal Commands, Plists & Logs¶
- Terminal Commands:
networksetup -listalllocations(הצגת כל מיקומי הרשת המוגדרים במערכת).networksetup -switchtolocation <LocationName>(החלפה מהירה בין מיקומי רשת).networksetup -listnetworkserviceorder(הדפסת סדר העדיפויות הנוכחי של ממשקי הרשת).netstat -rn(צפייה בטבלת הניתוב של הקרנל להבנת ניתוב ברירת המחדל).- Plists:
-
ההגדרות נשמרות בקובץ
preferences.plistהממוקם בנתיב:/Library/Preferences/SystemConfiguration/preferences.plist -
Logs:
log show --predicate 'process == "configd"' --info(מעקב אחר שינויים במצב הרשת והחלפות מיקומים כפי שמנוהלים על ידי ה-Daemon).
4. Edge Cases & Troubleshooting¶
מצב שכיח הוא שלמשתמש יש חיבור Wi-Fi תקין לרשת, אך אין לו גישה לאינטרנט. פעמים רבות הבעיה נעוצה ב-Service Order: ממשק וירטואלי (כמו תוכנת VPN ישנה או תחנת עגינה שאינה מחוברת לכבל) נמצא בראש הרשימה, ולמרות שהוא לא מספק אינטרנט, המערכת מנסה לנתב דרכו את התעבורה. הפתרון הוא כניסה ל-System Settings, גרירת ממשק ה-Wi-Fi לראש רשימת ה-Service Order, או שימוש בפקודת networksetup. במקרי קצה של שחיתות בקובץ ההגדרות, שבהם שינוי הגדרות IP לא נשמר, מומלץ ליצור Network Location חדש (היוצר סביבת SystemConfiguration נקייה לחלוטין מאפס) – מה שלרוב פותר את כל תקלות התצורה ללא צורך במחיקת קבצים ידנית.
2. כלי אבחון: Ping, Traceroute והיכרות עם פקודת העל networksetup¶
1. High-Level Theory & History¶
כדי לתמוך ולפתור תקלות רשת, אנשי IT חייבים להבין האם הבעיה היא מקומית (במחשב), בתשתית הראוטר, או בשרת היעד. לשם כך, ישנם כלי אבחון מסורתיים המגיעים מעולם ה-Unix. פקודת ping בודקת קישוריות בסיסית, בעוד traceroute מציגה את הנתיב המדויק שהמידע עובר דרך ראוטרים שונים בדרך ליעד. מעבר לכלים גלובליים אלו, אפל פיתחה את הפקודה הייעודית networksetup – זהו כלי ניהול עוצמתי לטרמינל ב-macOS שמהווה למעשה ממשק שורת פקודה (CLI) מקביל לחלוטין לכל מה שניתן לעשות דרך חלונית ה-Network ב-System Settings.
2. Deep Technical Architecture¶
הפקודה ping שולחת מנות ICMP Echo Request אל היעד וממתינה לתשובת ICMP Echo Reply ברמת הקרנל. traceroute עובדת על ידי שליחת מנות UDP עם ערך Time-To-Live (TTL) שהולך וגדל; כל ראוטר בדרך מפחית את ה-TTL, וכאשר הוא מגיע לאפס, הראוטר מחזיר הודעת ICMP Time Exceeded, וכך המערכת ממפה את כל "התחנות" בדרך. הפקודה networksetup ייחודית ל-macOS – בניגוד לשינוי ידני של קבצי טקסט בלינוקס, networksetup מתקשרת ישירות מול תהליך הרקע configd דרך XPC. כל שינוי באמצעות networksetup נרשם ומוחל מיד ב-SystemConfiguration framework, ולכן זו הדרך היחידה הנתמכת לבצע סקריפטים לשינוי רשת בארגון. פעולות תרגום שמות דומיין ל-IP (DNS) מתבצעות ומטומנות (Cached) על ידי תהליך הרקע mDNSResponder.
3. Terminal Commands, Plists & Logs¶
- Terminal Commands:
ping -c 4 www.apple.com(ביצוע 4 בדיקות פינג בלבד, ולא שליחה אינסופית כפי שנהוג ב-macOS כברירת מחדל).traceroute www.google.com(איתור נתיב הניתוב).networksetup -getinfo "Wi-Fi"(הצגת כל הגדרות ה-IP, ה-Subnet וה-Router של ממשק ה-Wi-Fi).sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder(מחיקת מטמון ה-DNS ואילוץ ה-Daemon לקרוא מחדש הגדרות).system_profiler SPNetworkDataType(הפקת דו"ח מלא של מצב הרשת והחומרה).- Plists:
- N/A (כלים אלו פועלים מול ה-Daemon בזיכרון או שהם כלי אבחון רשתיים בזמן אמת, אינם שומרים הגדרות בקבצי Plist עצמאיים).
- Logs:
log show --predicate 'process == "mDNSResponder"'(איתור שגיאות בשאילתות DNS).
4. Edge Cases & Troubleshooting¶
מקרה נפוץ הוא כאשר בדיקת ping לשרת נכשלת (Packet Loss 100%) למרות שיש גלישה תקינה והשרת למעשה פעיל. במקרים כאלו חשוב לזכור שרשתות מודרניות, נתבים או שרתים (וגם macOS עצמה אם פועל Stealth Mode) חוסמים פקודות ICMP מטעמי אבטחה, ולכן כישלון ב-ping אינו מעיד בהכרח על חוסר קישוריות לשירות עצמו (כמו שרת Web בפורט 443). בנוסף, תקלות רבות שבהן המשתמש לא מצליח לגשת לשרת מסוים למרות שכתובת ה-IP שלו השתנתה נובעות מזיכרון מטמון מיושן של DNS. הרצת פקודת ה-flushcache ושליחת סיגנל HUP ל-mDNSResponder מאלצת את המערכת למחוק את הזיכרון ולבצע שאילתת DNS חדשה ונקייה.
3. חומת האש: ה-Firewall המובנה של macOS וכיצד הוא פועל¶
1. High-Level Theory & History¶
באופן מסורתי, חומות אש מנוהלות לפי "פורטים" (Port-based Firewall), דבר שדורש מהמשתמש להבין אילו פורטים לפתוח (כמו פורט 80 ל-HTTP). אפל בחרה בגישה שונה וידידותית יותר למשתמש ב-macOS, והטמיעה Application Layer Firewall (ALF). ה-Firewall המובנה של מק לא שואל "האם לפתוח את פורט 22?", אלא "האם לאפשר לאפליקציה Zoom לקבל חיבורים נכנסים?". גישה זו קושרת את הרשאות התקשורת לחתימה הדיגיטלית של האפליקציה, ומאפשרת למערכת לנהל חסימות ואישורים באופן אוטומטי עבור תוכנות מוכרות, מבלי להציק למשתמש בהתראות טכניות.
2. Deep Technical Architecture¶
ה-Application Layer Firewall פועל תחת התהליך socketfilterfw. כאשר תוכנה מבקשת להאזין לתקשורת נכנסת (Listen to an incoming connection), מנגנון ה-ALF יבדוק את החתימה הדיגיטלית שלה (Code Signature). אם התוכנה חתומה כדין על ידי מפתח מורשה של אפל (והאפשרות "Automatically allow downloaded signed software to receive incoming connections" מסומנת), התהליך socketfilterfw יוסיף אותה לרשימת ההיתרים באופן שקט. אם החתימה שבורה או שהתוכנה לא חתומה, קופצת התראת TCC המבקשת אישור מהמשתמש (Admin). בנוסף, ה-Firewall כולל מצב "Stealth Mode", אשר מנחה את הקרנל להתעלם לחלוטין מבקשות סריקה כגון ICMP Echo Requests (פינגים) ובקשות TCP שאינן מורשות, מבלי להחזיר אפילו הודעת סירוב (RST) – כך שהמק נראה כ"בלתי נראה" ברשת. ראוי לציין שיש למק גם מנוע Packet Filter (pf) ברמת הקרנל עבור חוקים מתקדמים, אך ה-GUI שולט רק ב-ALF.
3. Terminal Commands, Plists & Logs¶
- Terminal Commands:
/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate(בדיקה האם ה-ALF מופעל)./usr/libexec/ApplicationFirewall/socketfilterfw --setstealthmode on(הפעלת מצב Stealth מהטרמינל)./usr/libexec/ApplicationFirewall/socketfilterfw --listapps(רשימת כל האפליקציות והרשאות ה-Firewall שלהן).- Plists:
-
תצורת ה-Firewall נשמרת בנתיב:
/Library/Preferences/com.apple.alf.plist -
Logs:
- פעולות וחסימות מתועדות בלוג הייעודי:
/var/log/appfirewall.log - או דרך ה-Unified Logging System:
log show --predicate 'subsystem == "com.apple.alf"'
4. Edge Cases & Troubleshooting¶
תקלה קלאסית מתרחשת כאשר מפתחים מעדכנים אפליקציה באופן לא תקני והחתימה הדיגיטלית שלה משתבשת (Code Signature invalidation). במקרה כזה, גם אם האפליקציה נמצאת ברשימת המורשים של ה-Firewall, המערכת תזהה שמדובר ב"מתחזה" ותחסום את התקשורת הנכנסת שלה, או שתקפיץ למשתמש בקשת אישור בכל פעם מחדש שהתוכנה נפתחת. במקרים אלו, מחיקת האפליקציה מרשימת ה-Firewall והוספתה מחדש לרוב לא תעזור עד שהחתימה תתוקן. במקרה של שחיתות כללית ברשימת ה-ALF שבה החוקים לא נאכפים, הפתרון הקיצוני הוא כיבוי ה-Firewall, מחיקת הקובץ com.apple.alf.plist, הפעלה מחדש של המק והדלקת ה-Firewall לקביעת תצורה נקייה.
4. תיבול ארגוני: אבחון פרופילי Wi-Fi מסוג 802.1X ארגוני וחיבורי VPN פרוקסי פרוסים מרחוק¶
1. High-Level Theory & History¶
בסביבה הארגונית (Enterprise), רשתות ה-Wi-Fi והגישה הפנימית מאובטחות בצורה מחמירה בהרבה מרשת ביתית של סיסמה אחת (WPA2 Personal). ארגונים משתמשים בפרוטוקול 802.1X (כגון PEAP או EAP-TLS) הדורש מכל מחשב להזדהות באמצעות שם משתמש וסיסמה אישיים, או באמצעות תעודה דיגיטלית (Certificate) המושתלת במחשב. כדי למנוע טעויות הקלדה ולפשט את התהליך, מנהלי IT אינם מצפים מהעובד להגדיר זאת ידנית, אלא משתמשים ב-MDM כדי לדחוף Configuration Profile המכיל Payload (Payload) עם הגדרות ה-Wi-Fi, התעודות הארגוניות, ואף הגדרות VPN ו-Proxy אוטומטיות לסינון תעבורה.
2. Deep Technical Architecture¶
תהליך ההזדהות הארגוני 802.1X מנוהל ב-macOS על ידי תהליך שנקרא eapolclient. התהליך מבצע משא ומתן (Handshake) מול הראוטר המקומי ומול שרת ה-RADIUS הארגוני. אם התהליך מוגדר ל-EAP-TLS (הזדהות מבוססת תעודה), ה-eapolclient חייב לגשת אל מערכת מחזיק המפתחות של macOS כדי לקרוא את ה-Identity Certificate הרלוונטי שהושתל על ידי ה-MDM. כאשר Configuration Profile מסוג Wi-Fi או VPN מופץ דרך MDM, ההגדרות ננעלות (Managed) במערכת. המשתמש מאבד את ההרשאה לשנות את ההגדרות הללו ואף כפתור "Forget This Network" מנוטרל או נעלם מהממשק הגרפי, כדי למנוע מהעובד לנתק עצמו משוגג מהרשת הארגונית המסופקת כפרופיל.
3. Terminal Commands, Plists & Logs¶
- Terminal Commands:
profiles list(הצגת כל פרופילי התצורה והפיילודים המותקנים המכתיבים מדיניות רשת).security find-identity -p macos -v(בדיקת התעודות הדיגיטליות החוקיות המותקנות ב-Keychain למטרות 802.1X).networksetup -setwebproxy "Wi-Fi" proxy.company.com 8080(דוגמה להגדרת פרוקסי ידנית אם נדרש עוקף אבחוני).- Plists:
- N/A (הגדרות רשת מנוהלות יושבות בתוך ה-MDM database ולא בקבצי plist סטנדרטיים של משתמש).
- Logs:
log show --predicate 'process == "eapolclient"' --debug(צפייה בזמן אמת בתהליך לחיצת היד הארגונית והבנת מדוע השרת דחה את החיבור).
4. Edge Cases & Troubleshooting¶
בעיה ארגונית שכיחה ביותר בהתחברות ל-802.1X מבוסס EAP-TLS היא תוקף תעודות. אם התעודה הדיגיטלית (Identity) פגת תוקף, תהליך ה-eapolclient ייכשל וה-Wi-Fi לא יתחבר, לרוב מבלי לספק שגיאה ברורה למשתמש. במקרים של PEAP (סיסמה ארגונית), בעיה נפוצה היא שהמשתמש משנה את סיסמת ה-Active Directory שלו בארגון, אך הסיסמה הישנה נשארת שמורה ב-Keychain עבור רשת ה-Wi-Fi, מה שגורם לנעילת החשבון שלו לאחר ניסיונות התחברות כושלים ברקע. כיוון שהפרופיל מנוהל על ידי MDM, טכנאי IT לא יכול למחוק את הרשת ידנית במק במקרה של תקלה חמורה. דרך המלך לפתרון היא שליחת פקודת מחיקת פרופיל מה-MDM, אילוץ עדכון פוליסות, ודחיפת Payload חדש ומעודכן, או מחיקת הסיסמאות הרלוונטיות דרך אפליקציית Keychain Access כדי לאלץ קפיצת חלון הקלדת סיסמה מחדש.