מתג החסימה של UFW חוסם את ה-VPN שלך? אפשרו את העמית

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

מדוע היתר על tun0 לא תואם דבר בהתחלה

tun0 נוצר על ידי הלקוח לאחר שקיימת הפעלה. הדטגרמות שבונות את אותה הפעלה הן חבילות UDP רגילות הממוענות לספק בפורט 1194, והן יוצאות דרך wlan0 או eth0 עם כתובת המקור הפיזית. allow out on tun0 תואם רק תעבורה שממשק היציאה שלה הוא tun0, ולכן במהלך לחיצת היד הוא לא תואם דבר בכלל.

שימו default deny outgoing מעל זה והחבילות החיצוניות נזרקות לפני שהממשק בכלל מופיע. הלקוח מנסה שוב, מגיע לפסק זמן ומדווח על כשל TLS או לחיצת יד, מה ששולח אנשים לחפש בתעודות ובאימות MTU בזמן שהחומת אש אוכלת את החיבור בשקט. הכלל שאמור היה להכיל את התעבורה שלכם מונע מאותה תעבורה להיות מוכלת.

התיקון הרפלקסיבי הופך את הדליפה לקבועה. sudo ufw allow out on wlan0, או החזרת ברירת המחדל להיתר, מעלה את המנהרה ומשאירה את המכונה בלי מתג חסימה: בפעם הבאה שהמנהרה נופלת, הכול ממשיך דרך המתאם הפיזי. איבדתי אחר צהריים בדיוק על צמד השינויים הזה לפני שהבנתי איזו חבילה אני באמת מסנן.

מה ששתי קבוצות החבילות צריכות

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

sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'

החליפו את הכתובת והפורט באלה של הפרופיל שלכם. עמיתי WireGuard עונים בדרך כלל על 51820/udp; פרופילי OpenVPN שעוברים דרך TCP 443 זקוקים לפורט הזה במקום. הפרטים שונים, הצורה לא: שני הכללים צרים, וביחד הם מגדירים את היעדים היחידים שהמכונה יכולה להגיע אליהם כשהמנהרה למטה.

הסדר הוא המיתוס השני. עם iptables גולמי קוראים את השרשרת מלמעלה למטה ומנמקים איזה כלל מנצח. ufw אינו עטיפה דקה סביב הרשימה שהקלידו; הוא מהדר את הכללים לשרשראות משלו ובוחר את נקודות ההוספה. ufw status מדפיס אותם בסדר של ufw, לא בסדר שלכם. כשכלל נראה כאילו התעלמו ממנו, השוו ufw show added לקבוצה המהודרת מ- iptables -S | grep ufw לפני שכותבים משהו מחדש.

החריגה חייבת להישאר ברוחב כתובת אחת

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

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

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

בנו את המדיניות לפני שהמנהרה נדרשת

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

sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

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

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

בדקו את המצב החסום, ושמרו את הביטול

מתג חסימה שלא נבדק הוא ניחוש. נתקו את הלקוח בכוונה ונסו לטעון עמוד: זה חייב להיכשל. התחברו מחדש וזה חייב להתאושש בלי לגעת בכלל. sudo ufw status verbose מאשר את ברירות המחדל ואת מצב הרישום, ו- ufw status numbered מראה איזה כלל בדיקה למחוק כשהוא שורד את מטרתו.

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

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

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