שינוי כלל בחומת האש לא עובד: סדר הכללים ומצב החיבור

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

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

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

מעקב חיבורים יוצר את התסמין השני, ומבחוץ הוא נראה זהה. ברגע שזרימה נמצאת בטבלת המצבים, אישור עבור established-or-related סמוך לראש השרשרת חוזר לפני שהכלל החדש שלכם בכלל נבחן. מיפויי NAT הם בעלי אותה תכונה: התרגום נקבע כשהזרימה החלה, ולכן כלל postrouting שערכתם אינו כותב מחדש הפעלה שכבר רצה. זו הסיבה ששינוי נראה עובד ב-09:00 עבור חיבור חדש ונראה שאינו עושה דבר עבור ההפעלה שמישהו פתח ב-08:55.

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

קראו את מערך הכללים הפעיל, לא את הקובץ שערכתם

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

nft list ruleset
iptables-save

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

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

כלל נעילה עם אפס חבילות אחרי ניסיון בדיקה אמיתי אינו בעיית מדיניות, הוא בעיית מיקום. העברתו היא שינוי של שורה אחת, והתחביר הוא בדיוק מה שגרם לבאג המקורי. עם iptables -I מוסיף בתחילה; -A מוסיף בסוף; עם nftables insert מציב כלל בראש השרשרת; add מוסיף בסוף. כשכלל חייב לנצח, אמרו זאת במפורש במקום לסמוך על הסדר שנטען במקרה.

הוכיחו אם הזרימה נמצאת במעקב

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

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

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

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

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

בדקו מזרימה חדשה עם דרך חזרה

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

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

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

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

תעדו מטרה ומיקום יחד עם הכלל

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

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