שרת או לקוח: איזו יחידת OpenVPN על Pi בעל תפקיד כפול

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

התאימו את שם היחידה לתיקייה שהיא טוענת

Upstream 2.6 מספק שתי יחידות תבנית, [email protected] ו[email protected]. תבנית השרת מתחילה ב-/etc/openvpn/server וטוענת משם את %i.conf. תבנית הלקוח מתחילה ב-/etc/openvpn/client. מופע בשם roaming יכול להתקיים בשני המקומות בעת ובעונה אחת, כשרת וכלקוח, עם שתי תצורות לא קשורות ובלי שום חיבור ביניהן מלבד המחרוזת.

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

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

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

הכריעו לפי כיוון החבילות, לא לפי שם הממשק

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

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

הסתכלו בסוקטים לפני שאתם מתיארים. שרת שקושר ל-udp/1194 מציג סוקט האזנה. הלקוח מציג שיוך לכתובת הספק וכלום שמאזין.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

מסלול ברירת המחדל של מופע אחד יכול לתפוס את התשובות של האחר

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

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

בחנו את ההחלטה המקומית ולא את מצב המנהרה, כי הליבה בוחרת את המקור והממשק לפני ש-OpenVPN רואה את החבילה.

ip route get 203.0.113.44
ip rule show

הפעילו מחדש תפקיד אחד והוכיחו שהאחר שרד

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

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

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

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