כללי VPN בנתב: התאימו בין המקור ליעד
לכלל VPN בנתב יש שני קצוות: ההתקן ששולח תעבורה והיעד שאמור להשתמש במנהרה. החליטו קודם על החיתוך ועל התנהגות הגיבוי.
דפי קנייה של נתבים מציגים ניתוב VPN כמשבצת סימון אחת, והביטוי הזה מסתיר שלוש שאלות שונות. האם הכלל מתאים להתקן ששולח את התעבורה, לשרת שמקבל אותה, או לשניהם? מה קורה לתעבורה שלא מתאימה לאף אחד מהם? וכששני כללים חופפים, מי מנצח? כתיבת התשובה כזוג של מקור ויעד הופכת רשימת תכונות מעורפלת לתכנון שאפשר לבדוק.
שם התכונה מסתיר שני קצוות
נגן מדיה שאמור להשתמש במנהרה הוא התאמת מקור. קידומת משרד פרטית שאמורה להיות נגישה דרך המנהרה היא התאמת יעד. תחנת עבודה שאמורה להשתמש במנהרה רק לשירות אחד היא שניהם, והחיתוך הזה הוא המקרה שרוב הקושחה הצרכנית מטפלת בו רע.
כתבו את הדרישה כזוג לפני השוואת מוצרים. הזוג הזה הוא מה שתבדקו בהמשך.
מוצר שמציע רשימת התקנים או רשימת יעדים גלובלית אולי לא יכול לבטא «רק ההתקן הזה, רק היעדים האלה». הפער אינו קוסמטי: כלל יעד גלובלי שולח את התעבורה של כל התקן לאתר הזה דרך המנהרה, וכלל התקן שולח את כל התעבורה של אותו התקן. אף אחד מהם אינו הדרישה. בדקו את המקרה הזה עם שני התקנים לפני שתסמכו על המסך.
בנו את הכלל כחיתוך
טבלה שומרת על התכנון ישר. שימו את התרחיש משמאל, ואז תנו שם בנפרד להתאמת השולח ולהתאמת היעד:
| Scenario | Sender match | Target match | Rule shape |
|---|---|---|---|
| Media player uses the tunnel | Player address | Any internet destination except the LAN | Source only |
| Office prefix reachable | Authorized LAN devices | 10.40.0.0/16 | Target only |
| One app on one laptop | Laptop address | The service address set | Source and target |
| Guest network never tunnels | Guest subnet | Any | Deny, evaluated first |
השורה השלישית היא המעניינת, כי היא צריכה את שני החצאים בבת אחת. אם הקושחה יכולה לבטא רק ציר אחד, יש לפצל את הדרישה לשני כללים או להעביר אותה להתקן שמסוגל לכך.
שמרו על יציבות זהות המקור. הזמנת DHCP, מקטע ייעודי או מנגנון זהות התקן כולם עובדים, אבל כתובת שמשתנה לאחר שהחכירה פגה אינה עובדת. כללו IPv6, כי כתובת IPv4 אחת אינה מזהה את כל התעבורה של התקן.
העדיפות מכריעה את החפיפה
חפיפה בין כללים היא נורמלית. כלל התקן רחב וכלל יעד צר יכולים לתאר זרימה אחת, וסדר העדיפות המתועד מכריע מי מנצח. מסך הגדרות מושך אינו מספר לכם את הסדר הזה.
קראו במדריך על הסדר ועל המקרה בלי התאמה, ואז בדקו את שניהם בתעבורה שאפשר לראות:
ip rule show
ip route get 203.0.113.10אם התיעוד אינו מציין את הסדר, הניחו שהכלל הצר יותר אולי לא ינצח ותכננו בהתאם. שני כללים שאינם יכולים להתנגש קלים יותר לתמיכה מכלל חכם אחד שקדימותו אינה מתועדת.
שמות צריכים מדיניות רענון
יעד שנכתב כדומיין מוסיף בעיית תחזוקה. הנתב צריך לפתור אותו, לרענן את המיפוי, לטפל במספר כתובות ובדומיינים משנה ולהתמודד עם DNS של יישומים שעוקף את הפותר הצפוי.
העתקת תוצאת חיפוש אחת לכלל IP היא תצלום רגע, לא מדיניות דומיין.
החליטו עד כמה תשובה יכולה להיות ישנה לפני שהכלל שגוי, ומה הנתב עושה כשהפתרון נכשל. כלל ששומר את הכתובת הידועה האחרונה יכול לשרוד הגירת שירות; כלל שמשליך את הרשומה יכול לעצור את המינהור בשקט. כל אחת מההתנהגויות מקובלת אם היא כתובה לצד הכלל.
הגדירו את מצב אי-הזמינות
העדפת מסלול אינה כופה תעבורה דרך VPN בלבד. כשהמנהרה למטה, הנתב יכול לחסום את הזרימה, לשלוח אותה ישירות או להשתמש במנהרה אחרת, ולכל בחירה חתימת כשל אחרת.
החליטו איזו מהן הדרישה צריכה, ואז אמתו זאת על ידי עצירת המנהרה וצפייה בזרימה:
curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10תעבורה שמקורה בנתב עצמו היא תחום נפרד. העברת DNS, בדיקות עדכון וניטור יכולים להתחיל זרימות חדשות מהנתב עצמו במקום לרשת את התאמת המקור של ההתקן. חשבו על הזרימות האלה במפורש, אחרת הן יופיעו כדליפות לא מוסברות ביומנים.