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

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

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

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

תאר את החריג שאתה באמת מתכוון אליו

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

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

sudo ufw allow out on enp3s0 proto udp to 192.0.2.44 port 1194
sudo ufw status verbose

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

רענן אותו כתהליך עבודה אחד

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

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

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

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

הוצא את ההרשאה הישנה במכוון

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

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

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

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