כמה remote של OpenVPN: רשימת failover, לא איחוד קישורים

שתי שורות remote בפרופיל אחד נראות כמו נתיב שני; הן ניסיון שני. כשהנקודה הראשונה מפסיקה לענות, הלקוח ממשיך הלאה והסשן לא נעשה רחב יותר. קראו לרשימה failover מוקדם, אחרת תכווננו את הכפתור הלא נכון.

מה רשימת remote נותנת לכם

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

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

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

בלוקים ששומרים הגדרות עם נקודה אחת

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

כל מה שמחוץ לבלוק משמש כברירת מחדל לרשומות שלא דורסות אותו. לכן בלוק בנוי אחד וארבעה remote רגילים מתנהגים בדרכים שרשימת הכתובות לא יכולה להסביר.

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

סדר ניסיונות חוזרים ומחיר remote-random

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

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

ערבוב מפעילים שובר את הצהרת האמון

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

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

בדקו כל רשומה במקום להניח

לאחר עדכון פרופיל מאושר, התחברו בכוונה לכל נקודה נדרשת ואשרו איזו תעבורה עלתה. ריצה מפורטת הופכת זאת לגלוי. הפעילו openvpn --config office.ovpn --verb 4 וקראו את שורת הקישור לכתובת שציפיתם לה. אחר כך בדקו את המשאבים מאחורי המנהרה; רשומה יכולה להשלים את לחיצת היד ובכל זאת לא לנתב אתכם לשום מקום.

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

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