DNS של OpenVPN בשער: dnsmasq והיקף חומת האש

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

המאזין הוא שירות מקומי בעל שני כיוונים

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

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

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

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

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic קושר את הכתובות הבודדות ומתמודד עם כך ש-tun0 מופיע מאוחר יותר, מה שחשוב במארח שבו שירות ה-VPN מופעל מחדש. רישום loopback משאיר כלים מקומיים עובדים בלי להוסיף מאזין ציבורי. no-resolv מונע מהדמון לרשת שרתים במעלה הזרם מתצורת הפותר של המארח, ו-no-hosts מונע מהמופע הזה לפרסם את קובץ ה-hosts של השער. אף אחת מהאפשרויות האלה לא נותנת לאיש הרשאה לשאול את השירות.

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

התירו קלט DNS, לא מעבר מנהרה

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

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS עובד מעל TCP כמו מעל UDP, ולכן כלל UDP בלבד משאיר תשובות גדולות נכשלות באופן שנראה לסירוגין. אלה אינן ufw route הרשאות, ואסור שהן יהפכו להתרה רחבה על tun0. הסדר חשוב כמו התוכן: כלל מוקדם שמפיל את כל הקלט מ-tun0 עדיין מנצח, והוספת התרה מתחת להפלה סופית לא יוצרת דבר.

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

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

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

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

דחפו את האפשרות, ואז בדקו את המסירה

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

push "dhcp-option DNS 10.90.0.1"

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

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

בדקו את מה שבניתם בפועל

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

אם השאילתות הישירות עובדות והיישום עדיין נכשל, התקלה במסירה ולא בשרת:

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

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