pfSense OpenVPN: להגיע לרשת מאחורי נתב אחר

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

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

חבילה אחת, שלוש החלטות ניתוב

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

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

תנו ללקוח קידומת, לא ניחוש

בשרת pfSense SSL/TLS עם רשת מנהרה IPv4 גדולה מ-/30, השדה IPv4 Local network(s) מפיץ מסלולים ללקוחות כשהם מתחברים. הוסיפו שם את הקידומת התחתונה במקום להסתמך על הלקוח שימציא אחת. לאחר מכן קראו את הטבלה בפועל של הלקוח לאחר החיבור, כי פרופיל עם route-nopull או מסנן מסלולים יכול להתעלם ממה שהשרת שלח. השרת יכול להיות תקין לחלוטין בזמן שהלקוח לא מתקין דבר.

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

כוונו את pfSense לנתב הפנימי

מסלול סטטי ב-pfSense צריך שער מוגדר ונגיש, והממשק שנבחר לשער הזה חייב להיות זה שבאמת מגיע אליו, כפי שמתאר מדריך המסלולים הסטטיים של Netgate. בפריסה להמחשה קישור המעבר הוא 192.168.77.1 בחומת האש ו-192.168.77.2 בנתב הפנימי, ורשת השירותים ב-172.16.30.0/25 מאחוריו. המסלול אז מציין את הקידומת ואת הקפיצה הבאה, לא את כתובת השירות. שימוש בכתובת מהרשת המרוחקת כשער הוא דרך נפוצה לבנות מסלול שנראה תקין ולא מעביר לשום מקום.

הקצאת שם לממשק אינה מתארת את הרשתות שמאחוריו. המסלול הסטטי הוא אותו תיאור.

הצד המרוחק חייב להכיר את הבריכה

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

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

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

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