מנוע OpenVPN או Tunnelblick: למי שייכת הפעלת ה-VPN ב-Mac?

Homebrew מתקין תוכנית OpenVPN; Tunnelblick מתקין מנהל שמריץ מנוע אחד או יותר. אלה שכבות שונות, והשאלה המועילה אינה אם אתם אוהבים להשתמש בטרמינל. היא למי שייכים התצורה, שינויי ה-DNS, בקשת האישורים והניקוי בסוף ההפעלה. בעלים אחד לשכבות האלה הוא מה שהופך את ההגדרה לצפויה.

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

בדיקה ראשונה: איזה קובץ בינארי של OpenVPN באמת רץ

הריצו pgrep -fl openvpn כשאתם מחוברים וקראו את שורת הפקודה המלאה. הנתיב הראשון הוא המנוע שבאמת רץ. ב-Apple Silicon התקנת Homebrew נמצאת בדרך כלל תחת /opt/homebrew, בעוד שמחשבי Mac עם Intel משתמשים ב-/usr/local, ו-Tunnelblick מריץ מנוע מתוך חבילת האפליקציה שלו.

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

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

בדיקה שנייה: מי משנה DNS ומסלולים

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

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

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

בדיקה שלישית: מאיפה מגיעים האישורים

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

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

בדיקה רביעית: מי מפעיל, מפקח ועוצר את התהליך

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

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

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

בדיקה חמישית: איך מאמתים את ההעברה

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

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

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

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