שני לקוחות VPN, שתי כתובות ציבוריות: התאימו את ה-SNAT

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

איזו זהות שורדת עד השער

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

iptables -t nat -S POSTROUTING

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

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

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

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

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

הוסיפו לפני ה-masquerade הכללי

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

ip -4 route show default
iptables -t nat -L POSTROUTING -n -v --line-numbers

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

iptables -t nat -I POSTROUTING 1 -s 10.88.4.20/32 -o ens3 -j SNAT --to-source 198.51.100.77
iptables -t nat -I POSTROUTING 1 -s 10.88.4.21/32 -o ens3 -j SNAT --to-source 198.51.100.78

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

הוכיחו את המקור בזרימה חדשה

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

conntrack -L -s 10.88.4.20 -p tcp --dport 443

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

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