VPN מנותב או LAN מגושר לקישור בין סניף למעבדה

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

שתי דרכים להתחבר, פשרה אחת ברורה

קישור מנותב מתייחס למעבדה הביתית כרשת מרוחקת עם מיעון משלה. הסניף מבקש את הקידומת של המעבדה, המנהרה מעבירה את החבילות האלה, ושער המעבדה עונה מתת-הרשת שלו. דבר בטבלת ה-ARP של הסניף לא משתנה, ושום דבר מטווח ה-DHCP של המעבדה לא מגיע לסניף.

קישור מגושר מותח תחום שכבה 2 אחד על שני האתרים. פרוטוקולי גילוי עובדים, התקנים מופיעים אוטומטית, וכל שידור, כל בקשת ARP וכל חבילת multicast הוא כעת מועמד לחצות את המנהרה, כלומר כמות גדולה של תעבורה שנישאת על ידי פרוטוקולים שנבנו לסגמנט מקומי ולא ל-WAN עם MTU אחר וזמן הליכה-חזרה משתנה.

מה נותן הניתוב

היתרון הראשון הוא רדיוס הנזק. לולאה, שרת DHCP לא רצוי או הצפת שידורים נשארים באתר שיצר אותם, כי נתב אינו מעביר שידורים. השני הוא בהירות המיעון: קידומת הסניף וקידומת המעבדה נפרדות, ולכן יעד של חבילה אומר לכם איזה אתר צריך לענות, וכלל חומת אש יכול לומר „מסניף לתת-הרשת של המעבדה“ במקום „מכל מקום לכל מקום“.

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

sysctl -w net.ipv4.ip_forward=1
ip route add 10.20.0.0/24 via 192.168.50.1
ip route get 10.20.0.40

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

מה עולה גישור

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

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

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

שמות בלי שידור

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

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

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

הפכו את התכנון המנותב לבדיק

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

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

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