שתי כתובות שירות בלקוח OpenVPN אחד: iroute ו-lo

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

הכינוי מקומי, הבעלות מרוחקת

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

בלקוח הכתובת שייכת למארח, ו-loopback הוא הבית הטבעי לזהות שירות שלעולם לא אמורה להופיע על קישור פיזי. ב-hub מיפוי העמית לתחילית הוא הצהרה נפרדת שרק השרת קורא. אף אחת משתי הרשומות לא מחייבת את השנייה.

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

הוסף את הכתובת בלקוח באופן קבוע

מקם את כתובת השירות על loopback עם תחילית מארח, כך שהמארח יתייחס אליה כקלט מקומי ולא כתת-רשת שיש להגיע אליה. ip address add 10.66.0.10/32 dev lo עושה זאת עבור כתובת אחת, וחזרה על הפקודה עבור כתובת שנייה מדגימה שני שירותים.

הרץ זאת כבדיקה חד-פעמית, ואז העבר אותה למה שמחזיק בתצורת הרשת של המארח, כי תוספת בזמן ריצה נעלמת באתחול ועותקים מצטברים בין התחברויות מחדש. יחידת systemd המסודרת אחרי הרשת היא אפשרות אחת, ומנהל הרשת של ההפצה הוא אפשרות אחרת. בכל בחירה שתבחר, הכתובת חייבת להתקיים לפני שהיישום נכרך, אחרת השירות עולה על השקע הלא נכון. אמת עם ip address show dev lo לאחר אתחול ולא לאחר הפקודה הידנית.

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

תבע אותה בקובץ ה-CCD שה-hub באמת קורא

בשרת, הצהרת הבעלות נכנסת לקובץ של כל לקוח שנבחר לפי השם המשותף המאומת, בתוך הספרייה שנקראת בשם client-config-dir. השורה היא iroute 10.66.0.10 255.255.255.255, אחת לכל כתובת, והיא אומרת לשרת איזה עמית אמור לקבל תעבורה ליעד הזה.

שני פרטים שוברים זאת בשקט. שם הקובץ חייב להתאים לשם שהשרת באמת משתמש בו, והוא שונה כאשר username-as-common-name משחק. ו-iroute נכנס לתוקף רק במצב TUN עם ספריית תצורת לקוח מוגדרת, כך שאותה שורה לא עושה דבר בפריסה מגושרת. הוסף שורות לקובץ הקיים במקום להחליף אותו, כי ייתכן שהוא כבר נושא כתובת קבועה או אפשרויות push. המסמך של OpenVPN 2.6 מתעד גם את הספרייה וגם את הנחיית הבעלות.

גם הליבה של ה-hub עצמו צריכה נתיב ליעדים האלה כדי שתעבורה שנוצרת מקומית תיכנס לתהליך המנהרה. route 10.66.0.10 255.255.255.255 בתצורת השרת מכסה תעבורה שהשרת יוצר, בעוד שלקוחות אחרים צריכים push "route 10.66.0.10 255.255.255.255" כדי ללמוד את היעד בעצמם.

ניתוב והרשאה נשארים נפרדים. נתיב שנדחף אומר ללקוח לאן לשלוח מנות ולא מעניק דבר; השירות עדיין חייב לקבל את הקורא בתנאים שלו.

בדוק את מדיניות הקלט ואת נתיב התשובה

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

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

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

בדוק כתובות ובעלות בנפרד

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

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