VPN מאתר לאתר מבוסס נתיב לעומת מבוסס מדיניות: מה שונה
IPsec מבוסס מדיניות בוחר תעבורה באמצעות בורר; מבוסס נתיב שולח אותה דרך ממשק מנהרה. שניהם עדיין זקוקים לכללי חומת אש ולנתיב תגובה.
שני התכנונים מגינים על אותה תעבורה באותה מכונת IPsec, והם נבדלים במה שמחליט איזו חבילה נכנסת למנהרה. בחיבור מבוסס מדיניות עושים את העבודה הזאת בוררי התעבורה שנקבעו במשא ומתן; בחיבור מבוסס נתיב עושה אותה נתיב שמצביע על ממשק מנהרה. ערבוב בין השניים מייצר את שרשור התמיכה המוכר שבו המנהרה מדווחת שהיא מוקמת בעוד היישום לא מגיע לשום דבר. ההבחנה חשובה ביותר כשמוסיפים רשת, מריצים פרוטוקול ניתוב או מאתרים תקלה בנתיב שיוצא בשקט דרך היציאה הלא נכונה.
שתי דרכים להחליט מה נכנס למנהרה
VPN מבוסס מדיניות בונה מדיניות אבטחה שמתאימה קידומות מקור ויעד, ואז מצפין כל מה שמתאים. הצד השני חייב לנהל משא ומתן על בוררים תואמים, ולכן ההיקף האפקטיבי נגמר כחיתוך של מה ששני הצדדים הציעו. שום דבר מחוץ לחיתוך הזה אינו מוגן, יהיה אשר יאמר טבלת הניתוב.
VPN מבוסס נתיב יוצר ממשק שמייצג את המנהרה ומאפשר לטבלת הניתוב לשלוח אליו תעבורה. דמון IKE עדיין מתקין את המצב ואת המדיניות לכל ממשק, וזה בדיוק הפרט שמדלגים עליו כשמחליטים שהנתיבים החליפו את ההצפנה. שני התכנונים מצפינים ב-IPsec; רק מנגנון הבחירה שונה.
קראו את ההשוואה שלהלן כמערכת של חתימות כשל ולא כלוח תוצאות, מפני שאף עמודה אינה מנצחת כשלעצמה.
| Aspect | Policy-based | Route-based |
|---|---|---|
| What selects traffic | Negotiated selectors | A route into the tunnel interface |
| Adding a network | Edit selectors on both peers | Add a route, widen the selector once |
| Dynamic routing | Awkward to run over the tunnel | Runs over the interface directly |
| Typical failure | Tunnel up, host outside the selector | Tunnel up, no route or wrong source |
מבוסס מדיניות: הבורר הוא החוזה
על הבוררים מנהלים משא ומתן, לא רק מגדירים אותם. הציעו 10.10.0.0/16 בצד אחד ו-10.10.1.0/24 בצד השני, והשיוך יכסה את מה שהמשא ומתן קבע בעוד כל מארח אחר נשאר בחוץ.
קראו את המצב המותקן ולא את קובץ התצורה. אצל עמית Linux הטבלאות של הגרעין עצמו הן האמת הבסיסית, והן מראות מה שרד את המשא ומתן. מדיניות שמפרטת את הקידומות הנכונות בלי מצב מתאים פירושה שהשיוך מעולם לא עלה. מצב שמלווה במדיניות לקידומת הלא נכונה הוא הבעיה ההפוכה, והוא מייצר את המנהרה שנראית בריאה בעוד תת-רשת אחת לא מגיעה לשום דבר.
sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sasהשוו את שני הפלטים לקידומות שאתם חושבים שאתם מגינים עליהן. ההשוואה האחת הזאת פותרת את רוב הדיווחים על מנהרה עובדת עם שרת בלתי נגיש. היא גם מצביעה על הצד שצריך לשנות, מפני שהפער נראה בדרך כלל בכיוון אחד בלבד.
מבוסס נתיב: הממשק הוא החוזה
ממשק XFRM נותן למנהרה שם וזהות, והתעבורה מגיעה אליו מפני שטבלת הניתוב אומרת כך. כמה קידומות מרוחקות הופכות אז לבעיית ניתוב ולא לבעיית בורר, ופרוטוקול ניתוב יכול לפרסם אותן. זה הרווח האמיתי, לא ההצפנה.
הממשק אינו מבטל את הצורך במדיניות. הדמון מתקין כללים לכל ממשק הקשורים לזהות הממשק, כך שחבילה שמגיעה לממשק הלא נכון עדיין נכשלת. גם כתובת מקור שהצד השני לא יקבל נכשלת, אפילו עם נתיב מושלם. מבוסס נתיב פירושו שהנתיב מחליט על הכניסה, לא שהמדיניות נעלמה.
sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10עקבו אחרי מוני הממשק לאחר שהנתיב במקום. נתיב שקיים בעוד המונים נשארים באפס פירושו ששום דבר לא מותאם אל תוך המנהרה, מה שמצביע בדרך כלל על מצב חסר ולא על נתיב חסר.
היכן שני התכנונים באמת נפרדים
הוספת רשת היא המבחן הנקי ביותר לאיזו מודל מתאים לכם. תכנון מבוסס נתיב מוסיף נתיב ומרחיב את הבורר לכל היותר פעם אחת, בעוד תכנון מבוסס מדיניות עורך זוגות קידומות בשני הצדדים ומנהל משא ומתן מחדש. שתי תת-רשתות יציבות הופכות את העריכה הזאת לזניחה, ועשרים הופכות אותה לפרויקט.
אף מודל אינו מחליף חומת אש, וההשוואות בדרך כלל נעצרות לפני הנקודה הזאת. בורר רחב או נתיב רחב מחליטים מה מוצפן, לא מה מותר.
התנהגות MTU שונה גם היא בפועל. הכמסה מקטינה את המטען השימושי, וממשק מבוסס נתיב נושא MTU משלו, ולכן הידוק MSS בשני השערים מונע את תסמין החור השחור שבו תגובות קטנות מגיעות וגדולות נעלמות. מנהרות מבוססות מדיניות פוגשות את אותה קיר מהצד השני, מפני שבורר לא אומר דבר על גודל החבילה. קבעו את ההידוק במכוון במקום להאשים את הצד השני.
הגירה בלי לאבד את נתיב החזרה
תעדו את זוגות הקידומות הקיימים לפני שמשנים משהו, ואז העבירו נתיב יישום אחד וצפו בו מקצה לקצה. מנהרה שמתקשרת אינה מנהרה שמעבירה, וההבדל מופיע בכיוון התגובה.
כשהצדדים מתחברים אבל מארחי ה-LAN לא, בדקו את נתיב התגובה ואת כתובת המקור שהמארח המרוחק ישתמש בה. מארח עם שני ממשקים עשוי להשיב מהממשק הלא נכון, ושום שינוי בורר לא מתקן זאת. לכדו תעבורה בשני הקצוות לפני עריכת אלגוריתמים.
ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-connsהשאירו נתיב ניהול שאינו תלוי במנהרה בזמן העבודה. חזרה לאחור קלה יותר כשהגישה של השער עצמו אינה רוכבת על החיבור שאתם מאתרים.