האם ה-VPN שלך מצפין DNS, או רק את הקפיצה הבאה?

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

רשמו מי מקבל את השאילתה בכל שלב לפני שאתם נוגעים בקובץ תצורה.

שני סידורים נראים זהים בעמוד הגדרות

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

ההבדל מדיד ולא פילוסופי. חפשו את הפעלת ה-TLS בלקוח או בשרת, ותדעו איזה סידור באמת יש לכם.

מפו את שרשרת הפותרים לפני שאתם משנים אותה

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

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

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

ודאו איזו קפיצה מוצפנת

התחילו בלקוח ואשרו אם יש לו הפעלת TLS אל פורט 853. שאילתה שנפתרת כראוי דרך פורט 53 אינה מוכיחה דבר על הצפנה.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

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

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

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

תעדו את הבעלים ואת התנהגות הכשל

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

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

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