מחשב נייד בעבודה על VPN אישי: מה באמת חוצה

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

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

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

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

שלוש נקודות חצייה, נסקרות בנפרד

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

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

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

בקשו משאב אחד, לא שתי רשתות

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

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

כללו השפעות של DNS ונתיבים

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

Resolve-DnsName intranet.corp.example -Type A
Get-DnsClientNrptPolicy -Effective
route print 0.0.0.0

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

אמתו והשאירו דרך יציאה

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

Test-NetConnection -ComputerName files.corp.example -Port 443
Get-NetConnectionProfile

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