מסכור או ניתוב מדיניות: תעבורת LAN דרך שער VPN

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

שני התכנונים מבטיחים דברים שונים

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

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

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

מסכור: עמית אחד בצד הרחוק

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

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

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

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

ניתוב מדיניות: שמור על המקור, הוסף מסלול חזרה

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

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

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

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

החלט לפי בעלות ולפי מה שהצד הרחוק מתעד

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

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

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

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

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

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

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