האם כדאי להחיל SNAT על העברת פורט אל תת-רשת VPN?

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

מדוע התשובה יוצאת לדרך אחרת

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

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

כלל מקור צר מספיק כדי לסמוך עליו

הפכו את הנתב למקור שהמארח המרוחק עונה לו. בפריסה הזו כתובת ה-WAN היא 203.0.113.24, ה-LAN הוא 192.168.88.0/24, כתובת המנהרה של הנתב היא 172.20.5.1, והשירות עונה בכתובת 172.20.5.40:8443. הכלל שלמטה מתאים לחבילה שלאחר תרגום היעד, ולכן הוא נוקב בכתובת המתורגמת ולא בכתובת הציבורית. שום דבר בו אינו תלוי בכתובת הלקוח, וזו בדיוק הנקודה.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

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

מתי הסוואה גורפת היא הבחירה הכנה

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

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

בדקו את המונים לפני פרסום

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

iptables -t nat -L POSTROUTING -v -n --line-numbers

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