ufw allow 443 לא עשה דבר לשירות שמאחורי ה-VPN

ping מצליח מלקוח VPN, שירות ה-TCP מגיע לפקיעת זמן, ו-ufw allow 443/tcp לא משנה דבר. כאשר היישום פועל על מארח מאחורי השער ולא על השער עצמו, ההרשאה הזו נכתבה לנתיב תעבורה שגוי. החבילה אינה ממוענת לחומת האש ואינה נמסרת לתהליך מקומי, ולכן כללי הקלט לעולם אינם רואים אותה. התיקון הוא כלל נתב שמכוון לזרימה המועברת, והראיה לכך כבר נמצאת ביומן.

החלט אם היעד מקומי או מועבר

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

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

קרא את החסימה לפני הוספת כלל כלשהו

שחזר ניסיון חיבור מורשה אחד ותעד את המקור, היעד, הפרוטוקול ופורט היעד כפי שהשער תיעד אותם. השווה את ארבעת הערכים האלה לרשומת היומן ולמיקום האמיתי של השירות. ping מוצלח קודם מוכיח רק שהחילופין שלו עצמו הורשו, וחומת אש עשויה לטפל ב-TCP SYN אל יישום באופן שונה לחלוטין.

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

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

כתוב את כלל הנתב הצר ביותר שמתאים

בדוגמה הזו לקוחות מגיעים דרך tun0 מ-172.20.8.0/24, השירות מאזין בכתובת 10.30.0.15 בפורט 8443, והשער יוצא דרך ens5. הערכים האלה נבחרו כדי שלא ייראו כלל כמו ברירת מחדל של VPC בענן 10.0.0.0/16 או רשת ביתית 192.168.0.0/16, ו-8443 מרחיק את הדוגמה מהמאזין 443 של השער עצמו.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

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

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

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

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

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

בדוק מה UFW לא יכול לאכוף עבורך

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

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

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

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