כוכב או רשת מלאה: איזו טופולוגיית VPN מתאימה לאתרים שלך

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

ספרו את יחסי העמיתים לפני כל דבר אחר

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

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

תנו לתערובת התעבורה להחליט, לא לשרטוט

אם תעבורת הסניפים היא בעיקר בקשות ל-ERP מרכזי או לאשכול קבצים, כוכב אינו פשרה, הוא הצורה הנכונה: התעבורה כבר רצתה להגיע לשם, ונקודת מדיניות אחת קלה יותר לביקורת מאשר רשת של כללים זוגיים. רשת מלאה מצדיקה את המורכבות שלה כשסניפים מחליפים ביניהם נתונים — שכפול בין שני משרדים, קול בין אתרים, שיתוף CAD שעשרה מהנדסים פותחים כל היום.

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

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

לכוכב צריך לומר להעביר הלאה

שתי מנהרות עובדות של סניף לכוכב אינן יוצרות גישה בין סניפים. הכוכב זקוק להעברת IP מופעלת, לנתיב לכל רשת סניף, לכלל חומת אש שמתיר את המעבר, ולמסלול חזור מחושב; כל סניף זקוק לנתיב לקידומות של האתר האחר. בכוכב Linux זה net.ipv4.ip_forward=1 בתוספת FORWARD שרשרת שאינה מפילה את הזוג בשקט, וב-IPsec מבוסס מדיניות אלה בוררי תעבורה שמפרטים את תת-הרשת של הסניף המרוחק בשני הקצוות. ב-strongSwan ההערות על העברה מכסות את צד הליבה וחומת האש כשזה השכבה שחסרה לכם. מבחן זול הוא לשלוח תעבורה מסניף אחד לשירות בסניף האחר תוך התבוננות במונים של הכוכב; כלל שלעולם לא עולה פירושו שהסדר שגוי, לא הנתיב.

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

שימו לב לגרסה החצי-גמורה: סניף A מנתב לסניף B דרך הכוכב, הכוכב מנתב לשני הכיוונים, וחומת האש של הכוכב מתירה חיבורים חדשים מ-A אבל לא מ-B. הכיוון הראשון נבדק היטב והשני נתקע, מה שנראה כמו תקלת ניתוב ואינו.

תכננו את הכשל, ואז את הנתיב הרגיל

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

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

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

בחרו לפי עלות שינוי, ואז אמתו את הנתיבים

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

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

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