Pi אחד, שני מופעי OpenVPN: מה כל יחידה קוראת
שני דמונים של OpenVPN על Pi אחד קוראים קובצי תצורה שונים ויוצאים דרך ווים שונים. מפו כל מופע, ואז בדקו את נתיב המטען בנפרד.
ספרו את תהליכי OpenVPN לפני שאתם נוגעים בפרופיל. Pi שמקבל משתמשים נודדים וגם מחייג לשירות במעלה הזרם מריץ שני דמונים, וכל אחד מהם קורא קובץ תצורה שנבחר לפי שם המופע שהקלדתם. לאחר מכן התבניות הארוזות נותנות לכל דמון את ספריית העבודה שלו, את קובץ המצב שלו בזמן ריצה ואת התקן המנהרה שלו. אם תטעו בפיצול הזה, תבזבזו ערב שלם על שינוי הגדרה נכונה בקובץ שהתהליך הרץ לעולם אינו פותח.
כל שם מופע בוחר את הקובץ שלו
בקובצי היחידה המסופקים עם OpenVPN 2.6, ארגומנטי ההתחלה נושאים מציין מקום למופע שמתמלא מהטקסט שאחרי הסימן @. תבנית השרת רצה מספריית התצורה של השרת ומפענחת את הארגומנט שלה מול %i.conf שם, בעוד תבנית הלקוח עושה את אותו הדבר מספריית הלקוח. לכן [email protected] קורא admits.conf בספריית השרת ו [email protected] קורא uplink.conf בספריית הלקוח, ולאף אחד מהשמות אין משמעות בספרייה האחרת.
אמתו את המיפוי במכונה במקום להניח שהחבילה שמרה על ברירות המחדל של מעלה הזרם. תוסף הפצה רשאי להחליף את ספריית העבודה או את ארגומנט התצורה ישירות.
systemctl cat [email protected]
systemctl cat [email protected]קראו את השורה WorkingDirectory ואת ארגומנט התצורה בפלט הזה, כי היחידה המופעלת היא הדבר היחיד שקובע איזה קובץ נטען. תוסף שמוסיף --config אל ExecStart גובר על התבנית גם כשנתיב התבנית נראה נכון. בקשו את נתיבי השבר והתוסף כשאתם רוצים לדעת אם יש עקיפה מקומית. אם שני התפקידים מתפענחים לקובץ אחד, יש לכם תהליך יחיד שמנסה להיות גם שרת וגם לקוח, והאפשרות המאוחרת באותו קובץ מנצחת בשקט.
תחבורה מקומית ומטען מועבר פוגעים בווים שונים
החיבור המוצפן של השרת לכל משתמש נודד נוצר על ה-Pi עצמו, ולכן התשובות החיצוניות שלו יוצאות דרך וו הפלט המקומי. החיבור של הלקוח לעמית במעלה הזרם הוא גם פלט שנוצר מקומית, אף שהוא מגיע לרשת מרוחקת. מטען מועבר הוא קטגוריה שלישית, והקרנל מתאים אותו רק אחרי שכבר בחר התקן יציאה לחבילה.
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
כלל שמתאים ממשק יציאה בתוך שרשרת העברה יכול לאשר או להשליך חבילה שהניתוב כבר הקצה לממשק הזה, אבל הוא לעולם לא בוחר את הממשק. כאשר מארח אחד מסיים מנהרה אחת ופותח אחרת, המדיניות ששולחת מטען משתמש למנהרת מעלה הזרם והמדיניות שמגנה על התשובות המוצפנות של ה-Pi עצמו הן החלטות נפרדות. הן נוחתות במקרה על אותה כרטיס רשת פיזי, ולכן מבלבלים ביניהן.
ההבחנה הזו מסבירה כשל-חצי נפוץ. משתמשים מתחברים, לחיצת היד מסתיימת, והתעבורה שלהם עדיין יוצאת בדרך הלא נכונה, כי לחיצת היד הייתה מקומית והמטען הועבר ורק אחד מהשניים נבדק אי פעם.
נתיב מיובא יכול לבלוע תשובות למשתמשים שלכם
הגדרת האבטחה של פרופיל הלקוח קובעת מה מעלה הזרם רשאי לדחוף לטבלת הניתוב של ה-Pi, והפניה רחבה היא האפשרות שהופכת מארח כפול-תפקיד עובד למארח שבור. אם הנתיב הנדחק מכסה את הכתובות הציבוריות של משתמשים נודדים, התשובות שהשרת יוצר אליהם יכולות ללכת אחרי הנתיב החדש אל מנהרת מעלה הזרם במקום לצאת דרך שכבת הבסיס. אנשים לעתים קרובות מאשרים שהמנהרה לספק עדיין עובדת ועוצרים שם, כי התעבורה הזו היא התחבורה של המנהרה עצמה והיא ממשיכה לזרום בזמן שכל השאר מתנהג לא נכון.
מדיניות מבוססת מקור או סימון היא הדרך שבה שני הזרמים נשארים נפרדים. אפשרות הסימון של לינוקס ב-OpenVPN מסמנת את החבילות המוצפנות של הדמון עצמו בסימון חומת אש, שכלל ניתוב יכול לשלוח אז לטבלה ייעודית. כתובות מקור עובדות באותה מידה כאשר התשובות החיצוניות של השרת תמיד יוצאות מכתובת בסיס אחת. כל אחת משתי הגישות זקוקה לנתיבים תקפים בטבלה שהיא בוחרת ולחריג עבור נקודת הקצה של הספק, אחרת המנהרה עצמה מפסיקה לעלות.
שאלו את הקרנל איזה נתיב תשובה באמת תיקח לפני שתכתבו כלל כלשהו. הכתובות שלהלן הן מצייני מקום לכתובת בסיס של Pi ולכתובת ציבורית של משתמש נודד אחד.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10אמתו את הפיצול, ואז עצרו תפקיד אחד בכל פעם
בדקו שלושה זרמים בנפרד, כי לחיצת יד עובדת לא מוכיחה דבר על השניים האחרים. קבלו חיבור נכנס חדש, שלחו יישום אחד מורשה דרך יציאת מעלה הזרם, ואשרו ששני התהליכים עדיין מגיעים לעמיתים שלהם.
אחר כך עצרו את תפקיד הלקוח וראו מה תפקיד השרת שומר. זו הדרך הזולה ביותר למצוא כלל נתיב או סימון שנועד למופע אחד והוחל על שניהם.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerמה שאתם רוצים לראות הוא המאזין עדיין קשור, התקן המנהרה עדיין קיים והיומן נקי משגיאות חדשות בזמן שתפקיד הלקוח מושבת. אם עצירת הלקוח גם מנתקת את תשובות השרת למשתמשים קיימים, שני התפקידים חולקים משהו שהיה צריך להיות מוגבל לאחד מהם. תעדו איזה מופע, איזה קובץ תצורה ואיזה בעל זרם נגע בכל שינוי, כי האדם הבא שינפה את המארח הזה יחזור אחרת על אותה תגלית מאפס.