VPN בניתוב או בגישור: בחרו לפי מה שהלקוח חייב להגיע אליו

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

שתי בקשות שנראות זהות בדלפק

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

אלה שאלות שונות, ומענה לשתיהן בגשר מרחיב את גישת העובד לכל ה-LAN של המשרד בלי סיבה.

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

מסלול צר יותר מחברות ב-LAN

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

אל תבלבלו מסלול עם הרשאה. אמירה ללקוח איך להגיע לתת-רשת אינה מונעת ממנו לנסות יעד אחר.

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

גשר משנה את שאלת הקבלה

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

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

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

סינון קיים בשתי הטופולוגיות

גשר אינו בלתי-ניתן-לסינון מטבעו, ומסלול אינו בטוח מטבעו. לסינון גשרים ב-Linux יש ווים משלו ותחביר כללים משלו, וכלל שנכתב להעברת IP בניתוב אינו חל אוטומטית על מסגרות בגישור.

בדקו מה הפלטפורמה באמת תומכת בו לפני שמבטיחים גבול:

bridge link show
nft list ruleset

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

הוכיחו את הגבול בשלושה ניסיונות

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

הריצו את הנתיב המותר והנתיב הנדחה מאותו לקוח, ותעדו את שניהם:

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

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