מרכז OpenVPN אחד, שלושה LAN: תוכנית כתובות וקובצי iroute

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

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

התחילו בתוכנית שאיש לא צריך לנחש

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

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

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

אמרו לליבה של המרכז היכן הסניפים

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

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

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

תנו לכל סניף את המסלולים שהוא צריך

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

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

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

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

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

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

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

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