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

האזור שורד עד שהממשק נוצר מחדש

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

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

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

קראו שלושה דברים לפני שמשנים משהו

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

רשמו גם את שם ההתקן האמיתי בכל שלב, כי מנהרה שנוחתת היום על tun0 עשויה לנחות מחר על tun1.

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

כש-NetworkManager הוא הבעלים של החיבור

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

שינוי המאפיין הזה יכול להשפיע על חיבור פעיל מיד.

השאירו נתיב ניהול זמין וקראו את המדיניות של אזור היעד לפני שמחילים אותה. עריכה של שדה ZONE בקובץ ifcfg נכונה רק במקום שבו הקובץ הזה עדיין מקור התצורה.

כש-firewalld הוא הבעלים של הקישור

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

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

אל תזרקו את הממשק ל-trusted רק כדי שהיישום יעבוד.

בדקו את הטעינה מחדש, את החיבור מחדש ואת האתחול מחדש

שינוי מסתיים רק כשהוא שורד את כל השלושה.

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

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

כתבו את הבעלים, את הערך ואת התוצאה הצפויה ל-runbook, וההקצאה הבאה תהיה מוסברת.

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