מדוע nftables אינו רואה תעבורת OpenVPN בין לקוחות

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

עקבו אחר מנה אחת דרך השרת

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

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

מבחן המונה שמכריע איזה מסלול רץ

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

sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forward

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

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

מתג אינו רשימת גישה

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

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

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

בחירת נקודת ההעברה

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

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

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

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

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

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