להגביל שער OpenVPN לרשת מקומית אחת עם כללי UFW

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

כתבו קודם את הטופולוגיה ואת ההרשאה

הדוגמה משתמשת בשרת Community OpenVPN עם התקן TUN במרחב המשתמש בשם tun0, מאגר לקוחות 10.77.0.0/24, ורשת משנה מחוברת אחת 192.168.60.0/24 על lan0. העברת IPv4 כבר עובדת ולרשת המקומית כבר יש מסלול חזרה אל המאגר, כך ששום דבר כאן אינו תלוי בתרגום ביניהם.

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

הציבו את השומרים לפני הקבלות המוקדמות של UFW

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

בסעיף *filter של הקובץ /etc/ufw/before.rules, הכריזו על שתי שרשראות לצד ההכרזות הקיימות ולפני כל שורת כלל.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

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

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

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

קראו מה כל שומר מתיר ומה הוא דוחה

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

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

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

הרשו את רשת המשנה וסגרו את דלתות הצד

הציגו תחילה תצוגה מקדימה של הרשאת המסלול, ואז הסירו את דגל התצוגה המקדימה כדי להחיל אותה: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. לאחר מכן עברו על סדר כללי המשתמש, כי דחייה מוקדמת עדיין גוברת על הרשאה מאוחרת. הרשאה לכל רשת המשנה היא גם הצורה הלא נכונה כאשר רק יציאת HTTPS של מארח אחד אמורה להיות נגישה.

שימו לב מה עושה זריקת הקלט: לקוחות המנהרה אינם יכולים להגיע לאף שירות על השער עצמו, כולל מאזין DNS הקשור לכתובת הרשת המקומית שלו. אירוח DNS שם דורש חריגה מכוונת לפני הזריקה וחוזה הרשאה מתוקן. אם UFW מנהלת IPv6, הוסיפו זריקות מתאימות עבור tun0 בקובץ before6.rules גם כן, כי רשימת יעדים של IPv4 אינה אומרת דבר על מנות IPv6.

אמתו את המדיניות הנטענת, לא את התצוגה המקדימה

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

sudo ufw --dry-run reload
sudo ufw show raw

ודאו ששומרי המנהרה מופיעים לפני הרשאות המצב ו-ICMP המובנות. ufw status רגיל אינו מציג כללי before שנערכו ביד, ולכן מפעילים מסיקים שכלל חסר כאשר הוא למעשה נטען. קראו את הרשימה הגולמית מלמעלה למטה במקום לחפש קטע. אם השומרים מופיעים אחרי הרשאת מצב, הגבול אינו עושה את מה שהקובץ מרמז.

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

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