NAT של ה-LAN דרך tun0 בשער VPN של OpenBSD

שני מהנדסים עם אותה שער OpenBSD ימסרו לך לעיתים קרובות שתי ערכות חוקים שונות להגעה לרשת מרוחקת, ושתיהן ניתנות להגנה. הבחירה בין תרגום מקור לבין נתיב חזרה אינה שאלת תחביר כלל. היא תלויה במה שהצד המרוחק כבר יודע על 192.168.88.0/24 ובמה שאתה צריך לשמור ביומנים שלך. טעות בזה והשורה nat-to תיראה מושלמת לחלוטין בזמן שהתשובות נעלמות לשער ברירת המחדל המרוחק.

ניתוב ושכתוב עונים על שאלות שונות

טבלת הניתוב קובעת ש-172.20.0.0/16 נגיש דרך tun0, וההחלטה הזו מתקבלת לפני שמתייעצים עם תרגום pf כלשהו. תרגום המקור משנה אחר כך את כותרת החבילה כך שהקצה המרוחק רואה את כתובת המנהרה של השער במקום מארח LAN. אף אחד מהמנגנונים לא מחליף את השני: חוק nat אינו יכול לחולל נתיב, ונתיב אינו יכול לשכנע נתב מרוחק שמעולם לא שמע על תת-הרשת הפרטית שלך. כשהצד המרוחק חסר נתיב חזרה, התשובות נזרקות או נשלחות לשער ברירת המחדל שלו, ושום כיוון חוקים לא מתקן את זה.

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

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

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

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

מיקום הקטע כך ש-pf באמת יעריך אותו

הקטע שלהלן מניח שה-LAN הוא 192.168.88.0/24, שהרשת המרוחקת היא 172.20.0.0/16 ושממש המנהרה הוא tun0. שום דבר בו לא בוחר קפיצה הבאה. הוא רק משכתב את המקור בחבילות שכבר יוצאות דרך המנהרה.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

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

אל תשכח את צד הליבה. העברת IPv4 חייבת להיות מופעלת, וחוקי pass עם מצב עבור מנהרה ו-LAN חייבים להתקיים לפני שכל זה משמעותי. קטע PF NAT בשאלות הנפוצות של OpenBSD הוא ההפניה הנכונה לסדר מילות המפתח כאן.

אמת את ערכת החוקים לפני שתסמוך על התעבורה

בדוק תחביר תחילה עם pfctl -nf /etc/pf.conf, שמנתח את הקובץ בלי לטעון אותו. אחר כך טען את המדיניות וקרא בחזרה מה הליבה באמת מחזיק, כי חוק שנותח נקי עדיין יכול להיות מוסתר או להיות מחובר לממשק הלא נכון. pfctl -sn מדפיס חוקי תרגום בצורתם הטעונה, ו-pfctl -sr מדפיס חוקי סינון לפי סדר הערכה.

עקוב אחרי החוט בשלב הבא. בשער, tcpdump -ni tun0 'host 172.20.0.10' מראה אם כתובת המקור שיוצאת מהמנהרה היא כתובת המנהרה או מארח ה-LAN. netstat -rn -f inet מהיר מאשר לאיזה ממשק היעד נפתר. ברגע שהתעבורה זורמת, pfctl -ss מציג רשומות מצב; אם זרימה לא יצרה מצב, החבילה מעולם לא התאימה לחוק שיוצר אחד.

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

כשתרגום עולה יותר ממה שהוא חוסך

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

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

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