חסמו טווח יעד אחד לכל מאגר לקוחות VPN
כלל nftables אחד יכול לסרב לקידומת יעד עבור מאגר VPN מאושר בלי לפגוע בתעבורה של השער עצמו. התאימו את ה-hook ואת המיקום.
כלל אחד יכול להרחיק מאגר VPN מאושר מטווח יעד בלי להפריע לשום דבר אחר שהשער עושה. הכלל עצמו קצר; מה שקובע אם הוא יעבוד הוא ה-hook שבו הוא חי והמיקום שלו בשרשרת. טעות בשני אלה מייצרת חומת אש שנראית נכונה ומתנהגת באופן לא עקבי. התחילו ממה שהמנה עושה כאשר הכלל רואה אותו.
מה הכלל באמת מתאים
הכלל מתאים שלושה דברים בבת אחת: ממשק קלט, קידומת מקור וקידומת יעד. שלושתם חייבים להיות נכונים לפני שה-drop חל, וזה מה ששומר עליו צר. לקרוא אותו כביטוי אחד קל יותר מאשר לקרוא אותו כשלוש מדיניות נפרדות.
התאמת הממשק היא מה שמבדיל תעבורת לקוחות מועברת מהחיבורים של השער עצמו. בלעדיה, כלל שמציין רק את מאגר המקור היה משפיע גם על מנות שהשער עצמו מייצר מאותה כתובת, אם אי פעם יעשה זאת. קידומת המקור מגבילה את המדיניות ללקוחות מאושרים, וקידומת היעד מגבילה אותה לטווח אחד. קראו את הכלל כחתך ולא כרשימה.
רשמו את שלושת הערכים לפני שאתם עורכים משהו: שם ממשק המנהרה, המאגר שהשרת מחלק, והקידומת שאתם מתכוונים לסרב לה. שגיאת הקלדה בכל אחד מהם מייצרת כלל שמנותח נקי ולא מגן על דבר. שמרו את שלושת הערכים ברשומת השינוי לצד הכלל.
ה-hook קובע על מי הכלל חל
שרשרת netfilter מחוברת ל-hook, וה-hook קובע אילו מנות השרשרת בכלל רואה. ה-hook forward רואה תעבורה שמנותבת דרך השער, וזו בדיוק התעבורה מלקוח ליעד. כל השאר בשרשרת מכוון לקהל אחר.
ה-hook input רואה תעבורה שמופנית לשער עצמו, כך שכלל שמוצב שם שולט בגישה לשירותים שלו ולא במעבר. ה-hook output רואה תעבורה שהשער מייצר, וזה ההפך ממה שדרוש למדיניות מאגר לקוחות. שמות שרשראות הם תוויות שרירותיות שנבחרו בידי מי שכתב את מערך הכללים, לכן אל תסיקו את ה-hook מהשם. בדקו היכן השרשרת מחוברת לפני שאתם מניחים מה היא יכולה להתאים.
| Hook | Traffic it sees | Right for this policy |
|---|---|---|
| input | Addressed to the gateway | No, that is the host's own services |
| forward | Routed through the gateway | Yes, for client-to-destination traffic |
| output | Generated by the gateway | No, that is the opposite direction |
קריאת החיבור היא בדיקה של שורה אחת שמונעת מכלל לנחות בשרשרת שלעולם אינה רואה את המנה.
מקמו את הכלל לפני ה-accept הרחב
כללים מוערכים לפי סדר, והכרעה ראשונה מנצחת. accept רחב מוקדם יותר בשרשרת מסיים את ההערכה עבור המנות שהוא מתאים להן, כך ש-drop שנוסף אחריו לעולם לא רץ עבורן. כלל הסדר הזה הוא כל הסיבה לכך שכלל שנראה נכון יכול להיות חסר השפעה.
הכניסו את הכלל לפני ה-accept במקום להוסיף אותו בסוף. אם השרשרת כבר מכילה accept כללי עבור ממשק המנהרה, הכלל החדש חייב לבוא לפניו אחרת הוא קישוט. בדקו את הסדר שנוצר ולא את הקובץ שערכתם, כי מערך כללים שנבנה מכמה קבצים אולי אינו תואם לאף אחד מהם. לאחר מכן אשרו באמצעות מנות בדיקה מהמאגר.
sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.confהפקודה השלישית מנתחת את הקובץ בלי ליישם אותו, וזה תופס שגיאות תחביר לפני שהן הופכות לתקלה. יישמו עם תוכנית חזרה, כי כלל שגוי בשרשרת forward יכול לחתוך את המנהרה שאתם עובדים דרכה.
זרימות קיימות לא אכפת להן מהכלל החדש שלכם
רשומת conntrack שנוצרה לפני שהכלל היה קיים ממשיכה להתאים ל-accept המוקדם. לכן drop חדש לפעמים נראה עובד לחיבורים חדשים ולא עושה דבר לזה שנבדק.
קראו את התאמת המצב בראש השרשרת. אם היא מקבלת תעבורת established ו-related לפני הכלל שלכם, כל זרימה שכבר בעיצומה ממשיכה לזרום עד שהיא נסגרת. בדרך כלל זה ההתנהגות שאתם רוצים לכלל חירום, והיא מבלבלת כשאתם מצפים לניתוק מיידי. החליטו איזו השפעה אתם רוצים לפני הפריסה. בדיקה שמשתמשת מחדש בחיבור פתוח תספר לכם סיפור שגוי.
sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'הפקודה הראשונה מראה אם קיימת זרימה, והשנייה מראה אם כלל מצב מוקדם ממשיך לקבל אותה. שתיהן לקריאה בלבד ובטוחות להרצה בזמן תקלה.
מה הכלל הזה אינו
הכלל אינו רשימה שחורה של דומיינים, מדיניות IPv6 או הגבלה על חשבון יישום בודד.
כל אחד מאלה צריך מנגנון משלו. חסימת דומיין חייבת לפתור שמות, מה שמסנן מנות לא עושה. תעבורת IPv6 צריכה התאמה משלה, כי ביטוי ip לא אומר דבר על מנות ip6. הגבלה ברמת היישום שייכת לשירות או לפרוקסי מאומת ולא להתאמת קידומת. דווקא ההפרדה בין הדרישות האלה היא שמונעת מבקשה מכלל צר אחד לעשות ארבע עבודות.
החוזה שהכלל הזה מספק הוא מדויק: תעבורה ממאגר מאושר לקידומת יעד אחת נדחית, בעוד תעבורה לא קשורה של השער שומרת על המדיניות הקיימת שלה. כתבו את המשפט הזה לצד הכלל, והאדם הבא יידע לשם מה הוא היה.