ה‑DNS הפרטי של Pritunl לא עובד? הוסיפו מסלול צר לרזולובר

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

ודאו שהרזולובר דוחה את מאגר הלקוחות שלכם

התחילו בהוכחה שהכשל נוגע למקור ולא לנגישות. מלקוח מחובר, שאלו את הרזולובר הפרטי ישירות וצפו אם הבקשה נגמרת בזמן המתנה או חוזרת כדחייה. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 שנגמר בזמן המתנה בעוד אותה שאילתה מהשער מצליחה מצביע על מדיניות גישה ברזולובר. תשובת SERVFAIL מצביעה למקום אחר לגמרי, בדרך כלל לאזור או למעביר העליון.

רשמו את כתובת הלקוח לפני הבדיקה. ip -4 addr show tun0 בלקוח, או החכירה שמוצגת בקונסולה, אומר לכם איזה מאגר הרזולובר רואה.

לאחר מכן ודאו שהנתיב קיים בכלל. מסלול ששולח את כתובת הרזולובר למנהרה הוא תנאי מוקדם, לא הפתרון; אם החבילות לא מגיעות לעולם, מדיניות המקור כלל לא נבדקת. בדקו זאת עם ip route get 10.40.0.53 בלקוח.

הוסיפו מסלול מארח אחד במקום לתרגם הכול

המדריך של Pritunl ל‑DNS פרטי מתאר את התרופה הצרה: מסלול /32 עם NAT עבור כתובת הרזולובר, כאשר אותה כתובת נבחרת כשרת ה‑DNS של הלקוחות. המסלול משנה את המקור שהרזולובר רואה רק עבור תעבורת DNS. תעבורת היישומים שומרת על התכנון המשמר את המקור שבחרתם עבורה.

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

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

החליטו אם השרת או הלקוח שולח את השאילתה

Pritunl מתעד גם סידור פרוקסי DNS הקשור ל‑VPN Client DNS Mapping, שבו השרת מעביר שאילתות עליונות עבור לקוחות. במודל הזה המקור העליון שייך להקשר הרשת של השרת עצמו, וחריגה בצד הלקוח היא הפתרון השגוי.

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

בדקו חיפוש פרטי, לא דף ווב ציבורי

לאחר החלת השינוי והתחברות מחדש, בדקו את תצורת הרזולובר האפקטיבית של הלקוח, ואז פתרו שם שאתם יודעים שקיים רק באזור הפרטי. dig intranet.example.net בלי שרת מפורש מראה מה הלקוח באמת משתמש בו. אחריו שלחו בקשה לכתובת שהחיפוש החזיר, כי פתרון וגישה לשירות הם שלבים נפרדים. דפדפן שטוען אתרים ציבוריים דרך DNS-over-HTTPS לא מוכיח דבר על נתיב הרזולובר הפרטי של מערכת ההפעלה. גם רזולובר משני ציבורי אינו סמכות לאזור פנימי.

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

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