VPN ארגוני בתוך WireGuard: איזה שכבה באה קודם?

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

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

השוו בין שני הסדרים האפשריים

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

הלקוח הרשמי של WireGuard מחיל קובץ תצורה מלא, כולל נתיבים ו-DNS. לקוחות ארגוניים מסחריים מסתירים בדרך כלל את שניהם. הצבת לקוח מוסתר בחוץ משאירה אתכם לנחש את הנתיב שמתחתיו.

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

תנו ל-AllowedIPs למנות רק את הטווח הארגוני

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

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

[Interface]
PrivateKey = ...
Address = 10.99.4.2/32

[Peer]
PublicKey = ...
Endpoint = 198.51.100.44:51820
AllowedIPs = 198.51.100.44/32, 10.20.0.0/16, 10.21.0.0/16

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

סדר, מדדים והמתאם השני

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

# which interface currently claims the corporate prefix?
Find-NetRoute -RemoteIPAddress 10.20.10.5 | Select-Object -First 1

# prefer the corporate interface for its own prefixes
Set-NetIPInterface -InterfaceAlias 'Corp VPN' -InterfaceMetric 3
Set-NetIPInterface -InterfaceAlias 'wg-personal' -InterfaceMetric 40

wg show interfaces

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

לקוחות המבוססים על OpenVPN 2.6 מוסיפים מלכודת משלהם. כשמתאם פריקת ערוץ הנתונים כבר תפוס, מופע שני פשוט מסרב לעלות. הוספת disable-dco לפרופיל מחזירה לנתיב ה-TAP הישן, ואז שניהם פועלים זה לצד זה.

היכן הנתיב המקונן נשבר

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

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

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