DNS גאוגרפי ואניקאסט: בדיקת נקודת הכניסה של VPN שמקבלים

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

בדקו של מי המיקום שהפותר מדווח עליו בפועל

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

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

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

בדקו מה החליטה ניתוב האניקאסט

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

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

בדקו שהסשן שורד החלפת צומת

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

צפו בשינוי במקום להניח אותו. sudo tcpdump -ni any -c 20 esp מציג את המנות החיצוניות כשהמסלול משתנה, ושינוי פתאומי בכתובת העמית הוא השינוי עצמו. הגדירו במפורש את ההתנהגות הרצויה למימוש שאתם מריצים, ואז בדקו אותה בכפיית שינוי מסלול. אם התכנון מניח שכפול סשן, שם התהליך ושם הכשל שהוא אינו מכסה.

בדקו שהזהות עדיין תואמת

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

בדקו זאת מלקוח שהגיע לצומת לא שגרתי, כי זה המקרה שבו תעודה לכל צומת הופכת לגלויה. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com מדפיס את השרשרת ואת השמות, וזה בדיוק מה שהלקוח משווה. אחר כך החליטו אם יש לצמצם את הפרופיל או לשנות את מודל התעודה.

בדקו את הרשומה, לא רק את התשובה הראשונה

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

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

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