פורט המקור של הלקוח מול המאזין בשרת בזרימת VPN
השוו את שני מספרי הפורטים במנהרה אחת: המאזין הקבוע של השרת והמקור הזמני של הלקוח, ואיך תרגום הנתב יושב ביניהם.
שני מספרים מופיעים באותה שיחה, ואף אחד מהם אינו שגוי. יומן השרת מציג את המאזין שמציע את השירות, המחשב הנייד מציג את הסוקט ששלח את הדאטגרם, ונתב בדרך עשוי לכתוב מחדש את השני ביציאה. השוואת קצוות השיחה שימושית יותר מהשוואת הספרות. ההשוואה שלמטה מחזיקה בנפרד את המאזין, את סוקט הלקוח ואת המקור המתורגם, מפני שהם עונים על שאלות שונות.
שני מספרים שמתארים קצוות מנוגדים
הפורט המוגדר של השרת הוא היעד שאליו הלקוח מחייג. הוא נקבע על ידי מדיניות, מופיע בפרופיל וחייב להיות פתוח בצד השרת. פורט המקור של הלקוח נבחר באופן מקומי, בדרך כלל מהטווח הזמני, והוא קיים כדי שלתגובה יהיה איפה לנחות. הוא עשוי להשתנות בכל התחברות מחדש, ושום דבר בתכנון לא תלוי בכך שיישאר יציב.
נתב בדרך עשוי לכתוב את המקור הזה מחדש במיפוי ה'NAT' שלו. לכן למספר שנצפה בשרת אין לעיתים קרובות שום קשר לזה שהמחשב הנייד בחר.
היכן מספר המקור משתנה בדרך החוצה
קחו דוגמת IPv4 מומצאת: לקוח מאחורי נתב שמתרגם, שרת עם מאזין 'UDP' אחד, ודאטגרם יחיד שחוצה את שניהם. הטבלה נוקבת בכל קצה ובמה שקורה לו, במקום להשמיע את החבילה מחדש בשלוש נקודות תצפית.
| Endpoint | What stays fixed | What changes on reconnect | Who owns it |
|---|---|---|---|
| Server listener | The service port and the address the profile names | Nothing; the listener does not follow the client | The server operator |
| Client socket | The destination it dials | The local source port, chosen per socket | The client, or its operating system |
| Translated source | Usually the public address of the router | The port, and sometimes the address after a network switch | The NAT device or the upstream carrier |
היעד קבוע בכל שורה, ורק זהות המקור משתנה. דרישות UDP NAT מבדילות בין כתובת ופורט פנימיים לבין המיפוי החיצוני, וזה בדיוק הפער בין השורה השנייה לשלישית. נתב רשאי לשמר את פורט המקור של הלקוח או לבחור אחר; שימור אינו משהו שיישום צריך להניח.
קראו את שלושת הקצוות מהמארחים עצמם
הרשימות שלמטה מגיעות משלוש מכונות שונות, ויחד הן מציגות את כל השיחה. הריצו את הראשונה בשרת, את השנייה בלקוח ואת השלישית בכל מקום שבו המיפוי קיים. שורת יומן אחת לא מציגה לעולם את כל השלוש.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194הרשימה הראשונה מוכיחה שהשרת קשור לפורט השירות ומראה איזה תהליך מחזיק בו. השנייה מציגה את הסוקט המקומי של הלקוח ואת היעד שאליו חייג. השלישית מציגה את המיפוי שהנתב יצר, וזהו המקום היחיד שבו מופיע המקור המתורגם. קראו אותן בסדר הזה והשני מספרים מפסיקים להיראות סותרים.
מה התחברות מחדש משנה, ומה לא
נתבים אחדים משמרים את פורט המקור של הלקוח כשהוא פנוי, ואחרים מקצים אחר בכל פעם. שתי ההתנהגויות נורמליות, ויישום שדורש את הראשונה יישבר בשנייה. שינוי מיפוי אחרי התחברות מחדש או החלפת רשת אינו תקלת שרת: הלקוח פותח סוקט חדש, הנתב מקצה את מה שיש לו, והשרת רואה מקור חדש על אותו מאזין. תקלה תהיה לצפות שהשרת יקבל תעבורה הממוענת לפורט לקוח שרירותי.
לקוחות OpenVPN של הקהילה מקבלים התנהגות זו דרך nobind, שמאפשר למערכת ההפעלה לבחור את הפורט המקומי; הפורט המרוחק עדיין מגיע מהפרופיל. קישור מפורש הוא בחירה מכוונת, לא דרישת פרוטוקול. השרת ממשיך להציע קצה אחד בעוד הלקוחות בוחרים זהויות מקומיות משלהם.
תייגו את השכבות בנפרד ברשומה
בתוך המנהרה מתנהלת שיחה שנייה עם פורטים משלה. בקשת HTTPS שנישאת על ידי המנהרה מיועדת ל-TCP 443, בעוד החיבור המוצפן החיצוני משתמש ב-UDP 1194, ולכן שינוי פורט המקור החיצוני אינו משנה דבר בשירות הפנימי.
אפילו בשכבה החיצונית הפרוטוקול חשוב. UDP 1194 ו-TCP 1194 הם קצוות שונים, ומאזין 'TCP' לעולם לא יקבל דאטגרם UDP רק מפני שהמספר תואם. כשמתעדים פריסה, תייגו את מאזין השרת, את סוקט הלקוח ואת המקור המתורגם כשלושה דברים נפרדים, והוסיפו לכל אחד את התעבורה.
ואז תנו למדיניות ללכת אחרי התפקידים. השרת פותח את התעבורה המיועדת במאזין שלו ועדיין מאמת את העמית; חומת האש של הלקוח מתירה תשובות לחילופי היציאה שלו בלי לפרסם שירות נכנס. מסנן חסר מצב זקוק לכיוון החזרה כתוב במפורש, וזו הסיבה המעשית לכך שההבחנה חשובה מעבר לתרשימים מסודרים.