קידומת ציבורית דרך OpenVPN: תיקון נתיב החזרה

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

הקידומת חייבת קודם להיות מנותבת אליכם

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

אם הספק מנתב את 198.51.100.64/28 לשרת הכניסה שלכם, מנותבים החבילות של הטווח הזה מגיעות לשרת ונעצרות שם אלא אם תעבירו אותן הלאה. אם הספק במקום זאת מגשר על הטווח ל-uplink שלכם, השרת חייב להשיב ב-ARP עבורו, וזו בעיה אחרת.

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

שתי שכבות ניתוב: נתיב הליבה ו-iroute

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

הנתיב בצד השרת נראה כך, כאשר הקידומת והמסכה חייבות להתאים להקצאה:

ip route add 198.51.100.64/28 dev tun0

התצורה הספציפית ללקוח מקצה בעלות. שימו אותה בקובץ ה-CCD הנקרא על שם השם הנפוץ של תעודת הלקוח, וודאו שהספרייה הזו היא זו שהשרת באמת קורא:

iroute 198.51.100.64 255.255.255.240

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

היכן חיה כתובת השירות

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

בלקוח Linux שמסיים את השירות מקומית, די בכתובת מארח בודדת:

ip address add 198.51.100.70/32 dev lo

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

שמרו על המקור הציבורי בנתיב החזרה

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

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

iptables -t nat -S POSTROUTING

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

בדקו את שני הכיוונים לפני שאתם בוטחים בזה

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

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

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

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

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

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