יציאה נפרדת: מאגר VPN על usb0, תעבורת השער על eth0

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

ודאו שכתובת המקור שורדת עד להחלטת הניתוב

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

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

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

בנו טבלה נבחרת שהיא מלאה

טבלה אינה נתיב ברירת מחדל עם חבר. היא זקוקה למספיק נתיבים כך שכל חיפוש ייפתר בתוכה, כולל הנתיב המחובר של תת-רשת ה-WAN כדי שהצעד הבא יהיה נגיש. עבור מאגר 10.77.0.0/24 על tun1, כתובת WAN 203.0.113.20/24 עם צעד הבא 203.0.113.1, וטבלה 600:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

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

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

השאירו את התעבורה של המאזין עצמו מחוץ למדיניות

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

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

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

התאימו את ההעברה והתרגום לנתיב

ניתוב בוחר קישור עליון; הוא אינו מעניק הרשאה להעביר. הגרעין חייב שהעברת IPv4 תהיה מופעלת, וחומת האש חייבת לקבל את הכיוון מהלקוח ל-WAN ואת תעבורת החזרה. טבלה נכונה עם שרשרת FORWARD שמפילה את הזרימה נותנת את אותו סימפטום כמו נתיב חסר, ולכן שניהם נבדקים באותה מעבר.

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

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

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

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

החליטו מה קורה כאשר usb0 נעלם

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

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

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