לקוחות במורד הזרם מאחורי VPN במעלה הזרם: נתב או NAT?

שער אחד מריץ WireGuard עבור המכשירים שלך ולקוח OpenVPN אל הרשת של מישהו אחר. העברה בין שתי הממשקים הפנימיים עובדת, וקל להסיק שתת־הרשת במורד הזרם היא כעת חלק משירות מעלה הזרם. היא לא. נתיב שהלקוח מושך אומר לשער שלך לאן לשלוח בקשות; הוא לא אומר דבר על איך הרשת המרוחקת מחזירה תעבורה למכשירים שמעולם לא שמעה עליהם. בחר מודל החזרה שהמעלה באמת תומך בו לפני שתוסיף ולו כלל אחד.

החלט על מודל ההחזרה לפני שאתה נוגע בניתוב

בסיור הזה הלקוחות במורד הזרם משתמשים ב־10.90.0.0/24, כתובת המנהרה במעלה שהוקצתה לשער היא 10.80.0.6, והמשאב המרוחק המאושר הוא 172.20.0.30. שני מודלים מתאימים לצורה הזו: לשמר את המקור במורד ולדאות שהצד המרוחק מנתב אותו, או לתרגם את המקור לכתובת המנהרה של השער עצמו. כל מה שאחרי ההחלטה הזו הוא מכני, וההחלטה עצמה דורשת את בעל השירות. שורה אחת למעלה היא הסכם ניתוב עם הצד המרוחק; השנייה היא שינוי מדיניות מקומי שאתה יכול לעשות לבד. הערבוב בין השתיים הוא מה שהופך שינוי של עשר דקות למשא ומתן.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

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

שימור מקור בניתוב

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

אם התשובה חיובית, התצורה המקומית קטנה: העברה מופעלת, allowed-ips של peer ה־WireGuard שמכסים את טווח המורד, ומדיניות חומת אש שמתירה את החציה בשני הכיוונים.

תרגום מקור מכוון

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

IPv6 צריך תכנון משלו; העתקת שורת masquerade של IPv4 אינה ארכיטקטורה. בדוק את הנתיב המתורגם בחיבור חדש ולא בחיבור שמור במטמון.

נתיב הנתונים המקומי עדיין חייב לעבוד

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

בדוק ממכשיר מורד אמיתי, לא מהשער. כתובת המקור היא כל מטרת התרגיל.

מקור אחד פירושו זהות הפעלה אחת

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

כתוב את האישור הזה ב־runbook ליד הכלל, כי הסוקר הבא ישאל אם התכנון אושר או רק היה נוח.

הגדר את מצב הניתוק ואז בדוק שלוש בקשות

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

תעד את החזרה לאחור בשורה אחת לכל כלל, כדי שאפשר יהיה לבטל את השינוי בלי לשחזר את הכוונה.