אפליקציה אחת דרך WireGuard: קישור אינו ניתוב

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

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

קישור קובע כתובת מקור, ולא יותר

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

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

תנו למנהרה טבלה משלה

wg-quick מתקין נתיבים בכל מקום שהפרופיל אומר. הוספת Table = 40 תחת [Interface] מעבירה אותם לטבלה 40 במקום לטבלה הראשית. העלו את הממשק ואשרו שהם הגיעו: ip -4 route ls table 40 אמור להציג את נתיבי המנהרה, ו-ip -4 route get 10.66.127.142 מראה כיצד הגרעין פותר כעת אחד מהם. כשהנתיבים בטבלה משלהם, הטבלה הראשית ממשיכה לעבוד לכל השאר.

עשו את אותו דבר עבור IPv6 במקום להתאים קידומת רחבה. ip -6 rule add from fd00::2/128 lookup 40 נועל כתובת אחת; fc00::/8 עלול להתנגש בממשקים אחרים במארח וליצור כלל שמתאים ליותר מהמכוון.

הוסיפו את כלל המקור וצפו במונים

אחר כך חברו את החצאים: ip -4 rule add from 10.66.127.142/32 lookup 40, כאשר אותה כתובת מחוברת לממשק WireGuard. שימו את שני הכללים ב-PostUp כדי שחיבור מחדש ישחזר אותם. אמתו עם בקשה אמיתית ולא עם הגדרה: ip route get 1.1.1.1 from 10.66.127.142 אמור לנקוב בשם התקן המנהרה, ו-curl --interface wg0 ifconfig.me אמור לדווח על כתובת המנהרה ולא על כתובת הבית.

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

המקרה ההפוך: החזיקו את SSH מחוץ למנהרה

הבעיה ההפוכה נפוצה באותה מידה: wg-quick מחזיק בנתיב ברירת המחדל ו-הפעלת ה-SSH לשרת מתה באמצע ההפעלה. הכללים שלו יושבים במספר עדיפות נמוך, ולכן יש להעריך חריגה לפניהם. ip rule add dport 22 ipproto tcp table main priority 123 עושה זאת ב-iproute2 עדכני; במקום שבו הבורר אינו זמין, סמנו את הזרימה ב-nftables והתאימו את הסימון במקום.

בדקו גם את נתיב התשובה. הפעלת SSH שמתבססת ואז משתתקת סובלת בדרך כלל מניתוב א-סימטרי: כיוון אחד יוצא דרך המנהרה והשני דרך הממשק הפיזי. ip route get עבור כתובת השרת אומר לכם לאן התשובה תלך.

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