The Life of a Packet: From Application to Routing

מאת שי מרדכי | 18 בדצמבר 2025

כשמנסים לגשת לאתר (למשל פאלו אלטו) מהטרמינל בלינוקס, קל לחשוב על התהליך כמושג אבסטרקטי. בתור מי שרגיל יותר למודל 5 השכבות מאשר ל-OSI הקלאסי, החלטתי לפרק את ה-Flow שעוברת חבילת מידע ברשת, ולשאול את השאלות הארכיטקטוניות שעולות בדרך.

שכבת האפליקציה והתעבורה: חלוקת תפקידים

הכל מתחיל בשכבת האפליקציה, שם פועל פרוטוקול HTTP על גבי TLS שמצפין את השיחה. אבל לפני שבכלל נוצר חיבור, אנחנו חייבים לתרגם את ה-Domain לכתובת IP, כדי שהלקוח יוכל להתחבר בסוקט מול השרת. כאן נכנס ה-DNS.

ה-DNS משתמש בפרוטוקול UDP, מכיוון שאין צורך לשמור את מצב השיחה – מדובר בבקשה ותשובה חד-פעמיות. לעומתו, HTTP חייב להשתמש ב-TCP כדי לשמור על השיחה פתוחה, לעקוב אחריה, ולדאוג לשלמות הנתונים לאורך זמן.

Encapsulation: איך עוטפים חבילה?

בהתחלה זה בלבל אותי, כי היה נשמע שיש תהליך שונה בין חבילה שיוצאת מאפליקציה בקונטיינר (כמו Docker) לבין חבילה שיוצאת מאפליקציה רגילה ב-Host. אבל בסוף, העטיפה עובדת כמו בבושקה:

1. קודם כל, תוכן ההודעה (HTTP) נעטף ב-Headers של TLS בשכבה 6.
2. אח"כ זה נעטף בפורט מקור ויעד (TCP) - שכבה 4.
3. לאחר מכן בכתובות IP מקור ויעד - שכבה 3.
4. ובסוף, השכבה החיצונית ביותר (שכבה 2), עוטפת את החבילה בכתובת ה-MAC של המקור, וכתובת ה-MAC של הראוטר המקומי (אותה השגנו באמצעות פרוטוקול ARP).

כשהחבילה מגיעה לשרת היעד, התהליך הפוך: השרת מקבל את החבילה ומתחיל לפתוח ולבדוק בכל שכבה האם החבילה מיועדת אליו, עד שהוא רואה את תוכן ההודעה.

ניתוב (Routing) ו-NAT/PAT

תפקיד ה-IP הוא אכן לתקשר עם השרת, אבל איך מתבצע ה-Routing בפועל? כתובת ה-IP של הלקוח נרשמת ב-Socket, אבל כשהיא עוברת מהמחשב לראוטר המקומי, הראוטר מבצע NAT. הוא מחליף את ה-IP הפנימי לכתובת החיצונית של הראוטר.

כאן עלתה לי שאלה לגבי ניהול הפורטים: כשהראוטר מוציא חבילה החוצה, הוא לא רק משנה IP, הוא גם משתמש ב-PAT כדי לתרגם את פורט המקור של המחשב, לפורט המקור של עצמו. כך הם עובדים ביחד כשהחבילה יוצאת ל-Default Gateway.

לאורך הדרך באינטרנט, הראוטרים פותחים את השכבה השנייה ומחליפים את כתובות ה-MAC של הראוטר הבא (שוב באמצעות ARP), עד שהחבילה מגיעה לנתב ה-ISP ומשם ליעד. (אגב ניתוב, למדתי בתואר על אלגוריתם דייקסטרה, אבל בפועל פרוטוקולים כמו BGP מזכירים יותר אלגוריתמים דמויי A* או Waze שמחפשים את הנתיב הכדאי ביותר, ולאו דווקא הקצר ביותר).

וקטור תקיפה: ARP Spoofing ברשת מבודדת

נושא שחקרתי לאחרונה הוא מה קורה כשמחשב שולח חבילה ל-Default Gateway שלו (בחיבור WiFi למשל). לא נפתח שם Socket אמיתי של IP ופורטים לתקשורת ה-WiFi עצמה, אלא כרטיס הרשת מעביר ב-MAC Sublayer את החבילה לראוטר, וההצפנה (כמו WPA2/3) מנוהלת בשכבה הזו.

אבל מה קורה כשחבילה יוצאת מ-Namespace של קונטיינר ל-Bridge של הלינוקס? אם תוקף מצליח להשתלט על הקונטיינר, הוא יכול לנסות לבצע ARP Spoofing ברשת הפנימית (SDN).
התוקף מנסה לשלוח הודעת ARP מזויפת שאומרת "אני הראוטר". המטרה שלו היא לגרום למחשב או לקונטיינר להשתכנע, לעדכן את טבלת הניתוב, וכך ליירט את התקשורת בתוך ה-LAN. מה המנגנון שמונע מהמחשב להשתכנע ל-ARP Spoofing? זה אזור שדורש העמקה במנגנוני אבטחה של שכבה 2.

שאלת מחקר: הראוטר הווירטואלי

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