הגשת OpenVPN דרך TCP ו-UDP ממארח אחד
תהליך אחד מקבע תחבורה אחת לפני 2.7. השוו זוג TAP מגושר, שתי תתי-רשת TUN ומאגר משותף, ואז התאימו כל פרופיל למאזין שלו.
רשתות שמתירות רק TCP 443 מתקיימות לצד רשתות שמעבירות UDP בשמחה, ושרת אחד צריך לשרת את שתיהן. פרופיל עם proto udp עונה לקבוצה השנייה ונכשל בראשונה, ועריכת אותה תצורה כדי לומר proto tcp אינה יוצרת מאזין שני. ההוראה בוחרת תחבורה אחת לתהליך אחד. כל השאר נובע מהמגבלה הזו.
או שאתם מריצים יותר מתהליך אחד, או שאתם מריצים גרסה שיכולה לקבע כמה sockets בבת אחת.
תהליך אחד מקבע תחבורה אחת לפני 2.7
OpenVPN הקהילתי מקבע את ה-socket ש-proto מתאר, וההוראה הזו בוחרת תחבורה בודדת עבור המופע. TCP ו-UDP הם מחסניות נפרדות, ולכן אותו מספר פורט יכול להיות תפוס על ידי שניהם באותו זמן, אבל לא על ידי תהליך אחד. לכן קו 2.6 נותן לכם תחבורה אחת לכל daemon. OpenVPN 2.7 הסיר את המגבלה הזו עבור שרתים, שיכולים לקבע כמה sockets דרך כמה הצהרות --local בתהליך אחד.
בדקו את הגרסה לפני שמתכננים סביב כל אחת מהתשובות, כי סידור 2.7 הוא מודל תפעולי אחר עם תחביר תצורה משלו. מדריך שנכתב עבור 2.6 מתאר שני תהליכים גם כשהוא לא אומר זאת.
שלוש דרכים להריץ שני מופעים
עם ממשקי TAP, הריצו מופע אחד לכל תחבורה וגשרו את שני התקני ה-tap במארח. שתי קבוצות הלקוחות מגיעות לאותו תחום שידור, מה שמאפשר למאגר כתובות אחד לכסות אותן ושומר על פרוטוקולים התלויים בשידור. עם TUN, גישור אינו זמין, ולכן הפיצול הפשוט ביותר נותן לכל מופע תת-רשת משלו ומשאיר לניתוב להפריד בין שתי קבוצות הלקוחות. אפשרות שלישית שומרת על מאגר אחד בכך שכל מופע קורא לסקריפט learn-address שמתקין מסלול /32 עבור הלקוח דרך ההתקן של אותו מופע.
הסידור השלישי הזה הוא זה שאנשים מבקשים וזה שדורש את מרב הזהירות, כי הסקריפט הופך לחלק מנתיב הנתונים וחייב לטפל נכון באירועי הוספה, עדכון ומחיקה.
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
הפרידו בין שני המופעים
כל מופע צריך גם פורט או כתובת נפרדים, קובץ מצב נפרד ויעד לוג נפרד. שני daemons שמוסיפים לאותו קובץ מצב מייצרים פלט שלא ניתן לקרוא בזמן תקלה, וזה בדיוק הרגע שבו אתם צריכים אותו. אם מופע שני מקבע כתובת מסוימת, הכתובת הזו חייבת להתקיים במארח כשהתהליך עולה; אחרת הוא יוצא בכשל קיבוע לפני שהוא אומר משהו על מפתחות.
תנו שמות ליחידות ולפרופילים כך שהתחבורה תהיה ברורה משם הקובץ. המפעיל הבא לא אמור לפתוח תצורה כדי לדעת איזו היא TCP.
התאימו את הפרופיל למאזין
שרת שמריץ proto tcp מצפה לפרופיל לקוח עם proto tcp-client, ופרופיל שעדיין נושא proto udp מול אותו מאזין מגיע לפסק זמן בלי שגיאה שהמשתמש יכול לפעול לפיה. שמרו שני פרופילים אם הפריסה מציעה את שתי התחבורות, ותייגו אותם כך שהתמיכה תדע איזו נוסתה. מספר הפורט לבדו אינו מתאר את התחבורה.
כללי חומת אש פועלים לפי אותו פיצול: כלל ל-UDP 1194 אינו אומר דבר על TCP 1194, וכלל לכתובת אחת אינו מכסה את המאזין האחר.
קראו קודם את התמונה של השרת
התחילו עם ss -lntup בשרת ואשרו שמופיעים גם מאזין TCP וגם מאזין UDP. אחר כך חברו לקוח אחד מכל סוג ובדקו את פלט המצב לשני רשומות עם כתובות נפרדות. אם ה-sockets קיימים ואף לקוח לא מגיע, הנתיב או חומת האש דוחים מנות לפני שה-daemon רואה אותן.
socket שלעולם לא מופיע הוא בעיית תצורה או קיבוע, ו-socket שמופיע אך לעולם אינו רושם חיבור הוא בעיית סינון. השניים נראים זהים מהלקוח, ולכן התמונה של השרת עצמו באה ראשונה. זכרו ש-TCP נושא חסימת ראש תור, ולכן הצעתו היא אמצעי נגישות ולא שדרוג ללקוחות עם נתיב UDP נקי.