לנתב לקוחות OpenVPN דרך Cloudflare? בדקו קודם את התפקיד
לקוח של התקן אינו נתב. ודאו שתפקיד Cloudflare מעביר מנות של מארחים אחרים, ואז השאירו את המנהרה של השרת עצמו בנתיב הישן שלה.
יש לכם שרת OpenVPN עובד ומארח שמריץ גם את תוכנת ההתקן של Cloudflare, והשלב הבא המובן מאליו נראה כמו הפניית תעבורת הלקוחות אליו. שני חיבורים עובדים על מכונה אחת אינם מצטרפים לשער מעבר. מה שחסר הוא תפקיד מתועד להעברת מנות ששייכות למישהו אחר, ומדיניות שמסווגת את המנות האלה כשהן מגיעות.
לפני כל כלל באות ארבע שאלות: איזו תעבורה נכנסת, לאן היא הולכת אחר כך, איך התשובות מוצאות את הדרך חזרה, ומה עושה התכנון כשהנתיב השני הזה נכשל. השתיים הראשונות הן שאלות יכולת.
שני שירותים על מארח אחד אינם נתיב מעבר
לקוח של התקן בנוי לטפל בתעבורה שמקורה במכונה שבה הוא פועל. הוא מיירט את פתרון השמות, או תעבורת יישומים נבחרת, ושולח אותה דרך המנהרה שלו, והמדיניות שלו כתובה עבור המשתמש של ההתקן הזה והתהליכים שלו. מנה שמועברת מלקוח OpenVPN אינה פלט מקומי, ולכן אותם כללים אינם מסווגים אותה. זה אינו פרט תצורה שאפשר לכסות בכלל רחב יותר, מפני שהוא קובע אם התוכנה רואה את המנה בכלל.
לכן שאלת התכנון היא שאלת יכולת. או שלמוצר המותקן יש תפקיד מתועד שמעביר תעבורה עבור רשתות אחרות, או ש פונקציית המעבר שייכת למקום אחר לגמרי.
איזה תפקיד של Cloudflare רשאי להעביר
לקוח ההתקן של Cloudflare מציע מצבים שנבדלים בהיקף: פתרון שמות בלבד, תעבורה מההתקן, ולפעמים שניהם. אף אחד מהמצבים האלה אינו הופך את המארח לנתב עבור טווח פרטי שמגיע דרך מנהרה אחרת. תפקיד הניתוב הייעודי הוא מוצר נפרד עם המחבר, הרישום ומודל הרשת שלו.
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
בדקו את התפקיד המותקן לפני שמתכננים נתיבים סביבו. קראו איזה ממשק המחבר יוצר, אם הוא מכריז על קידומות מסוימות או על נתיב ברירת מחדל, ואם המדיניות המקומית חלה גם על מנות מועברות ולא רק על מקומיות. אם מטפלים רק בתעבורה מקומית, השרת של OpenVPN אינו יכול להיות נקודת המעבר, לא משנה איך נכתבה כלל התרגום.
כאן גם צריך לנסח במדויק דרישה ליציאה ציבורית. יציאה שמספקת Cloudflare עבור תעבורת לקוחות מועברת היא מקרה שימוש מסוים, וצריך לאשר אותה מול השירות שבאמת יש לכם.
השאירו את המנהרה החיצונית בלתי תלויה בנתיב החדש
ברגע שמוסיפים נתיב ברירת מחדל אל הממשק החדש, התעבורה היוצאת של השרת עצמו מתחילה להתחרות עליו, וזה כולל תשובות ללקוחות OpenVPN ואת הפעלת ה-SSH שלכם אל המכונה. התסמין הרגיל הוא מנהרה שמתבססת ואז מתה, או מנהל שננעל בחוץ בזמן שהשינוי נראה כאילו עבד. השוו את ip route get עבור נקודת הקצה לפני ואחרי, והשתמשו בניתוב לפי מדיניות או בנתיב מארח כדי להשאיר את התעבורה של השרת עצמו במקום שבו הייתה. הריצו את ההשוואה מהמכונה עצמה, כי ההשקפה של השרת על הנתיב שלו היא זו שקובעת.
חריגה עבור הכתובת הציבורית של השרת אינה מספיקה בפני עצמה, כי נתיב החזרה של כל מנהל מרוחק הוא זרימה אחרת. החליטו אילו מהזרימות האלה חייבות לשרוד את השינוי, ואז אמתו כל אחת במקום להניח שהראשונה מכסה את השאר.
הגבילו את ההעברה והתרגום לזרימה אחת
מנות שמתקבלות עוקבות אחר נתיב ההעברה, לא אחר נתיב הפלט המקומי, ולכן הכלל שקובע חי בקרס forward. כשהממשק הבא זקוק לתרגום, הגבילו את המקור למאגר הלקוחות, את היעד למותר ואת היציאה לאותו ממשק יחיד. כלל masquerade שמקושר רק לממשק אינו בוחר נתיב בעצמו ואינו מתיר העברה מעבר לשום מסנן אחר.
החליטו מראש על התנהגות הסגירה בעת כשל, ואז בדקו אותה. עצרו את הנתיב הבא ואשרו שהלקוחות מאבדים את היציאה המיועדת במקום ליפול בשקט חזרה לקישור העולה הרגיל, כי זו התוצאה שאיש לא שם לב אליה עד שהתעבורה יוצאת מהדלת הלא נכונה. חזרו על הבדיקה עבור פתרון שמות ועבור IPv6, כי מערך כללים ל-v4 בלבד משאיר נתיב v6 פתוח.
רשמו את ארבע התשובות שבהן בחרתם ואת התצפית שמוכיחה כל אחת מהן. נתיב מעבר שאתם יכולים לתאר הוא כזה שתוכלו להגן עליו בסקירת התקלות הבאה.