שרת ולקוח OpenVPN על אותו מארח: למה לקוחות נופלים

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

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

אותו מאגר, שני שרתים: מי מנצח

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

רשמו מה פעיל לפני העריכה: ip -4 addr show מציג את התקני המנהרה, ss -lunp מציג את המאזינים, ו-systemctl list-units נוקב בשמות היחידות. מבט אחד בכתובות המנהרה מכריע אם המאגרים מתנגשים.

מה פרופיל הלקוח מוסיף לטבלה

החצי של הלקוח כותב מסלולים ברגע שהוא מתחבר. redirect-gateway def1 מפצל את מסלול ברירת המחדל ל-0.0.0.0/1 ועוד 128.0.0.0/1, שניהם מנותבים דרך ההתקן החדש, יחד עם מסלול מארח לשרת המרוחק שמוצמד בכוונה לממשק הפיזי. ההצמדה הזו קיימת כדי שהמנהרה תשמור על נתיב לתעבורה של עצמה. כל השאר, כולל התגובות שהשרת המקומי חייב ללקוחות שלו עצמו, הולך כעת לפי ברירת המחדל החדשה ויוצא דרך הקישור המרוחק.

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

שלוש דרכים להפריד את התפקידים

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

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

איזה משני המופעים אשם

עצרו את מופע הלקוח ובדקו שוב את הלקוחות המקוריים. התאוששות מיידית פירושה ניתוב, לא שרת. החזירו את הלקוח ועקבו אחרי תגובה אחת עם ip route get שנמסרו לו גם כתובת מקור וגם כתובת יעד, מה שמראה את הנתיב שהקרנל היה בוחר, ואז צפו בממשק שהחבילות באמת משתמשות בו עם tcpdump -ni any port 1194. קובץ המצב של השרת, שנכתב כל כמה שניות דרך ההנחיה status, מכיל את רשימת הלקוחות המחוברים ומוני בייטים לשני הכיוונים.

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