סט nftables שמזין DNS אל WireGuard: איך עובדת ההעברה

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

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

מה תשובת DNS יכולה לעשות ומה לא

dnsmasq יכול להעתיק כתובות מהתשובות לסט nftables, וזה הזנה ולא החלטת ניתוב. האפשרות הזו, המתועדת במדריך dnsmasq, מציינת את המשפחה, הטבלה והסט, וה-4# המוביל שלה בוחר רשומות A בלבד, ולכן יעדי v6 זקוקים לסידור משלהם. הסט חייב כבר להתקיים, כי הפותר מוסיף איברים למשהו שבעל חומת האש יצר. שום דבר בשלב הזה לא בוחר ממשק, טבלה או עמית.

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

הסט הוא קלט, לא נתיב

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

nft add set inet vpn_select office_v4 { type ipv4_addr\; }
ip rule add fwmark 0x40 table 200
ip route add default dev wg0 table 200
wg show wg0 allowed-ips

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

סימונים, טבלאות וכיסוי העמית

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

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

בדקו כל תוחלת חיים בנפרד

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

dig +short office.example
nft list set inet vpn_select office_v4
conntrack -L -d 10.60.8.15
ip rule show

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

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