אותו תת-רשת בשני הקצוות: מפו את ה-LAN המרוחק לטווח פנוי

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

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

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

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

סדר הארגומנטים הוא כל הטריק

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

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

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

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

המיפוי לא יוצר נתיב חזרה

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

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

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

שמות ומטענים שורדים את התרגום

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

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

שלוש בדיקות לפני שמתחייבים

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

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

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