שרת TAP אחד או כמה? לקוחות OpenVPN על גשר

כמה לקוחות TAP אינם דורשים תהליך שרת אחד, יציאת UDP אחת והתקן TAP אחד במארח לכל אחד. שרת OpenVPN אחד במצב Ethernet יכול לקבל לקוחות מאומתים רבים ולחבר אותם לגשר יחיד, וזו הדרך המתועדת להרחיב מקטע של שכבה 2. תכנון התהליך היחיד הוא זה שהמדריך מתעד, והוא בדרך כלל ברירת המחדל הנכונה.

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

שתי ארכיטקטורות, לא שתי הגדרות

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

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

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

מה עושה עוזר server-bridge

העוזר server-bridge מגדיר את מצב Ethernet לריבוי לקוחות. צורת מאגר הכתובות שלו מקבלת את השער, את מסכת הרשת ואת טווח ייעודי בתוך תת-הרשת המגושרת, למשל שער ב-192.168.50.1 עם מאגר מ-192.168.50.160 עד 192.168.50.199.

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

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

בידוד אינו נובע ממספר התהליכים

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

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

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

מתי כמה תהליכים עדיין נכונים

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

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

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

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