חומת אש של הפצת לינוקס יכולה לחסום את תעבורת ה-VPN שלכם

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

מצאו את המנהל ואת ה-backend

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

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

התאימו את הכיוון ואת הממשק

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

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

שמרו על הסכמה בין בעלי החוקים

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

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

בדקו את התיקון בלי לאבד את הנעילה

בדקו את המצב המיושם עם המנהל שמחזיק בו, בעזרת פקודות שמתאימות ל-backend שרשמתם. הרשימה שלהלן מניחה ש-firewalld אחראי; החליפו במקבילה של nftables או ufw במקום להריץ את כולם. ערבוב כלים בסשן אחד הוא הדרך שבה מכונה מסיימת עם שתי מערכות חוקים סותרות.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=trusted --list-all
sudo nft list ruleset | head -40

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

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