קבוצות עמיתים של WireGuard במרכז: בעלות על המקור ומדיניות
החזיקו קבוצות עמיתים נפרדות עם כתובות מקור צרות לכל עמית ומדיניות העברה, בלי ממשק מנהרה נפרד לכל קבוצה.
מרכז שמריץ WireGuard יכול להחזיק קבוצות עמיתים נפרדות בלי ממשק או טבלת ניתוב נפרדת לכל קבוצה. שני מנגנונים עושים את העבודה, וערבוב ביניהם הוא הסיבה הרגילה לכך שמדיניות נראית נכונה ולא עושה דבר. שכבה אחת מחליטה מי רשאי לתבוע כתובת מקור. האחרת מחליטה לאן מותר לחבילה הזו לצאת.
שני תפקידים, מוחזקים בנפרד
שכבת המנהרה עונה על שאלה צרה: האם המפתח של העמית הזה אישר את כתובת המקור הפנימית הזו. שכבת ההעברה עונה על שאלה רחבה יותר: האם החבילה הזו רשאית לצאת אל היעד ההוא. אף אחת מהן אינה עונה על שאלת האחרת, ואף אחת מהן לבדה אינה מדיניות גישה שלמה.
ההפרדה הזו היא הסיבה לכך שעמית יכול להיות מאומת, ממוען נכון, ובכל זאת לא להצליח להגיע למארח שהוא לא אמור להגיע אליו. היא גם מסבירה את ההפך: כלל חומת אש שמתיר הכול לא מוכיח דבר על מי רשאי לתבוע איזו כתובת.
תכננו את שתי השכבות יחד, ואז בדקו את שתיהן. תצורה שנכונה בשכבה אחת ולא נבדקה בשנייה נכשלת בפתוח או בסגור בהתאם לברירת המחדל.
תנו לכל עמית רק את הכתובת של עצמו
עמיתים מרובי מארחים מפתים אתכם להעניק את כל טווח הקבוצה בצד השרת. ההרשאה הזו היא תביעת כתובת מקור, ולכן לקוח שנפרץ או שהוגדר לא נכון יכול להציג כל כתובת בטווח והמנהרה תקבל אותה. הקצו /32 לכל עמית עבור הכתובת הפנימית שלו. הגדירו טווחי קבוצה רק בלקוחות, שם הם מתארים אילו יעדים הלקוח הזה רשאי להגיע אליהם ולא אילו מקורות הוא רשאי להשתמש בהם.
אז חומת האש מתאימה מקור שאפשר לסמוך עליו. כלל שנכתב עבור טווח הקבוצה נשאר קיבוץ שימושי, והוא נעשה משמעותי רק כאשר אף עמית בודד לא יכול לתבוע כתובת ששייכת לחבר אחר.
כתבו את מדיניות ההעברה שמפרידה בין קבוצות
התעבורה המעניינת כאן נכנסת ויוצאת דרך אותו ממשק מנהרה, ולכן היא חוצה את נתיב ההעברה ולא את נתיב הקלט של המארח. הכללים שייכים לשרשרת ההעברה הקיימת של מי שמנהל את חומת האש ובעל המארח, והם שברים ולא סט כללים שלם.
iifname "wg0" oifname "wg0" ip saddr 10.66.10.0/24 ip daddr 10.66.10.0/24 accept iifname "wg0" oifname "wg0" ip saddr 10.66.20.0/24 ip daddr 10.66.20.0/24 accept iifname "wg0" oifname "wg0" drop
שני הכללים הראשונים מתירים תעבורה בתוך כל קבוצה. האחרון חוסם כל דבר אחר שחוצה את הממשק הזה, וזה מה שיוצר את הבידוד בין הקבוצות. הוסיפו כללים מפורשים למשפחת הכתובות האחרת אם אתם זקוקים להם, כי חסימה שנכתבה עבור IPv4 אינה מתירה ואינה מתארת את התנהגות IPv6.
הסדר מחליט אם המדיניות חלה
סדר הכללים חשוב יותר מהשבר עצמו. כלל גנרי שמקבל חיבורים מבוססים ושמוצב לפני הרשומות האלה מאפשר לזרימה ותיקה בין קבוצות להימשך, ולכן הבידוד חל רק על חיבורים חדשים. החליטו איזו משתי התוצאות אתם רוצים לפני שאתם טוענים מחדש.
פסק דין של קבלה גם אינו תמיד סופי בין שרשראות באותו וו. אם שרשרת בסיס אחרת רצה מאוחר יותר, המדיניות האפקטיבית היא השילוב, ולכן בדקו את המונים ולא את הקובץ שערכתם. המונים הם הראיה הזולה ביותר הזמינה. כלל בלי ספירת מנות אינו מתאים, וכלל שמתאים בזמן ששרשרת מאוחרת מקבלת אומר לכם שהחסימה נמצאת במקום הלא נכון.
בדקו את המטריצה, לא את מספר הקבצים
בנו מטריצה קטנה של תוצאות צפויות ובדקו כל תא. מקבוצה A לקבוצה A אמור לעבוד, מקבוצה B לקבוצה B אמור לעבוד, ומ-A ל-B לא אמור, בשני הכיוונים ולשתי משפחות הכתובות אם אתם תומכים בהן.
nft list ruleset wg show wg0 allowed-ips ping -c 2 10.66.10.5 conntrack -L -s 10.66.20.7 2>/dev/null | head
השניים הראשונים מראים מה מוגדר. ה-ping מחבר בקבוצה הלא נכונה מראה מה קורה בפועל. רשימת conntrack מראה אם זרימה ותיקה עדיין מתקבלת, וכך שינוי בידוד נכשל בשקט להיכנס לתוקף.
שירותי מארח במרכז והגישה ל-LAN שמאחוריו הם נתיבים נפרדים עם מדיניות נפרדת. רשמו אילו מהם המטריצה מכסה, כי בדיקה שבודקת רק תעבורה בין עמיתים אינה אומרת דבר על אף אחד מהם.