שני לקוחות OpenVPN על שער Linux אחד: חלקו את המדיניות

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

הגרעין מחליט, לא הדימון

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

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

תנו לכל מופע את מערך המשאבים שלו

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

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

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

כתבו את המטריצה: מקור, טבלה, התקן

לכל קבוצת לקוחות, הוסיפו כלל שבוחר טבלה לפי כתובת מקור, ואז שימו את הנתיב המבוקש באותה טבלה:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

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

התעבורה של המנהרה עצמה אינה בקבוצת לקוחות

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

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

בחירת נתיב אינה מתירה אותו

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

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

מה קורה כשמנהרה אחת נופלת

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

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