האם לקוח WireGuard אינו מצליח להגיע ללקוח OpenVPN?

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

לתסמין חסר חלק אחד בכל פעם

התכנון הזה משתמש במאגר WireGuard של 10.71.0.0/24 על wg1 ובמאגר OpenVPN של 10.72.0.0/24 על tun1, ושניהם מסתיימים בשער אחד. הבקשה הנבדקת עוברת מ-10.71.0.5 אל HTTPS על 10.72.0.30. כל שלב למטה עוסק באותו זרם אחד. לכל בדיקה חתימת כשל אחרת אף שהמשתמש חווה אותן באופן זהה, ובדרך כלל חסר רק אחד מהשלושה בכל פעם.

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

הרחיבו את כיסוי היעד של הזרוע

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

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

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

שמרו על הבעלות על המקור בשער

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

AllowedIPs = 10.71.0.5/32

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

תנו לצד OpenVPN נתיב חזרה

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

push "route 10.71.0.0 255.255.255.0"

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

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

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

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

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

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