UFW משליך את שרת ה-DNS של ה-VPN ברגע שהמנהרה עולה
מדיניות חסימת ברירת המחדל של UFW מכסה גם את ממשק המנהרה. מיין את התעבורה לפי כיוון, התר את הפותרן הנדחף ב-tun0, ואז פתח את הנתיב החיצוני.
שמות מפסיקים להיפתר ברגע שה-VPN מתחבר, בעוד שפינג לכתובת ציבורית עדיין עונה וסטטוס חומת האש לא מראה שום דבר שנראה שגוי. דבר לא השתנה במדיניות; מה שהשתנה הוא שממשק חדש הופיע, וחסימת ברירת המחדל מכסה אותו מהמנה הראשונה. UFW מחליט לפי כיוון וממשק, ולכן כלל שנכתב לקישור האלחוטי לא אומר דבר על תעבורה שיוצאת מהמנהרה. התיקון הוא קומץ כללים צרים שמוחלים בסדר מסוים.
התסמין מופיע רק אחרי שהמנהרה עולה
מדיניות חסימת ברירת מחדל עושה בדיוק את מה שנאמר לה: כל דבר בלי כלל תואם נדחה, בכל ממשק שקיים. המנהרה לא הייתה קיימת כשנכתבו הכללים, ולכן אף אחד מהם לא יכול לתפוס אותה, והחסימה שתמיד הייתה שם חלה כעת על פתרון שמות. תעבורה ישירה לכתובת מפורשת עדיין יכולה לעבוד כשהרשאה רחבה יותר מכסה אותה, ולכן פינג לפותרן ציבורי מצליח בעוד חיפוש שם נכשל. הפער הוא כלל לממשק שהמדיניות מעולם לא ראתה.
זה גם מסביר למה הכשל מתהפך בצורה נקייה: הורד את המנהרה והשמות נפתרים שוב, כי השאילתה חוזרת לממשק שיש לו כללים. מדיניות שנכשלת רק כשהמנהרה למעלה אינה בעיית DNS, וכיוון הפותרן עצמו מבזבז כאן את הזמן הרב ביותר. קרא את רשימת הממשקים לפני שאתה קורא את תצורת הפותרן.
שלושה כיוונים, שלוש קבוצות כללים שונות
סשן אחד נוגע בכללים ביותר מכיוון אחד, ומנהרה מוסיפה ממשק שני לכמעט כל אחד מהם. מיון התעבורה לפי כיוון וממשק קודם הופך את השאר למכני, כי כל שורה למטה צריכה את הכלל שלה במקום שלה. הדוגמאות משתמשות ב-tun0 ובמאגר של 10.8.0.0/24, אז החלף את השמות והטווחים באלה מהפלט של הלקוח עצמו.
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
שתי שורות מתבלבלות לעתים קרובות כי שתיהן מזכירות את המנהרה. כלל לפותרן מתיר תעבורה שהלקוח שולח לתוך המנהרה, בעוד שכלל ל-SSH מתיר תעבורה שהשרת מקבל ממנה; הם חיים במכונות שונות ונכשלים באופן בלתי תלוי. השורה שנשכחת לרוב היא השנייה, כי הלקוח לא יכול להקים את המנהרה בכלל עד שהתעבורה שלו לכתובת הציבורית של השרת תותר. עבוד מלמעלה למטה ולכל כשל יש סיבה אחת סבירה.
פותרן שנדחף צריך כלל משלו
אם המנהרה נושאת DNS תלוי במה שהשרת שולח. שרת שדוחף אפשרות פותרן מתקין כתובת פרטית בתצורת הלקוח, וכתובת זו ניתנת לניתוב רק דרך המנהרה. אם השרת לא דוחף דבר, הלקוח שומר על הפותרן שכבר היה לו ולכללים למטה אין מה להתיר. בדוק את המצב שנדחף ואת תוצאת השאילתה הנוכחית לפני שאתה כותב משהו:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedפלט הסטטוס נוקב בשם הפותרן שבשימוש ובקישור שאליו הוא קשור, וחיפוש המסלול שמאחוריו מראה איזה ממשק יישא שאילתה לכתובת הזו. כשהפותרן יושב על קישור אחר, הבעיה מוקדמת יותר מחומת האש ושום כלל לא יעזור. כששניהם מסכימים על המנהרה, דרושים שני כללים, כי UDP נושא את רוב השאילתות ו-TCP משתלט כשתשובה נחתכת. רשום את שני הערכים, כי אלה שהכללים ינקבו בשמם:
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'פתח את הנתיב החיצוני לפני הפנימי
הלקוח חייב להגיע לכתובת הציבורית של השרת לפני שקיימת מנהרה, ולכן הכלל בשבילה יושב על הקישור הפיזי וחייב להיות במקום ראשון. מדיניות שמתירה את הפותרן אבל שוכחת את השרת משאירה את הלקוח לגמרי לא מסוגל לבנות את המנהרה, והתסמין הזה מיוחס בדרך כלל למתג הרג. אחר כך התר את השירותים שרצית באמת דרך המנהרה, כלל צר אחד בכל פעם, במקום לפתוח את הממשק כולו. הכללים הצרים הם הסיבה שהחסימה יכולה להישאר במקומה.
sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'הסדר חשוב בזמן הבדיקה, כי הכלל הראשון הוא מה שמאפשר למנהרה לעלות בכלל. הוסף אותו, התחבר, וודא שהמנהרה למעלה לפני שאתה מוסיף את כלל השירות, כי עשיית שניהם בבת אחת משמעה שכשל לא אומר לך דבר על איזה חצי שגוי. החלף את כתובת התיעוד למעלה בנקודת הקצה שהלקוח מוגדר להשתמש בה.
סיים את צד הלקוח בניתוק בכוונה. החסימה אמורה עדיין לדחות את התעבורה שהחרגת בכוונה, כי פותרן שעונה כשהמנהרה למעלה מכסה רק חצי ממדיניות שדוחה בספק.
לקוח שמתחבר עדיין לא התקבל
לשרת יש כיוון משלו לשקול, ולקוח שמשלים את לחיצת היד עדיין לא מגיע לשום דבר שרץ על השרת עד שהשרת יקבל אותו. כלל המאזין הציבורי רק מאפשר למנהרה להתקיים; הוא לא מכניס את התעבורה של המנהרה. בשרת אלה שני כללים ועוד בדיקה אחת שהשירות באמת מאזין:
sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'המאגר בכלל חייב להיות שווה לטווח שהשרת מקצה, ומספר המנהרה חייב להתאים לזה שהשרת יצר, כי כלל לממשק אחר אינו ניתן להבחנה מהיעדר כלל. limit מכוון לפורט ניהולי, כי הוא מגביל חיבורים חוזרים במקום להתיר אותם ללא גבול. בדיקת המאזין מפרידה בין פורט סגור למנה שנזרקה, שנראים זהים מהלקוח. גם כללים ממוספרים אינם כל התמונה: כללי ה-before של UFW וכל שורת nftables שנכתבה ביד מתאימים קודם ועדיין יכולים לדחות מנה שהרשימה נראית שמתירה.