DNS לא נפתר כשה-kill switch של ה-VPN חוסם את פורט 53

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

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

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

שתי תכנונות DNS לאותה תקלה

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

תכנונה B משאירה מאבחן נגיש ברשת המקומית, בדרך כלל הנתב בכתובת 192.168.1.1 או ה-stub של מערכת ההפעלה בכתובת 127.0.0.53, מתוך הנחה שפתרון שמות לא אמור למות עם המנהרה. זה נוח ברשת ביתית שבה הנתב פותר עבור כל הבית. ברשת Wi-Fi של מלון או שדה תעופה אותה חריגה מפנה לשרת של מישהו אחר, וכל שם שאתם מקלידים נחשף, גם אם תעבורת האינטרנט שלכם נשארת חסומה.

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

למה החיפוש של לקוח ה-VPN עצמו עדיין עובד

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

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

תחת systemd-resolved אפשר לראות את הפיצול ישירות.resolvectl statusמציג את שרתי ה-DNS לכל קישור ואת תחומי הניתוב, ואחרי שהמנהרה יורדת התחום הפנימי ממשיך להצביע על שרת בקישור שכבר לא קיים. ה-stub בכתובת 127.0.0.53 עדיין מקבל את השאילתה, ואז ממתין לשרת במעלה הזרם שלא יענה, ולכן הכשל נמשך שניות במקום לחזור מיד.

DNS מוצפן לא עוקף מסנן מקטעים

DNS over HTTPS ו-DNS over TLS נוסעים על 443 ו-853, ולכן כלל שחוסם את פורט 53 לא אמר עליהם דבר. חסימת "DNS" לפי פורט היא מדיניות לגבי פורט, לא לגבי פתרון שמות. אם ה-kill switch שלכם חוסם את כל התעבורה מחוץ למנהרה, DoH מכוסה במקרה. אם הקציתם היתר עבור פורטל שבי או מאבחן ציבורי, הוא אינו מכוסה.

הפקדים בצד הלקוח הם הידית הזולה יותר. Firefox נוטש את מאבחן ה-DoH שלו כששם הקנריתuse-application-dns.netלא נפתר, ולכן רשתות מנוהלות מפרסמות את התחום הזה כ-NXDOMAIN; מדיניות ארגונית יכולה גם לנעול אותו כבוי. ל-Android Private DNS ול-DNS המאובטח של Chrome יש מתגים משלהם וברירות מחדל משלהם. לכבות אותם אמין יותר מרדיפה אחרי כתובות מאבחנים, כי רשימת הכתובות משתנה ומערך הכללים שלכם לא.

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

התאימו את התסמין לשכבה

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

SymptomLikely layerFirst check
Every name fails at once, instantlyResolver answering with a refusalQuery the resolver by address, not by name
Lookups hang for seconds, then time outPackets dropped with no responseWatch port 53 on the physical link
Public names resolve, internal ones do notSplit-DNS routing domainPer-link DNS servers on the tunnel
Names resolve, the page still failsNot DNS: routing or MTUConnect to the IP directly
Only one application failsPinned resolver or cached answerCheck that app's DNS setting

שתי השורות הראשונות הן אלה שאנשים מאבחנים לא נכון. נפילה שקטה וסירוב נראים בדפדפן אותו דבר, "ה-DNS שבור", אבל רק אחד מהם אומר שה-kill switch שלכם עושה את עבודתו. סירוב אומר שמשהו ענה, ולכן החסימה אינה במקום שאתם חושבים.

שחזרו את מדיניות המאבחן ואז הוכיחו אותה

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

אחר כך אמתו בסדר הזה. ב-Linuxresolvectl statusמציג את הקישור הפעיל,dig +short example.comבודק שם ציבורי,dig @10.8.0.1 internal.example.comבודק את הפרטי, ו-sudo tcpdump -ni any port 53מראה באיזה ממשק המקטעים משתמשים בזמן שאתם מריצים את שניהם. ב-WindowsGet-DnsClientServerAddress -AddressFamily IPv4ו-Resolve-DnsName example.comנותנים את אותן שתי עובדות: מי מוגדר, ומי עונה.

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

רשימת בדיקה לפני סגירת הקריאה:

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

מאמרים קשורים