חסימת IPv6 כדי לאבטח את WireGuard שוברת את המארח

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

שלוש אחריות, מערכת כללים אחת

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

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

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

מה ICMPv6 עושה עבור המארח

IPv6 נשען על ICMPv6 הרבה מעבר להדהוד. בקשת שכן והודעת שכן מחליפות את ARP והן נדרשות למסירה מקומית. Packet Too Big נושאת מידע MTU של המסלול, והתעלמות ממנה מייצרת העברות שנתקעות במנות גדולות. הודעות נתב נושאות את המסלול המוגדר כברירת מחדל ואת מידע הקידומת כאשר הקישור משתמש בתצורה אוטומטית.

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

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

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

אשרו את המנהרה, ואחר כך את השירות

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

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

קראו את מערכת הכללים כפי שהיא, ולא כפי שהקובץ מתאר אותה:

sudo nft list ruleset
ip -6 addr show
ip -6 route show default

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

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

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

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

ip -6 neigh show
ping -6 -c 3 2001:db8:1::1
sudo nft -c -f /etc/nftables.conf

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

שחזרו מארח שננעלתם ממנו

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

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

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