לאפשר DNS רק דרך מאתר ה-VPN שלכם: מדריך צעד אחר צעד
עקבו אחרי שאילתת שם אחת מהדפדפן עד לתשובה. ראו היכן נבחר המאתר, היכן חומת האש אוכפת אותו ומה לעולם אינו מכוסה בכלל פורט 53.
עקבו אחרי שאילתת שם אחת מרגע שאתם מקלידים אותה. הדפדפן שואל את מערכת ההפעלה, מערכת ההפעלה שואלת את המאתר שהמדיניות שלה בוחרת, והשאילתה יוצאת מהמכשיר דרך ממשק כלשהו בתחבורה כלשהי. תכנון ה-VPN שלכם אומר שהתשובה אמורה לבוא ממאתר מסוים בדרך מסוימת. הפער בין שתי הקביעות האלה הוא מה שאתם מגדירים ואז אוכפים.
שלב 1: תנו שם למאתר ולנתיב
רשמו שלושה דברים לפני שאתם נוגעים בחומת אש: כתובת המאתר, הפרוטוקול והפורט שאתם מצפים להם, והממשק שדרכו השאילתה אמורה לצאת. בלי הרשימה הזאת כלל הוא ניחוש לגבי תעבורה ולא אכיפה של החלטה. VPN יכול לשאת נתוני יישומים בזמן ש-DNS עוקב אחרי סידור נפרד, וזה כשלעצמו אינו תקלה. זה מה שקורה כשאיש לא אמר ללקוח אחרת.
מתן שם מפורש לנתיב הוא ההבדל בין תכנון לתאונה. הוא גם נותן לכם משהו לבדוק אחר כך, כי כל תצפית ניתנת להשוואה לציפייה כתובה. שמרו את הרשימה בכרטיס השינוי ולא בראש של מישהו.
שלב 2: הציבו את המדיניות היכן שהיא באמת נמצאת
בחירת המאתר שייכת ללקוח: תצורת הרשת של מערכת ההפעלה, ההגדרות של לקוח ה-VPN עצמו או מדיניות דפדפן מנוהלת. הציבו אותה שם קודם, במנגנון שהפלטפורמה תומכת בו, כי חומת אש אינה יכולה לאלץ לקוח לבחור מאתר שמעולם לא שמע עליו. בלקוח עם מנהרה מפוצלת, אמרו במפורש אילו דומיינים הולכים למאתר הפנימי. בצי מנוהל, מדיניות דפדפן היא לעתים המנוף היחיד ל-DoH, כי הדפדפן יכול לבחור מאתר מוצפן משל עצמו בלי תלות בהגדרת המערכת.
דלגו על זה ולכו ישר לחומת האש, ותקבלו כלל שמתיר את המאתר הנכון ולצידו לקוח שלעולם אינו משתמש בו. הכלל נראה נכון ויומני המאתר נשארים ריקים, צמד מבלבל לניפוי שגיאות. הגדירו קודם את הבחירה ואז אכפו אותה.
שלב 3: אכפו את הנתיב באופן צר
הוסיפו עכשיו את הרשאת הרשת לנתיב המותר: כתובת המאתר, הפרוטוקול והפורט, והממשק שדרכו היא אמורה לצאת. החזיקו את הכלל מוגבל לאותו מאתר במקום להתיר את כל ה-DNS היוצא. שלושת הנתיבים שלמטה הם אלה שלקוח מודרני יכול לקחת, ורק הראשון מכוסה בכלל פורט 53.
| Path | Port | Who controls it |
|---|---|---|
| Classic DNS | UDP and TCP 53 | System resolver settings |
| DNS over TLS | TCP 853 | Resolver or stub configuration |
| DNS over HTTPS | TCP 443 | Browser or application policy |
חסימת DoH ו-DoT היא לגיטימית; ההנחה שכלל פורט 53 כבר חסם אותם אינה כזו. דפדפן עם DoH מפענח שמות בנתיב שהכלל שלכם מעולם לא תיאר, ויישום שמביא מאתר משל עצמו עושה אותו דבר. רשמו כל נתיב שאתם מתכוונים להתיר וכל אחד שאתם מתכוונים לסרב לו. כלל שאינו נוקב בנתיב לא הכריע לגביו.
שלב 4: עקבו אחרי שמות פרטיים וציבוריים
DNS מפוצל שולח בכוונה רק מרחבי שמות פרטיים למאתר פנימי בעוד שמות ציבוריים הולכים למקום אחר, ולכן יותר ממאתר אחד בתכנון אינו דליפה. דליפה היא שאילתה שהייתה אמורה ללכת למאתר שלכם ומגיעה למקום אחר, או נתיב מתוכנן בלתי נגיש שמפיל את הלקוח בחזרה בשקט. שני המקרים האלה הם מה שכדאי לחפש. עקבו אחרי שם פנימי ושם ציבורי תחת המדיניות המתוכננת וציינו איזה מאתר השיב לכל אחד.
אתר בדיקה שמדווח על המאתר שלכם הוא רמז ולא הוכחה, כי הוא רואה רק את השאילתות שהגיעו אליו. לכדו את השאילתה בצד הלקוח כשאתם צריכים לדעת באיזה נתיב היא באמת הלכה, ואז השוו את שתי התצפיות. כשהן חלוקות, מצאתם נסיגה שאיש לא תיעד.
אם כתובת המאתר נכונה אך אינה נגישה, הבעיה היא בניתוב או בסינון ולא במדיניות. עקבו אחרי השאילתה לכתובת הזו ואשרו שהתשובה חוזרת בממשק הצפוי לפני שתשנו הגדרת מאתר כלשהי.
שלב 5: השאירו דרך חזרה
לפני שאתם מהדקים את הגישה ל-DNS בשער, אשרו שיטת שחזור שאינה תלויה בפענוח שמות. מאתר שבור הופך כל כלי תיקון לקשה יותר להשגה, כולל אלה שבהם הייתם משתמשים כדי לבטל את השינוי. השאירו קונסולה מקומית או נתיב מחוץ לרצועה פתוחים עד שהמדיניות החדשה תוכח. הסירו אותו רק אחרי שהמדיניות שרדה התחברות מחדש.
אחרי התחברות מחדש או עדכון מדיניות דפדפן, בדקו שוב את המצב האפקטיבי, כי שניהם יכולים לשנות את המאתר בלי לשנות את הכלל שלכם. הדרישה היא נמען ידוע ונתיב מוגן לשאילתות, לא תווית מאתר מרגיעה בצילום מסך אחד. מפרט RFC 8484 ל-DNS over HTTPS הוא האסמכתא לנתיב המוצפן שכלל הפורט שלכם אינו רואה.