VPN מעל DNS אינו אותו דבר כמו שרת DNS של VPN
הגדרת resolver, DNS מוצפן ומנהרה שנושאת נתונים בתוך DNS הם שלושה דברים שונים. בדקו איזה מהם באמת דרוש לכם.
VPN מעל DNS מתאר רעיון של תעבורה, והוא אינו שם נרדף להפניה של מכשיר ל-resolver מותאם. השאלה שפוטרת את הבלבול פשוטה: מה בעצם נושאות הודעות DNS? VPN רגיל עשוי להתקין resolver כדי שאפליקציות מכוסות ימצאו שמות פרטיים, והחלפה של אותו resolver משנה רק את פתרון השמות. הריצו את הבדיקות שלמטה לפי הסדר, מפני ששלוש הסידורים חולקים אוצר מילים וכמעט שום דבר אחר.
הפרידו בין שלושת הסידורים
בסידור הראשון, ה-VPN מספק resolver או הגדרת מדיניות שמות. נתוני האפליקציה עדיין עוברים דרך חיבורי הרשת שלהם עצמם, והמנהרה משפיעה רק על איזה שרת עונה לשאילתה.
בשני, DNS מוצפן מגן על חילופי ה-DNS עצמם. DNS מעל HTTPS ו-DNS מעל TLS עוטפים שאילתות אל ה-resolver הנבחר, והם אינם נושאים מנות של אפליקציה אחרת. הם גם אינם מסתירים את שמות השאילתות מה-resolver שבחרתם, וזו גבול אמון שונה מהסתרתם מהרשת המקומית.
בשלישי, לקוח משתף פעולה מקודד נתונים אחרים לתוך הודעות DNS, ונקודת קצה משתפת פעולה משחזרת אותם. נתיב ה-resolver הרגיל הופך לתעבורה, וה-resolver הוא כעת רכיב בנתיב הנתונים ולא שירות שמות.
בדקו מה נושאות הודעות ה-DNS
החליפו את ה-resolver וצפו אם נתיב התעבורה של האפליקציה משתנה. אם האפליקציה עדיין מתחברת לאותן כתובות דרך אותן sockets, שיניתם את פתרון השמות ולא דבר נוסף.
מנהרה שנשאת על ידי DNS זקוקה לסידור מתאים בצד השרת. Iodine הוא דוגמה מתועדת: תיעוד הפרויקט מתאר מנהרת IP דרך DNS, והוא דורש רכיב שרת שמבין את הקידוד. הזנת כתובת resolver ציבורי ב-Android אינה מספקת את נקודת הקצה הזו, ומונח שיווקי שמשותף לשני מוצרים אינו מפרט פרוטוקול.
לכידה היא הבדיקה המכרעת. אם אתם רואים שאילתות רגילות אל ה-resolver ולא דבר אחר, אין מנהרה. אם אתם רואים מטען מקודד בשמות שאילתות ובתשובות, מצאתם את הנשא, והשאלה הבאה היא כמה הוא יכול להעביר.
בדקו את הקיבולת לפני שאתם מתחייבים
DNS תוכנן לשאילתות ותשובות, לא למסירה בכמויות. עלות הקידוד, מגבלות גודל ההודעה והתנהגות ה-resolver כולם לוקחים חלק מהנתיב הנומינלי, ולכן הקיבולת השימושית נמוכה מכפי שהקישור הבסיסי מרמז. התייחסו לכל נתון תפוקה שלא מדדתם בנתיב שלכם כאל השערה ולא כתקציב. מדדו את שני הכיוונים, כי העלאה והורדה יכולות לפגוע במגבלות שונות בנשא מסוג שאלה-תשובה.
הלקוח צריך גם להחליט איזו תעבורה נכנסת למנהרה. ממשק שירות VPN מקומי יכול לאסוף מנות, אבל הממשק אינו אומר דבר על האופן שבו התעבורה המרוחקת מגנה עליהן או מעבירה אותן הלאה. פיצול ושידור חוזר מתנהגים אחרת כאשר הנשא הוא פרוטוקול שאלה-תשובה ולא זרם, וחיבור שנשאר פתוח אומר מעט על השהיה אינטראקטיבית.
מדדו עם התעבורה שאתם מתכננים לשאת. מנהרה שנראית טוב לפעימת לב תקופתית עשויה להיות בלתי שמישה להפעלה אינטראקטיבית, וההפך נכון גם כן.
בדקו את אבטחת הנשא
אל תניחו שעיטוף DNS מספק סודיות או אימות חזק. נתיב ה-resolver ונקודת הקצה של המנהרה רואים את מה שהמימוש חושף, וחשיפה זו משתנה לפי התכנון.
הצפנה ובחירת הנשא הן תכונות נפרדות. מנהרה יכולה להיות מוצפנת מעל נתיב IP פשוט, ומנהרה שנשאת על ידי DNS יכולה להיבנות עם הגנה על המטען שלה או בלעדיה. שמרו על HTTPS של האפליקציה בכל מקרה, והעריכו את תכנון האבטחה בפועל של המנהרה ולא את שמה.
אם הדרישה היא פרטיות מהרשת המקומית, DNS מוצפן ומנהרת נתונים עונים על חלקים שונים שלה. רשמו מפני איזה צופה אתם מגנים לפני שתבחרו אחד.
התאימו את התיקון לתקלה בפועל
עבור VPN איטי רגיל, החלפה במנהרה שנשאת על ידי DNS מוסיפה תעבורה מוגבלת מעל הבעיה. היא אינה מתקנת איכות רדיו, עומס יתר או עומס שרת, ובדרך כלל הופכת אותם לבולטים יותר.
עבור כשלים של שמות פרטיים, בדקו תחילה את מדיניות ה-resolver המיועדת: איזה שרת אמור לענות, אילו שמות בטווח, והאם הלקוח רשאי להשתמש בו. לאחר מכן בחרו תעבורה מורשית שמתאימה לדרישה, ושמרו את תצורת ה-resolver ביומן השינויים כדי שהתקרית הבאה לא תתחיל את אותו חיפוש מחדש.
רשימת הבדיקה קצרה: זהו את הסידור, אשרו מה נושאות ההודעות, מדדו קיבולת, ואז עברו על האמון. כל שלב שאינו מתאים לתסמין פירושו ששני הסידורים האחרים עדיין במשחק.