נתבו בין רשתות LAN פרטיות לפני שתוסיפו עוד NAT
מרחב כתובות חופף, נתיב חזור חסר או מעבר לא מהימן מכריעים בין ניתוב, NAT ומנהרה. בדקו את שלושת אלה לפני שתערכו את חומת האש.
שתי חומות אש פנימיות, קטע מעבר פרטי אחד ובקשה לאפשר לכמה מארחים בכל LAN לדבר עם אלה שבאחרת. הרפלקס הוא להקים VPN או להוסיף שכבה שנייה של NAT, ושתי הרפלקסים עולים יותר ממה שהבעיה ראויה לו. ניתוב רגיל מספיק כאשר שלושה תנאים מתקיימים: טווחי הכתובות אינם חופפים, שני הצדדים יכולים להחזיר תעבורה ל-LAN האחר, וקטע המעבר מהימן מספיק עבור הנתונים. בדקו את שלושת אלה לפני שתתכננו משהו, כי כל אחד מהם משנה את התשובה.
שלושה תנאים שמכריעים את התכנון
התנאי הראשון הוא מרחב הכתובות. אם שתי רשתות ה-LAN משתמשות באותו בלוק RFC 1918, הניתוב אינו יכול להבדיל ביניהן והתרגום נעשה בלתי נמנע ולא רשות. השני הוא נתיב חזור: נתיב מ-A ל-B חסר תועלת אלא אם B יודע גם כיצד להגיע ל-LAN של A, וידע א-סימטרי הוא הסיבה הנפוצה ביותר לכך שתכנון מנותב מפיל תשובות בשקט.
השלישי הוא אמון. ניתוב מעביר מנות; הוא אינו מגן עליהן. קטע מעבר פרטי בתוך בניין אחד הוא עניין אחר מאשר מסירה לספק או קישור שחוצה עמוד שדרה משותף של קמפוס. אם הקטע אינו מהימן, התשובה היא מנהרה בין שתי חומות האש, ותוכנית הניתוב שלהלן עדיין חלה בתוכה.
רק כאשר כל השלושה מצביעים לאותו כיוון התכנון הפשוט מנצח. כאשר אחד מהם נכשל, תקנו את התנאי הזה במפורש במקום לטשטש אותו בתרגום, כי NAT מסתיר את הכשל במקום לפתור אותו.
בנו את תוכנית הנתיבים על רשת המעבר
תנו לכל חומת אש כתובת בקטע המשותף, ואז הוסיפו נתיב אחד ספציפי לכל LAN מרוחק. דבר אחר בהגדרה הקיימת אינו צריך לזוז, ובמיוחד נתיב ברירת המחדל לאינטרנט חייב להישאר בדיוק במקומו. החלפת נתיב ברירת מחדל בחומת האש העמית תשלח כל יעד לא קשור דרך המעבר, וזה שינוי גדול בהרבה מזה שמתבקש. התיעוד של pfSense לניתוב סטטי מתאר את אותו מודל של נתיב פלוס שער עבור אותה פלטפורמה, והבקרה המקבילה קיימת בכל חומת אש שאתם מפעילים בפועל.
| Firewall | Remote LAN | Next hop on the transit |
|---|---|---|
| A | 10.40.0.0/24 | 192.0.2.20 |
| B | 10.30.0.0/24 | 192.0.2.10 |
חומת אש A משרתת 10.30.0.0/24 וחומת אש B משרתת 10.40.0.0/24, ושתי כתובות המעבר נמצאות ב-192.0.2.0/24. כל מארח LAN שומר על חומת האש המקומית שלו כשער, כך שהמצב החדש היחיד הוא נתיב אחד בכל צד. בחומת אש מבוססת Linux אותה תוכנית נראית כך, וחייבים להפעיל העברה, אחרת הנתיב ייפתר והמנה תיפול.
sysctl -w net.ipv4.ip_forward=1 ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1 ip route get 10.40.0.15 traceroute -n 10.40.0.15
הפרידו בין סינון לתרגום
ניתוב ומדיניות הם בקרות שונות, ובשנייה רוב התכנונים המנותבים נכשלים באמת. אפשרו את המקורות, היעדים והשירותים הספציפיים בגבול הכניסה שהמנות עוברות בו בפועל, וזכרו שתווית ממשק כמו WAN היא שם ולא הצהרה על אמון. ייתכן שפורט מעבר שנושא תעבורה פרטית עדיין כולל חסימת כתובות פרטיות כברירת מחדל.
לאחר מכן הסתכלו על תרגום יוצא לפני שאתם מסיקים שאין NAT. כללים יוצאים אוטומטיים יכולים לשכתב תעבורה שמעולם לא נועדה לתרגום, וזה הורס את כתובות המקור שהצד השני זקוק להן עבור המדיניות והלוגים שלו. ודאו שהזרימות הנבחרות שומרות על כתובותיהן המקוריות, והניחו לכללי תרגום האינטרנט בשקט עבור התעבורה שעדיין זקוקה להם.
iptables -t nat -S POSTROUTING iptables -t nat -L POSTROUTING -n -v tcpdump -ni eth1 -c 5 host 10.40.0.15
כאשר NAT הוא התשובה הכנה
תרגום זוכה למקומו כאשר טווחי הכתובות אכן חופפים ואין אפשרות למספור מחדש, או כאשר מדיניות דורשת שצד אחד יראה כתובת אחת ולא תת-רשת. במקרים כאלה מיפוי מכוון אחד-לאחד או מוגבל לפורטים הוא החלטת תכנון עם השלכות ידועות, ולא עקיפה.
ההשלכה שיש לומר בקול היא שהצד השני אינו יכול עוד לראות או לסנן מקורות בודדים. הלוגים קורסים לכתובת המתרגמת, מדיניות לכל מארח מפסיקה לעבוד, ופתרון תקלות הופך למרדף אחרי איזה מארח פנימי החזיק בזרימה ברגע נתון. אם שום דבר מזה לא חשוב לתעבורה המדוברת, NAT בסדר.
כאשר המעבר עצמו הוא ההנחה השגויה
אם הקטע המשותף חוצה ספק, מרקם מיתוג משותף או כל נתיב שבו צד אחר יכול לקרוא את התעבורה, ניתוב לבדו אינו תשובה שלמה. מנהרה בין שתי חומות האש נותנת לכם סודיות ואימות עמית, וטבלת הניתוב שבתוכה היא אותה טבלה שהייתם כותבים על המעבר.
החליטו זאת מתוך שאלת האמון בסעיף הראשון, לא מתוך הרגל ש-VPN בטוח יותר. מנהרה מעל קטע שכבר פרטי מוסיפה עלות תפעולית ועוד אופן כשל בלי שום רווח, בעוד ניתוב מעל קטע לא מהימן מחליף סודיות בפשטות שאין לכם אפשרות להרשות. כתבו איזה משלושת התנאים הנחה את הבחירה, והמהנדס הבא לא יצטרך לדון בה מחדש.