אזורי Shorewall לשני נתיבי החבילות של OpenVPN
הפרידו בין תעבורת OpenVPN המוצפנת לתעבורת הלקוח המפוענחת, תנו למנהרה אזור משלה והתירו רק את השירות האחד שהלקוח צריך.
שני זרמי חבילות חוצים שער Shorewall שמסיים OpenVPN, ורק אחד מהם מוצפן. הראשון הוא התעבורה של הלקוח אל מאזין ה-VPN בממשק הפונה לאינטרנט. השני הוא הבקשה המפוענחת שיוצאת מממשק המנהרה אל שרת משרד או שירות בשער. שרטטו את שניהם לפני עריכת המדיניות, כי כלל שמספק את הראשון אינו עושה דבר עבור השני.
שרטטו את שני הזרמים לפני עריכת המדיניות
כתבו את הזרמים כשורות עם מקור, יעד, פרוטוקול ופורט. בנתיב החיצוני המקור הוא הכתובת הציבורית של הלקוח והיעד הוא פורט המאזין של השער; Shorewall מתייחס לכך כתעבורה מהאינטרנט אל חומת האש. בנתיב הפנימי המקור הוא טווח כתובות המנהרה והיעד הוא השירות המאושר. לשתי השורות בעלים שונים גם כאשר מנהל אחד מתחזק את שתיהן.
| Flow | Zone relationship | What to constrain |
|---|---|---|
| Encrypted OpenVPN transport | Internet to the firewall host | The listener's actual protocol and port |
| Decrypted request to a LAN service | VPN clients to the LAN zone | One approved server and service |
| Decrypted request to the gateway | VPN clients to the firewall host | Only the local services required |
| Request to another VPN client | VPN clients to VPN clients | Denied unless deliberately required |
הוסיפו שורה רק אם הבקשה מסתיימת בשער עצמו, כגון גישה לפותר או לניהול. שירות על המארח פועל לפי מדיניות הקלט של המארח, ולא לפי הנתיב המועבר. ערבוב של השניים הוא הדרך שבה כלל מנהרה צר חושף בסופו של דבר ממשק ניהול.
הקצו את אזור המנהרה ואת היקף הממשק
אזור הנוסע מוצהר ב-/etc/shorewall/zones, ממשק המנהרה מחובר ב-/etc/shorewall/interfaces, והחיבור החיצוני מתואר ב-/etc/shorewall/tunnels. התאימו לתחביר של המהדורה המותקנת, כי סדר העמודות ושמות האפשרויות השתנו בין גרסאות ראשיות. פורט הדוגמה במדריך אינו סיבה להתיר פורט שונה מזה שהדמון באמת מאזין עליו. TCP ו-UDP אינם ניתנים להחלפה רק מפני שהמספרים תואמים.
המדריך מקבץ ממשקים עם tun+. במארח שיש בו יותר ממנהרה אחת, תו כללי זה עלול להציב VPN שני ברמת אמון אחרת באותו אזור. בחנו את ההיקף מול הממשקים שקיימים בפועל, והשאירו את השמות תחת מחזור החיים של מנהל החיבורים במקום לערוך שמות ממשקים ביד.
המדריך ההיסטורי מכיל דוגמאות תצורה של OpenVPN ישנות בהרבה, ואין להעתיק את עצות ההצפנה שלו לפריסה נוכחית. שאלו במקום זאת את מודל האזורים והזרמים. קחו את הבסיס הקריפטוגרפי ממדיניות OpenVPN המתוחזקת של השער.
התירו רק את הנתיב שסיווגתם
קבלה רחבה מאזור ה-VPN אל ה-LAN היא סקיצת פתיחה, לא מדיניות גמורה. כתבו את מקור הלקוח המורשה, את כתובת השירות בפועל, את הפרוטוקול ואת הפורט. אחר כך קראו את הכללים שמעליו ואת ברירת המחדל של האזור, כי תוספת צרה אינה מבטלת היתר רחב שכבר תואם. תעבורה אל מארח השער היא יחס נפרד מתעבורה המועברת דרכו.
תעבורה בין לקוחות דורשת החלטה משלה. client-to-client של OpenVPN ו-routeback של Shorewall שניהם משפיעים על כך שלקוחות יוכלו להגיע זה לזה, ואף אחד מהם לא יופעל רק כדי שאפליקציית LAN אחת תעבוד. החליטו היכן הבידוד נאכף לפני שתבדקו אותו.
השאירו את נתיב התשובה באותה תוכנית. השירות או הנתב שלו חייב לדעת כיצד להחזיר תעבורה אל טווח המנהרה, או שהתכנון חייב לתרגם את המקור במכוון ובתוך ההיקף המתוכנן.
אמתו, ואז הוכיחו את שני הנתיבים
אמתו את התצורה לפני הפעלה מחדש של משהו, והשאירו הפעלה ניהולית עצמאית פתוחה למקרה שהמדיניות החדשה שגויה.
shorewall checkלאחר בדיקה נקייה, החילו את התצורה וקראו בחזרה מה Shorewall טען. קריאות אלו מתארות את המדיניות הרצה ולא את מה שנראה שקובץ אומר.
shorewall show zones
ip route get 192.168.10.20בדקו בקשה מורשית חדשה ובקשה שנדחתה במכוון מאותו לקוח. לחיצת יד מוצלחת של OpenVPN מוכיחה רק את החליפין החיצוני; השירות המורשה והמשאב הנדחה מוכיחים את המדיניות הפנימית שהתכוונתם לה. אחר כך חברו מחדש את הלקוח וחזרו, כי שם ממשק המנהרה וכתובתו עשויים להשתנות בין הפעלות. אם התוצאה שונה, תקנו את היקף האזור במקום להרחיב את הכלל.