חיבורים חדשים ביציאת VPN חדשה, זרימות ישנות נשארות לנפשן
ניקוז מתוכנן מעביר רק זרימות לא מסווגות. השוו זאת להחלפת נתיב, וראו את הסימונים, הטבלאות ומצב conntrack שמחזיקים אותו.
שתי יציאות VPN תקינות, העלאה ארוכה שכבר פועלת, ודרישה שהחיבור הבא ישתמש במנהרה האחרת. יש שתי דרכים למלא זאת, ורק אחת מהן בטוחה בשער פעיל. החלפת נתיב ברירת המחדל מעבירה כל מנה, כולל אלו ששייכות להעלאה. ניקוז מתוכנן משנה את הבחירה עבור חיבורים חדשים ומשאיר את הזרימות הנעקבות בנתיב שבו החלו.
שתי דרכים להחליף יציאה
החלפת נתיב היא פקודה אחת וניתנת לביטול בשניות, ולכן משתמשים בה בזמן תקלות. היא גם לא מבחינה: מנות ההעלאה הקיימת יוצאות לפתע דרך מנהרה אחרת, עם כתובת מקור ציבורית אחרת ומצב תרגום נפרד.
אם הצד המרוחק עוקב אחרי זרימות לפי כתובת מקור, ההעלאה עשויה פשוט להפסיק להיות מזוהה. הניקוז מונע זאת על ידי קבלת ההחלטה פעם אחת לכל חיבור ושמירתה, כך שההעלאה הישנה שומרת על היציאה שלה עד שהיא מסתיימת. זה כל הערך של התרגיל: הצד המרוחק לא רואה שום שינוי שעליו לפרש. הוא ממשיך לקבל מנות שמתאימות לחיבור שהוא כבר מכיר.
המחיר הוא מורכבות: שתי טבלאות ניתוב, מסווג שרץ בקרס הנכון, וסימונים שחייבים להיות מתואמים עם כל דבר אחר במכונה שמשתמש בהם.
תנו לכל יציאה טבלה משלה
הקצו טבלת ניתוב לכל יציאה וערכי סימון או ביטים נפרדים לשתי האפשרויות. כל טבלה זקוקה לנתיבים המתאימים לתפקידה, לא רק לשם, והיא זקוקה לתוצאת כשל מכוונת למקרה החסר. טבלה ריקה שנופלת בשקט לטבלה הראשית — כך תעבורה יוצאת דרך יציאה שאיש לא בחר.
ip rule add fwmark 0x10/0x10 table 101
ip rule add fwmark 0x20/0x20 table 102
ip route add default via 192.0.2.1 dev wg-a table 101
ip route add default via 198.51.100.1 dev wg-b table 102הוסיפו נתיב blackhole בסוף כל טבלה כדי שחיפוש שלא מוצא התאמה ייכשל בקול רם במקום להימלט לברירת מחדל שלא בחרתם.
בחרו פעם אחת, במנה הראשונה
סווגו לאחר שמעקב חיבורים קיים ולפני חיפוש הנתיב החשוב. עבור חיבור LAN חדש ולא מסווג, בחרו את היציאה ושמרו אותה במצב החיבור. במנות מאוחרות יותר, שחזרו את הערך השמור לסימון המנה שממנו קורא הניתוב לפי מדיניות.
החלק העדין הוא מה פירוש חדש. conntrack עדיין יכול לדווח NEW עבור מנות מוקדמות ושידורים חוזרים לפני שנראית תשובה, ולכן מסווג שמסתמך רק על המצב הזה עלול לדרוס בחירה שכבר עשה. בדקו שלא נשמרה יציאה עבור החיבור לפני שמקצים אחת.
nftables שומר על סימוני מנה וחיבור בנפרד, ומתאר מדריך המטא-מידע את ההעתקה המפורשת ביניהם. סימון חיבור לא הופך מעצמו לסימון המנה שהכלל שלכם מתאים לו, וזו הסיבה הנפוצה ביותר לכך שמסווג שנכתב בקפידה אינו משפיע.
הגבילו את השחזור לכיוון ולתעבורה שאתם מתכוונים אליהם. החלת סימון יציאת אינטרנט על מנות חוזרות עלולה לשלוח תשובות לעבר היציאה במקום ל-LAN, והתסמין הוא חיבור חד-כיווני שנראה כמו בעיית חומת אש. קראו את נתיב התשובה לפני שנוגעים בכלל חומת אש, כי המנה מנותבת, רק לא חזרה לשולח.
ארבעה שלבים של ניקוז
הכינו את B בלי לגעת ב-A: ניתוב, העברה, הרשאה, NAT ונתיב החזרה. התקינו את הטבלה ומדיניות הבחירה שלו דרך בעל התצורה הקיים של השער.
החליפו את המסווג כך שחיבורים חדשים ולא מסווגים יבחרו ב-B, תוך שמירה על הבחירות השמורות. עסקת nftables אטומית מונעת חלון שבו יש לנקות את המצב הישן.
השאירו את A פועל עד שהזרימות שלו מסתיימות. הממשק, הטבלה, היציאה המרוחקת ומיפויי ה-NAT שלו עדיין חלק מהזרימות האלה, ועריכת כלל NAT אינה בונה מחדש קשרים שכבר קיימים.
הוציאו את A משירות כשמתקיים תנאי הניקוז, לפי מצב החיבורים והתנהגות היישום ולא לפי מרווח שקט אחד.
מה ניקוז לא יכול להבטיח
בקשת דפדפן אינה חיבור תעבורה חדש; האיגוד ממשיך לשלוח בקשות דרך הישן. לעומת זאת, זרימת UDP עלולה להתיישן מ-conntrack ומנה מאוחרת מסווגת מחדש. הניקוז עוקב אחרי זרימות נעקבות, לא אחרי תפיסת היישום לגבי הפעלה.
אם A נכשל לפני שזרימותיו מסתיימות, הסימון השמור לא מציל אותן. הן מתחברות מחדש דרך B, או שאינן מתחברות כלל. ניקוז מתוכנן קונה המשכיות כל עוד הנתיב המקורי בריא; הוא אינו שכפול מצב בין יציאות בלתי תלויות.
אמתו את שני החצאים
התחילו חיבור מורשה ארוך טווח לפני השינוי ואחד ממש חדש אחריו. אשרו איזו מנהרה כל אחד משתמש ואיזו כתובת מקור ציבורית הצד המרוחק רואה, ואז בדקו שתעבורת החזרה חוזרת.
אל תרוקנו את טבלת conntrack כדי שהבחירה החדשה תופיע. זה הורס בדיוק את המצב שהניקוז אמור לשמר, והופך מעבר מבוקר לתקלה עם בדיקה שנראית נקייה.