נעילת VPN באמצעות PF ב-Mac: מדיניות אתר, לא תכונה להפצה
Packet Filter אינו API נתמך למוצרים מופצים. תנו לסט החוקים בעלים, תנו שם לכל חריגה ובדקו את המעברים.
זה עובד ב-Mac שלכם, ולכן זה נראה כמו משהו שאפשר למסור למשתמשים. ההנחה הזו היא הדבר הראשון שצריך לאבד. המסמך TN3165 של אפל קובע בבירור ש-Packet Filter אינו API נתמך למוצרים מופצים באופן כללי, והוא מציג ניהול אתר מורשה ומבוקר כמקרה הסביר. לכן נעילת VPN הבנויה על PF היא מדיניות תפעולית מקומית עם בעלים, לא תכונה שאפשר להפיץ בתוך אפליקציה.
PF אינו משטח אריזה
ההבחנה אינה אקדמית. מוצר מופץ שתלוי ב-PF יורש כל שינוי שאפל עושה בו, כל התנגשות עם כלי אחר שגם כותב חוקים, ואין שום התחייבות תמיכה שהסדר ימשיך לעבוד. אתר שמנהל את המכונות שלו נמצא ביחס אחר: הוא יכול לתעד את התלות, לבדוק אותה מול כל גרסת מערכת הפעלה ולקבל על עצמו את התחזוקה.
כמה עצות התקנה חוצות קו שראוי לתת לו שם. דריסת כל סט חוקי המערכת כדי שעוגן אחד ייטען, עריכת תצורת האתחול של המערכת של אפל, או השבתת System Integrity Protection אינן דרישות מקובלות למתכון לשימוש חוזר. אם מדריך שפורסם זקוק לאחד מאלה, הוא מתאר מעבדה, לא מדיניות שאפשר לפרוס.
כתבו את כוונת היציאה לפני התחביר
החליטו מה מותר לפני שתבחרו מילת מפתח אחת. בדרך כלל צריכים להתקיים שלושה נתיבים: התעבורה של לקוח ה-VPN עצמו לשרת שלו, תעבורת האפליקציה המוגנת בתוך המנהרה, וכל מה שההתקנה או שירותים מקומיים באמת דורשים כנתיב ישיר.
תנו לכל חריגה מוצעת יעד, אמצעי תעבורה ובעלים. לאפשר את כל הפורטים ליעד אחד מאפשר הרבה יותר מאשר אמצעי התעבורה היחיד שהמנהרה משתמשת בו, והחשיפה הנוספת מגיעה בלי שמישהו החליט שהיא צריכה להיות. לאפשר resolver ציבורי הוא אותה מלכודת בתחפושת ידידותית יותר: הוא יוצר נתיב DNS ישיר גם כשהמנהרה למטה, ולכן חיפושי שמות עדיין דולפים.
| Path | Destination | Owner |
|---|---|---|
| VPN transport | Gateway address, one UDP port | Network team |
| Tunnel traffic | Internal prefixes | Application owner |
| Resolver exception | Named internal resolver | Security team |
המבחן השימושי לחריגה הוא אם אתם יכולים לנקוב בשם האדם שביקש אותה ובכשל שהיא מונעת. אם אף אחת מהתשובות אינה קיימת, החוק הוא כנראה מעקף לתצורה שגויה שאחרת הייתה נשארת בלתי נראית.
מספרי utun אינם זהות
MacOS יוצר ממשקי מנהרה כהתקני utun, ו המספר שמוקצה ל-VPN שלכם אינו יציב בין אתחולים, התחברויות מחדש או נוכחות של לקוח אחר. חוק שמפרט כמה מספרים משוערים אינו מדיניות; הוא צילום של אחר צהריים אחד.
עגנו את החוק במשהו שמזהה את הספק המיועד: תוכנית הכתובות שהמנהרה מקצה, התהליך שמחזיק בממשק, או תצורה שלקוח ה-VPN עצמו מתחזק. לאחר מכן תיעדו כיצד הזיהוי הזה עובד, כי למי שיבדוק את החוק בעוד שנה לא תהיה היסטוריית ה-shell שלכם.
הפכו את המדיניות הטעונה למיוחסת
שם עוגן מארגן חוקים; הוא אינו מוכיח שהמדיניות האפקטיבית היא מה שהתכוונתם. קדימות בין עוגנים, חוקים שתוכנה אחרת טענה, והמצב הקיים יכולים כולם לשנות את התוצאה. עברו על הסט האפקטיבי עם כל מי שעוד מחזיק ב-PF באותה מכונה, ותעדו את הבעלות באותו מקום שבו נמצאת התצורה. שני בעלים שעורכים עוגנים שונים בהנחות שונות הם הדרך הרגילה שבה נעילה מפתחת חור.
החזיקו את סט החוקים בנתיב התצורה הנתמך של האתר, נהלו לו גרסאות, וציינו אילו גרסאות macOS נבדקו. שינוי שמיושם ביד וזוכר אותו אדם אחד אינו תשתית מתוחזקת, יהיה מה שיהיה בכותרת הקובץ.
בדקו את המעברים, לא את המצב המחובר
צילום מסך שנעשה כשהמנהרה למעלה כמעט אינו מוכיח דבר. עברו במקום זאת על המצבים: אתחול לפני כל חיבור, מנהרה עובדת, מנהרה שנופלת בלי אזהרה, ניתוק מכוון, ומעבר מ-Wi-Fi לנקודת גישה. לכל מצב יש תשובה משלו, והמעניינים הם הכשלים ולא המסלול המאושר.
בכל מצב, תעדו מה נגיש בכוונה. בדקו IPv4 ו-IPv6 בנפרד, בדקו פתרון שמות, וכללו זרימה שכבר הייתה מבוססת לפני המעבר, כי חיבורים קיימים לא תמיד הולכים אחרי המדיניות החדשה. דפדפן שנכשל כשהמנהרה למטה הוא נקודת נתונים אחת, לא הוכחה שכל נתיב אחר חסום.
לבסוף, החזיקו שיטת שחזור שאינה תלויה בנתיב הרשת שאתם משנים. תצורה מוכרת-כטובה באחסון מקומי ודרך מתועדת לטעון אותה הופכות נעילה למדיניות; בלעדיהן, עדכון גרוע אחד נועל את המנהל מחוץ למכונה שאמורה הייתה להיות מוגנת.