פורט OpenVPN אחד, שלושה שירותים: למה פורטים פנימיים חשובים

הפעלת SSH אחת, אפליקציית ווב אחת ושאילתת שם אחת יכולות לחלוק חיבור VPN יחיד בלי לריב על פורטים. הלקוח בונה זרימה מוצפנת אחת אל השער, וכל שיחה של אפליקציה נוסעת בתוכה. מבחוץ נראים רק התעבורה והפורט של המנהרה עצמה. מבפנים כל שירות שומר על הפורט שלו ועדיין זקוק להרשאה שלו.

מה נושאת הזרימה החיצונית, ומה היא מסתירה

הלקוח עוטף כל מנה בתעבורת המנהרה לפני שהיא יוצאת מהמכונה. לזרימה חיצונית זו יש פורט יעד אחד, שנקבע כשהגדרנו את ה-VPN. בתוך העטיפה, כל מנה מקורית שומרת על הכתובת והפורט של השירות שאליו היא מכוונת. השער מסיר את העטיפה ומנתב לפי הכותרת הפנימית, כך שהיעד רואה לקוח רגיל שמגיע מהרשת.

לפיכך לכידה בממשק WAN מציגה שיחה אחת, לא שלוש. הפורטים הפנימיים מופיעים רק אחרי דה-קפסולציה. לכן פתח חומת אש אחד יכול לשאת SSH, HTTPS ו-DNS בעת ובעונה אחת.

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

תיעוד TUN/TAP מכסה את המסירה שבה התקן TUN מנותב מעביר מנות IP בין הגרעין לתהליך במרחב המשתמש. המסירה הזו היא מה שהופך את הכותרת הפנימית לגלויה לקוד הניתוב וחומת האש של השער. היא גם מסבירה למה הפורט החיצוני לא אומר דבר על אילו שירותים מותרים.

העברת NAT שייכת למאזין, לא לאפליקציות

שער באחסון עצמי מאחורי NAT של IPv4 זקוק לתרגום נכנס אחד: הכתובת והפורט הציבוריים ממופים למאזין ה-VPN. אין צורך בכלל עבור SSH, HTTPS או DNS רק משום שמשתמשי המנהרה מגיעים אליהם. פרסום הפורטים האלה היה חושף שירותים שהמנהרה כבר מגנה עליהם. כלל ההעברה מתאר את נגישות המאזין, לא הרשאה למשהו בפנים.

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

המדיניות הפנימית היא המקום שבו הגישה נקבעת בפועל

הצפנה מגנה על הנתיב; היא לא מאשרת יעד. מסלולי הלקוח בוחרים אילו קידומות נכנסות למנהרה, מדיניות ההעברה של השער מחליטה אם מנות רשאיות לצאת ממנה, וחומת האש של היעד יחד עם ההתחברות מחליטות אם השירות עונה. DNS הוא המקרה הברור ביותר: נשיאת שאילתות לא גורמת לרזולבר לקבל אותן ממאגר הלקוחות שלך. כל שכבה יכולה לומר לא באופן עצמאי.

בדקו כל שירות בנפרד דרך המנהרה. חיפוש מוצלח לא אומר דבר על פורט הווב, ובקשה מוצלחת לווב לא אומרת דבר על SSH.

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

כשהמנהרה פעילה והכול נכשל, קראו קודם את טבלת הניתוב של הלקוח. כששירות אחד נכשל והאחרים עובדים, התקלה נמצאת ביעד הזה. שתי התצפיות האלה מצביעות על אחראים שונים, וערבוב ביניהן מבזבז זמן.

WireGuard משרטט את אותו קו

WireGuard נותן למאזין החיצוני שלו את השם ListenPort, ואפליקציה פנימית עדיין משתמשת בכל פורט שירות שהיא צריכה. AllowedIPs הוא קבוצה של קידומות מנותבות, לא רשימה של פורטי שירות מותרים. קריאה שלו כרשימת הרשאות לפורטים מייצרת כללים שלא תואמים את מה שהמנהרה עושה. השמות שונים; השכבות לא.

אפשרו את השירות במדיניות קלט מקומית כשהוא רץ על נקודת הקצה עצמה, או במדיניות העברה כשהוא יושב מאחורי נקודת הקצה הזו. ההבחנה קובעת איזו קבוצת כללים רואה את המנה.

הצורה הכללית היא תעבורה חיצונית אחת עם שיחות פנימיות רבות. מוצרים שזקוקים לכמה חילופים חיצוניים, או לפרוטוקול IP אחר, מזכירים שתבנית הפורט הציבורי האחד מתארת את העיצוב הזה ולא כל VPN.