SSH לכתובת ה-IP הציבורית של שרת WireGuard נכשל ב-Windows

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

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

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

הרשאת ניתוב והרשאת חומת אש שונות זו מזו

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

לכן traceroute לנקודת הקצה יכול להצליח בעוד ניסיון SSH נכשל. את הראשון נושאת השירות שבעליו החריגה, ואת השני לא.

מה /0 עושה ב-Windows

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

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

חריגות משנות את מודל ההגנה

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

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

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

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

ipconfig | findstr /i "WireGuard IPv4"
wg show
ssh -v [email protected]
Test-NetConnection 203.0.113.9 -Port 22

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

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

מאמרים קשורים