DNS ב-AWS Client VPN: השתמשו ב-resolver של ה-VPC, לא ב-subnet

ה-endpoint נמצא ב-10.0.8.0/24, ולכן ה-resolver חייב להיות 10.0.8.2. זהו ההיגיון שאני שומע הכי הרבה, והוא שגוי פעמיים. Route 53 Resolver עונה על טווח ה-IPv4 הראשי של ה-VPC ועוד שתיים, אשר עבור VPC של 10.0.0.0/16 הוא 10.0.0.2, לא משנה באיזה subnet ה-endpoint משתמש. הטעות השנייה שקטה יותר: הצבת הכתובת הנכונה ב-endpoint אינה אומרת שמערכת ההפעלה של הלקוח תשאל אותו אי פעם משהו. שתי הטעויות מייצרות אותו סימפטום: פתרון שמות עובד אצל חלק מהלקוחות ונכשל אצל אחרים.

המיתוס מתחיל בשיוך ה-subnet

השיוך עוסק במקום שבו נמצאים ממשקי הרשת האלסטיים של חיבורי הלקוחות, ולא באיזו כתובת resolver קיימת. ה-subnets של ה-endpoint נותנים ללקוחות כתובת בתוך ה-VPC, ואף אחד מהם אינו נושא resolver משלו.

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

חשבו את הכתובת מטווח ה-VPC הראשי

קחו את ה-CIDR הראשי של IPv4 של ה-VPC והוסיפו שתיים לכתובת הרשת. 10.0.0.0/16 נותן 10.0.0.2, 172.31.0.0/16 נותן 172.31.0.2, ו-VPC עם טווח משני משאיר את ה-resolver בראשי. subnet של 10.0.8.0/24 בתוך אותו VPC לא מזיז אותו. כתבו את הכתובת ליד ה-ID של ה-VPC לפני שנוגעים ב-endpoint, כי המספר הוא תכונה של ה-VPC ולא של החיבור.

ה-VPC עונה גם על כתובת ה-link-local 169.254.169.253. הכתובת הזו נגישה מתוך ה-VPC, אבל היא אינה יעד מנותב כללי למחשב נייד בקצה השני של מנהרה.

אז יש שתי כתובות resolver תקפות, ואף אחת מהן אינה ה-subnet ועוד שתיים.

מה הגדרת ה-endpoint עושה ומה היא לא עושה

ל-endpoint של Client VPN יש שדות שרת DNS, ובמקום שבו הקונסולה מציעה אפשרות resolver של VPC היא ממלאת את אותו רעיון. הגדרתם משנה את מה שהשירות מוסר ללקוחות בזמן הקמת החיבור. היא לא משנה את מה שלקוח OpenVPN לא מנוהל עושה עם הערך הזה, כי הלקוח עדיין צריך להחיל אותו על מערכת ההפעלה. מהפער הזה מגיע «זה עובד ב-Mac שלי אבל לא במחשב Linux».

ב-Linux אינטגרציית ה-resolver שייכת למנהל החיבורים ולא למשתמש. עריכה ידנית של /etc/resolv.conf מוכיחה שהכתובת עובדת לסשן אחד ואז נעלמת בחיבור מחדש — לכן כל כך הרבה מקרים שתוקנו חוזרים למחרת בבוקר.

בדקו את ה-resolver הפעיל בלקוח לאחר החיבור, לא את עמוד התצורה של ה-endpoint.

Split tunneling יכול להביס resolver נכון

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

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

אל תפתחו security groups לכתובת Amazon DNS

האינסטינקט כשחיפושים מתייאשים הוא להוסיף כלל שמתיר UDP 53 לכתובת ה-resolver. AWS מתעדת ש-security groups ו-network ACL לא מסננים תעבורת Amazon DNS כפי שהם מסננים תעבורה למופע DNS משלכם. פתיחת הכללים האלה לא משנה דבר ל-resolver של ה-VPC ומרחיבה את הגבול בלי סיבה. resolver שאתם מפעילים בעצמכם הוא מקרה אחר ואכן זקוק לכללים משלו.

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

אמתו את המסלול, ואז מדדו משהו אחר

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

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