מתג ההרג חוסם את שרת ה-VPN לפני שזורם כלשהו עובר
איזה שלב מתג ההרג חוסם: חיפוש נקודת הקצה, המסלול החיצוני, מסלול החזרה וחריגי עמיתים מיושנים — עם מונים במקום ניחושים.
מתגי הרג נכשלים בכיוון שאנשים לא מצפים לו: הם בנויים לחסום תעבורה כשהמנהרה למטה, והחבילות שבונות את המנהרה הן בעצמן תעבורה. זו כל התקלה. מערכת חוקים שמפילה כל מה שלא יוצא דרך המנהרה מפילה גם את לחיצת היד שאמורה להעלות אותה, ולכן הלקוח מנסה שוב בלולאה והשגיאה מיוחסת לשלב שנבדק ראשון. לפני שמרחיבים חומת אש, גלו איזה משלושת השלבים נדחה: חיפוש השם, החבילה החיצונית אל העמית, או התשובה שחוזרת.
איך המנהרה והתעבורה שלה תלויות זו בזו
קראו לקוח VPN כשני מצבי רשת החולקים נתיב שקע אחד. לפני שהמנהרה קיימת, הלקוח פותח שקע על המתאם הפיזי ושולח מסגרות מוצפנות לכתובת ולפורט של העמית. רק לאחר שההחלפה הזו מצליחה הוא יוצר את התקן המנהרה ומתקין מסלולים. מתג הרג הוא מדיניות לגבי המצב השני, שנכתבה כה רחב שהיא חלה על שניהם.
חוקים מבוססי ממשק הם הצורה הרגילה: קבלו את מה שיוצא דרך tun0 או wg0, השליכו את שאר נתיב היציאה. הניסוח הזה לא יכול לפטור את החיבור של הלקוח עצמו לשרת, ולכן מימוש נכון מוסיף את החריג הזה במפורש, וגם אתם כשאתם כותבים חוקים ביד. חוקים לפי יישום ב-Windows וב-macOS עוקפים חלק מזה על ידי התאמת תהליך במקום ממשק, אבל התהליך עדיין צריך לצאת לפני שהמנהרה קיימת.
שלושה שלבים, לפי הסדר שבו הם קורים
השלב הראשון הוא פתרון. כשהפרופיל שומר שם מארח במקום כתובת מפורשת, הלקוח זקוק לתשובת DNS לפני שיוכל לשלוח משהו. פרופיל שמפנה את ה-DNS לפותרן של המנהרה יוצר מבוי סתום: הפותרן נגיש רק דרך המנהרה שהחיפוש אמור לאפשר. פתרון מחוץ למנהרה, או הצמדת נקודת הקצה לכתובת, מסיר את העמימות.
השלב השני הוא החבילה החיצונית, שעליה לשרוד קודם את הניתוב ואחר כך את חומת האש, בסדר הזה. wireguard-tools מטפל בחצי הניתוב של זה עבור WireGuard על ידי סימון החבילות שלו והוספת חוק מדיניות כדי שידלגו על ברירת המחדל שהוא זה עתה התקין; דף העזרה של wg-quick מתאר את החוק הזה ואת הטבלה שבה הוא משתמש. בנו מחדש את הניתוב הזה ביד, או תנו לכלי שני לשכתב את החוקים, והחבילות המסומנות עלולות להישלח חזרה אל המנהרה שהן אמורות להקים.
השלב השלישי הוא נתיב החזרה. לחיצת יד בלי תשובה אינה הוכחה להשלכה יוצאת; היא מתיישבת באותה מידה עם חוק כניסה בשרת או עם התקן NAT ששכח את המיפוי. הפרידו בין אלה לפני שנוגעים בלקוח.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
לקוחות רושמים את הסימפטום שהם מזהים, לא את השלב שנכשל, ולכן הטבלה מהירה בדרך כלל מהלוג.
מונה מחליט מהר יותר מלוג
ב-Linux, nft list ruleset או iptables -vnL OUTPUT מדפיס מונה חבילות לכל חוק. התחברו פעם אחת, תנו לזה להיכשל ואז קראו שוב את המונים. חוק שהמונה שלו זז הוא חוק שלחיצת היד פגעה בו; אם שום דבר לא זז בשום מקום, החבילה לא הגיעה מעולם לחומת האש. ראיתי מערכת חוקים מפילה את לחיצת היד של עצמה, ורק המונים אמרו את זה.
כדי להבדיל בין מעולם לא הגיע לחומת האש למעולם לא עזב את המארח, עקבו אחרי הממשק עצמו. ip -s link show dev wlan0 מדווח על חבילות שנשלחו, ו- tcpdump -ni wlan0 udp port 51820 מציג את המסגרות. אם הוא נשאר שטוח בזמן שהלקוח מנסה שוב, התקלה נמצאת מעל netfilter: מסלול עמית חסר, חוק מדיניות שמצביע להתקן שעוד לא קיים, או שגיאת שקע שהלקוח בולע.
בדקו חריגים מול כתובות תיעודיות כמו 203.0.113.10, כדי שטעות לא תוכל לבדוק את המארח של מישהו אחר.
חריג נקודת קצה מיושן נקרא כמו נפילת שרת
הגרסה המטעה ביותר מופיעה אחרי שכתובת העמית משתנה: שירות כתובות דינמיות העביר אותה, המארח נבנה מחדש, או שכתובת היציאה של הרשת שלכם שונה. החריג עדיין מציין את הכתובת הישנה, ולכן חבילות לחדשה נופלות על חוק ההשלכה. אותה הגדרה עבדה אתמול, ולכן אנשים מתחילים באיתור תקלות בשרת.
שם מארח בתוך חוק חומת אש לא מציל אתכם. ב-nftables השם נפתר כשמערכת החוקים נטענת, ולכן הוא מצמיד את הכתובת שהייתה קיימת באותו רגע ומתיישן כמו כתובת מפורשת. הפתרון העמיד הוא לעדכן את החריג כשנקודת הקצה משתנה ולהשאיר אותו צר: כתובת עמית אחת, פורט תעבורה אחד. טווח רחב מספיק כדי לשרוד שינוי כתובת הוא גם רחב מספיק כדי להוציא תעבורה לא קשורה.
כשמתג ההרג פועל על מארח השרת
אותה תלות קיימת בקצה השני, ושם קל יותר לפספס אותה. אם המכונה שמשמשת כשרת ה-VPN שלכם מריצה גם לקוח שולחני עם מתג הרג, או פרופיל חומת אש שהועתק ממחשב נייד, חוקי ההשלכה שלו חלים על השירות שמסיים את המנהרות. תשובות ללחיצת יד של לקוח מושלכות, ולכן כל לקוח נכשל בהתחברות בזמן שהשרת נראה בריא וממשק המנהרה שלו יושב ללא שימוש.
המארח הזה זקוק לשלוש קבלות צרות לפני ההשלכה: פורט ההאזנה בממשק הפיזי, ממשק המנהרה לתעבורה מפוענחת, והעברה מהמנהרה לעבר מה שהלקוחות אמורים להשיג. קראו את המערכת המותקנת עם nft list ruleset, iptables -S, או pfctl -sr לפני שמשנים משהו, וזכרו שמערכת חוקים שמורה שורדת אתחול, ולכן טעות שם שורדת את התהליך שיצר אותה.
סדר התאוששות ששומר על המכונה סגורה
עבדו מהפרופיל החוצה. קראו את כתובת העמית והפורט שהלקוח משתמש בהם, ודאו ששם המארח נפתר בלי המנהרה, ואז הוסיפו חריג אחד לאותה כתובת ופורט רק במתאם הפיזי. התחברו שוב וצפו במונה השליחה; לחיצת יד שהושלמה היא הסימן שהשלב השני תוקן.
השאירו את שאר מדיניות ההשלכה במקומה בזמן הבדיקה. בדיקה בלתי מזיקה היא לנסות חיבור לכתובת תיעודית לא קשורה ולוודא שהוא עדיין מסתיים בפסק זמן, מה שמראה שמתג ההרג עובד ולא כבוי. הדקו את החריג כשהמנהרה יציבה, ואל תשאירו אישור קבוע להכול עבור קובץ הלקוח רק כי זה נוח.
אם המנהרה עולה והיישום עדיין נכשל, השלבים הנותרים אינם זה: DNS מפוצל, MTU וניתוב לפי יישום כל אחד מהם יוצר מנהרה מחוברת עם תעבורה שבורה, ולכל אחד בדיקה ראשונה אחרת.