מדוע תשובות DNS64 משתנות ברגע שה-VPN מתחבר?

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

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

לאן רשומת AAAA מסונתזת מצביעה באמת

פותר DNS64 משיב לשאילתת AAAA עבור שם שיש לו IPv4 בלבד בכך שהוא משבץ את כתובת ה-IPv4 בתוך קידומת שהוגדרה לו לשימוש, והקידומת הידועה למלאכה הזו היא 64:ff9b::/96 כמתואר ב-RFC 6147. הרשומה נראית ליישום כמו כל רשומת AAAA אחרת, וזה בדיוק העניין: לקוח עם IPv6 בלבד יכול לנסות חיבור בלי לדעת שליעד מעולם לא היה IPv6. לאחר מכן החיבור הזה תלוי בפונקציית NAT64 שמתרגמת בין שתי המשפחות במקום כלשהו לאורך הנתיב. בלי המתרגם הזה, הכתובת המסונתזת היא יעד שנראה סביר ושאינו מוביל לשום מקום.

הרשומה אפוא מקודדת שני דברים בעת ובעונה אחת: כתובת ה-IPv4 המקורית וההנחה שהמתרגם נגיש. רק הראשון נראה בתשובה עצמה.

שלושה תנאים קובעים אם זה עדיין עובד

התנאי הראשון הוא איזה פותר הפיק את הרשומה, שכן פותר בלי DNS64 מוגדר אינו מחזיר דבר עבור השם הזה והיישום נכשל בדרך אחרת. השני הוא אם למכשיר שלכם יש נתיב אל הקידומת המסונתזת, כי תשובה יכולה להיות תקפה בזמן שהדרך אליה חסרה. השלישי הוא אם המתרגם שבעל הקידומת הזו נמצא על הנתיב שבו הייתם משתמשים, כי מנהרה שנושאת את 64:ff9b::/96 למקום אחר מגיעה לפונקציה אחרת או לשום דבר. שלושתם יכולים להתקיים לפני המנהרה ולהיכשל אחריה, ולכן התסמין נראה כמו נסיגה פתאומית.

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

כשהפותר משתנה, התשובה משתנה

לקוח VPN לעיתים קרובות דוחף פותר משלו או משתלט על כל נתיב השאילתה, והפותר הזה אולי אינו מסנתז דבר. שאילתות עבור שמות עם IPv4 בלבד אינן מחזירות אז רשומת AAAA, ולקוח עם IPv6 בלבד חווה זאת כשם שאינו יכול להגיע אליו. גם ההפך קורה: פותר שכן מסנתז יכול לתת לכם קידומת שהנתיב המנהרה שלכם אינו נושא.

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

בדקו את השאילתה ואת הנתיב בנפרד

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

dig AAAA ipv4only.example.com +short
dig AAAA ipv4only.example.com | grep -E '^;; SERVER'
ip -6 route get 64:ff9b::c000:0216
curl -6 -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 http://ipv4only.example.com/

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

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