מתג חירום או גישה לרשת המקומית? שתי תשובות ל-WireGuard

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

שני כשלים נושאים את אותו תסמין

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

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

שלושה תנאים מכריעים את התשובה

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

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

בחרו בסגירה בטוחה ותוותרו על הרשת המקומית

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

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

בחרו בגישה לרשת המקומית ובטאו את ברירת המחדל אחרת

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

[Peer]
AllowedIPs = 0.0.0.0/1
AllowedIPs = 128.0.0.0/1
AllowedIPs = ::/1
AllowedIPs = 8000::/1
Endpoint = vpn.example.net:51820

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

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

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

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultOutboundAction
route print 0.0.0.0

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

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