ניתוב חשבון Linux אחד דרך OpenVPN עם כלל UID

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

הדוגמה שלהלן מניחה חשבון דפדפן ייעודי ב-UID 1500, התקן מנהרה tun-office שנושא את הכתובת המקומית 10.80.0.11, ו-VPN שמתיר את היעדים המדוברים. הדמון עצמו רץ מחוץ ל-UID הזה.

שלושה תנאים שבוחרים את המנגנון

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

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

הטבלה, הכלל והשומר

לאחר בדיקת כללים קיימים ובחירת מספרי טבלה ועדיפות שאינם בשימוש, הסידור קצר: מסלול ברירת מחדל בטבלה ייעודית שנושאת את כתובת המקור של המנהרה, כלל ששולח את החיפושים של החשבון לטבלה הזו, וכלל מסיים שחוסם את הגיבוי. בכתב, זהו החלפת מסלול אידמפוטנטית, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, ואחריה ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

השומר הוא ip -4 rule add priority 12101 uidrange 1500-1500 unreachable, והוא חשוב יותר ממה שאורכו מרמז. בלעדיו, מסלול חסר בטבלה 51820 נופל לקישור העולה הרגיל והחשבון מדליף בשקט תעבורה שהמדיניות נועדה ללכוד. איתו, אותה תקלה הופכת לפסק זמן, כלומר חסימה ולא גיבוי.

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

מה שהניתוב לפי UID משאיר בחוץ: DNS

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

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

IPv6 זקוק למשפט משלו בתכנון

הכללים שלמעלה מכסים IPv4 בלבד. אם הדרישה היא מנהרת IPv4 בלי IPv6 ישיר מהחשבון הזה, הוסיפו כלל מסיים שנבדק כמו ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, ואז בדקו כללי IPv6 קודמים ואת חריגי ה-loopback שברצונכם לשמור.

חסימת IPv6 ישיר אינה מנהרור דו-ערוצי; זהו גבול. קריאה לזה מנהרור תבלבל את האדם הבא שיקרא את המדיניות, והבלבול יופיע כקריאת תמיכה על אתר IPv6 שבור.

אמתו עם החשבון האמיתי, ואז החזיקו במחזור החיים

השוו חיפושים: ip -4 route get 198.51.100.25 uid 1500 מול אותו יעד עם UID רגיל. אחר כך בצעו בקשה מותרת תחת החשבון הייעודי ובדקו את כתובת המקור שהצד המרוחק רואה. כתובת מקור מועדפת אינה source NAT, והיא לא תגבר על אפליקציה שכורכת משהו אחר. אם שני החיפושים מחזירים אותו מסלול, הכלל לא עושה את מה שאתם חושבים.

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