האם לקוחות בשני שרתי OpenVPN יכולים להגיע זה לזה?

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

המיתוס: רשימת חשבונות אחת, רשת אחת

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

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

תנו לכל שער קבוצה משלו וכתובת מעבר

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

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

התקינו את הנתיב בשני הצדדים

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

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

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

דחפו את נתיב הלקוח בלי לזייף בעלות

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

push "route 10.64.20.0 255.255.255.0"

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

הוכיחו בקשה אחת וסרבו לאחרת

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

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

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

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