מתי NAT בתוך VPN מאתר לאתר מזכה את מקומו

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

החלט איזו כתובת נכתבת מחדש

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

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

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

ip xfrm policy show
ip xfrm state show
nft list ruleset | grep -A4 nat

עקוב אחר המטען ונתיב החזור

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

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

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

שקול זאת מול מספור מחדש של אתר

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

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

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

הוכח את שני הכיוונים עם הפעלה אמיתית

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

tcpdump -ni any host 10.40.9.20 and port 443
conntrack -L | grep 10.40.9.20
ip route get 10.40.9.20

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

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