נתבו רק את פורט 25 לתוך המנהרה, לא את המארח

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

כלל פורט אינו נתיב ברירת מחדל

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

שתי הגדרות של wg-quick הן תנאים מוקדמים ולא חלק מהמדיניות. AllowedIPs = 0.0.0.0/0 מאפשר ל-peer לשאת יעדי IPv4 שרירותיים, ו-Table = off מונע מ-wg-quick להתקין את נתיב ברירת המחדל שלו עבור הקידומת הזו. אל תערבבו את ההוראות האלה עם מנהל שמחיל מדיניות ניתוב משלו, כי השניים לא יסכימו מי הבעלים של הטבלה הראשית.

כתבו את הנתיב, הבורר והשומר

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

ip -4 route add default dev wg0 src 10.77.0.2 table 51825
ip -4 rule add priority 10000 iif lo ipproto tcp dport 25 lookup 51825
ip -4 rule add priority 10001 iif lo ipproto tcp dport 25 unreachable

iif lo מגביל את הכלל לתעבורה שמקורה מקומי, ו-ipproto tcp dport 25 מזהה את כיוון החיבור; התיעוד של ip-rule מתאר את שני הבוררים. הם קיימים בקרנלים ובגרסאות iproute2 הנוכחיים, ובמערכת ישנה יותר הכלל נדחה לחלוטין, וזה כשל ברור יותר מכלל שנטען ולא מתאים לשום דבר.

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

כתובת המקור חייבת להסכים

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

בשער, ה-peer של הלקוח חייב לאשר את המקור שהוא באמת מקבל, כלומר 10.77.0.2/32 ולא קידומת יעד רחבה. העתקת 0.0.0.0/0 של הלקוח לכל peer בשער מבלבלת מי ה-peer שמחזיק איזו תעבורה. השער זקוק גם להעברה, למדיניות חומת אש שמתירה את הזרימה, ולנתיב חזרה, כולל תרגום יציאה כאשר במעלה הזרם לא יכול לנתב כתובת מנהרה פרטית.

בדקו את נתיב החזרה, ואז את ההתמדה

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

ip -4 route get 198.51.100.25 ipproto tcp dport 25
ip -4 route get 198.51.100.25 ipproto tcp dport 443

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

היכן שניתוב א-סימטרי מורשה, מצב רופף המוגבל לממשק דרך net.ipv4.conf.wg0.rp_filter=2 עשוי להתאים, וכדאי לבדוק תחילה את המקסימום האפקטיבי של ערכי all והממשק. אל תשביתו אימות באופן גלובלי כקיצור דרך. לאחר מכן מסרו את הטבלה, העדיפויות והשומר למי שמחזיק בתצורה, ופתחו חיבורים חדשים לאחר התחברות מחדש כדי לאשר שהבחירה עדיין מחזיקה. זכרו שתגובות מכל מאזין SMTP מקומי נושאות פורט מקור 25 ולא פורט יעד 25, וזו שאלת מדיניות נפרדת.