StrongSwan דוחף כתובת DNS שה-Mac לא יכול להגיע אליה

הכול עובד עד שמישהו פותח MacBook. המנהרה מוקמת, מארחים פנימיים עונים לפי כתובת, ופתרון השמות מת. ב-iPhone אותו פרופיל מתנהג באותה דרך, בעוד לקוחות Windows ו-Linux תקינים. בדרך כלל האשם הוא מאפיין ה-DNS הנדחף: השרת מחלק את כתובת הממשק הציבורית שלו, ולקוח IKEv2 של Apple אינו שולח לשם שאילתות דרך המנהרה. העבר את הפותר לתוך המאגר והתסמין נעלם בלי לגעת בלקוח.

התסמין מצביע על הכתובת הנדחפת

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

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

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

גזרו את הפותר מטווח ההקצאה

תנו למנהרה תוכנית כתובות שבה הפותר הוא חבר בתת-הרשת של המאגר עצמו, ואז הקצו את הכתובת הזו כך שלעולם לא תוקצה ללקוח. בדוגמה הזו המאגר הוא 10.180.7.0/24, השרת מחזיק 10.180.7.1, וההקצאות מתחילות ב-10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

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

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

קשרו את הפותר וסגרו את פורט 53

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

interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuse

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

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

iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

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

ודאו מה הלקוח באמת קיבל

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

swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.example

השאילתה הישירה מוכיחה שהפותר עונה על כתובת המאגר ממארח שיכול להגיע אליו. היא אינה מוכיחה שה-Mac בחר בשרת הזה. ב-macOS scutil --dns מציג פותרים לפי שירות תחום והוא מאלף יותר מלוח הסיכום; ב-Windows Get-DnsClientServerAddress מראה אם מתאם המנהרה קיבל את הערך הנדחף.

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