nftables: הוסיפו את כלל ההרשאה של VPN לפני ידית ההשלכה

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

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

שני מיקומים, שתי תוצאות שונות

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

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

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

ידית מזהה כלל, לא מספר שורה

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

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

iptables --version
nft -a list ruleset

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

מצאו את השרשרת ואת הכלל שבאמת משליך

קראו את hook הקלט, את עדיפות השרשרת ואת הכלל שדוחה את זרימת המאזין הזו. טבלת inet עשויה לשאת את שתי משפחות הכתובות, אבל כלל בודד עדיין יכול להתאים רק ל-IPv4.

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

insert rule inet filter input handle 42 iifname "eth0" ip saddr 198.51.100.25 udp dport { 500, 4500 } counter accept

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

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

ההרשאה מוגבלת, ההשלכה סופית

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

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

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

בדקו את הקובץ, ואז אמתו את התוצאה החיה

הריצו בדיקת תחביר וטרנזקציה על הקובץ הנבדק לפני הפעלתו. מצב הבדיקה מדווח אם nft יכול לנתח ולסדר את השינוי; הוא אינו מפעיל אותו ואינו מוכיח ש-hook אחר יאפשר את החבילה. הקובץ נשאר הצעה עד שהבעלים יפעיל אותו:

nft -c -f reviewed-vpn-rule.nft

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

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