שרת VPN על Raspberry Pi: מתחילים מהאפליקציה בטלפון, לא מהמתכון

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

הסדר שחוסך את הבנייה מחדש

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

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

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

מה האפליקציה בטלפון מיישמת בפועל

רשימת לקוחות שפורסמה מתארת יישום, לא שירות. אפליקציית OpenVPN Connect ל-Android מצפה לשרת OpenVPN; היא אינה מספקת את צד השרת. היא גם אינה הופכת ללקוח IPsec או L2TP כשפרופיל נראה דומה.

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

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

ההסכם בן ארבעת החלקים

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

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

לפרטי הגישה יש תפקידים נפרדים

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

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

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

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

הנגישות היא חוזה נפרד

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

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

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