תת־רשת במורד מול VPN שולחני: להחריג את התעבורה, לא את היישומים
עקיפה לפי יישום מסווגת רק פלט מקומי. ההתקנים שמאחורי תחנת העבודה זקוקים למדיניות כניסה, העברה ונתיב חזרה משלהם.
מכונה אחת, שתי משימות, חומת אש אחת: קישור Wi-Fi למעלה, תת־רשת Ethernet קטנה מאחוריו, ולקוח VPN שולחני שמניח שכל מה שיוצא מהמכונה הוא מקומי. יישומים שהופעלו מקומית יוצאים דרך נתיב הפלט המקומי. התקנים שמאחורי תחנת העבודה מגיעים ליציאת ה-Ethernet וזקוקים להחלטת העברה. החרגה שנכתבה עבור הנתיב הראשון לא רואה לעולם את השני, ולכן דפדפן עוקף את המנהרה בעוד ההתקנים לא.
שני נתיבי מנות, מדיניות אחת
| Origin | Path | Decision owner |
|---|---|---|
| Application on the workstation | OUTPUT then egress | The VPN app's routing policy |
| Device behind the workstation | PREROUTING then FORWARD | The workstation's own forwarding policy |
השורה הראשונה היא מה שרוב מדריכי split-tunneling מתארים. השנייה היא תצורת נתב שמתגוררת במקרה על אותה מכונה. מיזוגן למודל מנטלי אחד הוא הטעות; הן חולקות ליבה, אבל לא מדיניות. שרטטו את שני הנתיבים לפני עריכת כלל כלשהו, ושאר התכנון נובע מכך שאיזה נתיב חסר.
הטבלה גם מסבירה מדוע מכונה אחת יכולה לעבור מבחן אחד ולהיכשל באחר. דפדפן בתחנת העבודה מוכיח את הנתיב המקומי; מחשב נייד המחובר ליציאת ה-Ethernet מוכיח את נתיב ההעברה. אמתו כל שינוי בשניהם, אחרת השני יישאר לא נבדק לא משנה כמה פעמים ירענן הדפדפן.
מה החרגת יישום באמת מסווגת
החרגה לפי יישום פועלת בדרך כלל בכך שמסמנים מנות מתהליך או ממשתמש, ואז מנתבים תעבורה מסומנת אל מחוץ למנהרה. זהו מבנה של פלט מקומי. למנה מהתקן במורד אין תהליך מקומי, ולכן היא לעולם לא תתאים לבורר, יהא הבורר אשר יהא.
יהא הבורר אשר יהא, שתי הרשימות אינן אותה רשימה, וזה כל העניין. מדריך Mullvad ל-Linux מתאר סימונים שחומת האש ומדיניות הניתוב שלו צורכות, והדוגמאות שלו מכוונות לפלט מקומי; הן אינן תיאור נתמך של נתב במורד. העתקתן מניבה מכונה שחושבת שיש לה החרגה בעוד היא מעבירה הכול אל המנהרה.
כתבו את חוזה התעבורה
ציינו יחד את קידומת המקור במורד ואת ממשק הכניסה, ואז הגבילו את הקידומת בכניסה. בלי ההגבלה, כל התקן שמגיע ליציאה יכול לתבוע כתובת מוחרגת ולצאת דרך העקיפה. התייחסו לזה כשתי שאלות: האם מארחים אלה רשאים להשתמש בקישור הזה בכלל, והאם הם רשאים להגיע לתחנת העבודה או לטווחים הפרטיים של המנהרה? אלה הרשאות נוספות, לא תופעות לוואי של בחירת הקישור.
התירו העברה, ואז סננו אותה. שער ה-Linux זקוק להעברה מופעלת, לכללים שמתירים את התעבורה המיועדת בשני הכיוונים, ולמסלול חזרה כלפי מעלה או לתרגום מקור מוגבל במכוון. NAT לבדו אינו בוחר את הקישור ואינו מתיר מעבר דרך מסנן; הוא רק כותב מחדש כתובת אחרי ההחלטות האלה.
סיווג לתעבורה חייב להתרחש לפני החלטת מסלול ההעברה, כלומר בשלב prerouting ולא ב-output. כלל שיוצב אחרי ההחלטה עדיין יכול לשנות את המנה, אבל אינו יכול לשנות לאן כבר נשלחה.
סימונים שייכים ליישום שהם שלו
ערכי סימון, מספרי טבלאות וסדרי עדיפות של שרשראות הם חלק ממדיניות יישום ה-VPN, לא קבועים נצחיים. רשת עמידה שתלויה בהכנסת כלל לטבלה שתוכנית אחרת מייצרת מחדש תישבר בעדכון הבא, בדרך כלל בזמן התחברות מחדש ולא בעיתוי נוח.
הוספת שרשרת בסיס שנייה עם הכרעת accept לא בהכרח גוברת על drop של שרשרת מאוחרת. לשרשראות בסיס יש ווים וסדרי עדיפות, וההכרעה הראשונה בסדר מנצחת; accept בשרשרת אחת לא מבטל drop ששרשרת אחרת מגיעה אליו קודם. הסתכלו על מערך הכללים המלא ועל סדר מדיניות הניתוב, לא על המונה האחד שעלה. מונה מוכיח שכלל רץ, לעולם לא שההכרעה שלו היא שהוחלה.
שלבו, או העבירו את תת־הרשת
שתי התצורות נבדלות במי שמחזיק בעקיפה. תצורה משולבת שומרת על מכונה אחת ומדיניות אחת, במחיר תלות במחזור החיים של הטבלאות של יישום ה-VPN ובמערכת סימונים שהתיעוד שלו עשוי לשנות. נתב ייעודי לרשת שבמורד מסיר את התלות הזו לחלוטין: לתת־הרשת יש קישור משלה למעלה, ותחנת העבודה נשארת לקוח בלי תפקיד העברה.
בחרו בשנייה כאשר הרשת שבמורד חייבת להמשיך לעבוד דרך עדכוני VPN, או כאשר אין מי שיבדוק את המדיניות המשולבת אחרי כל מהדורה. בחרו בראשונה רק כאשר השילוב מתועד ומישהו אחראי לו.
אמתו את הגבול בארבעה מצבים: מחובר, מתחבר מחדש, חסום במכוון ועצור. בדקו פתרון שמות ושתי משפחות הכתובות בכל אחד מהם, כי עקיפה שמדליפה DNS אינה ההחרגה שתכננתם. המבחן צריך להוכיח את הגבול המדויק, לא רק שדף אחד נטען.