OpenVPN בפורט 53: שלוש שיחות שאנשים מבלבלים ביניהן
איתור נקודת הקצה, התעבורה המוצפנת ו-DNS שאחרי המנהרה הם שלוש שיחות. זהו איזה שלב נכשל לפני שמחליפים פורט או פותר.
דוחות שאומרים שה-VPN חסום בפורט 53 מערבבים שלוש תצפיות שנכשלות מסיבות שונות. פתרון שם נקודת הקצה קורה לפני שקיימת מנהרה, התעבורה המוצפנת היא שיחה נפרדת, ושאילתות ה-DNS שנעשות אחר כך הן השלישית. לכל אחת חתימת כשל משלה, ורק אחת מהן עוסקת ב-DNS בכלל.
מיין את החבילות לפי מטרה לפני שאתה משנה משהו, כי התיקון הולך אחרי השלב.
שלוש שיחות, מספר פורט אחד
השיחה הראשונה היא חיפוש שם עבור נקודת הקצה: המחשב שלך שואל את הפותר שהוגדר לו היכן נמצא vpn.example.com, והתשובה הזאת מגיעה ב-DNS רגיל לפני שהלקוח שולח חבילת מנהרה אחת. השנייה היא תעבורת OpenVPN עצמה, שמתחברת לכתובת שהחיפוש הניב, באיזה פרוטוקול ופורט שהפרופיל מציין. השלישית קורית אחרי שהמנהרה עולה, כשאפליקציות מבקשות שמות והגדרות הפותר שנדחפו קובעות מי יענה.
שלושתן יכולות להצליח או להיכשל באופן עצמאי. לקוח יכול לפתור את נקודת הקצה שלו היטב ועדיין להיכשל בהגעה למאזין, ויכול להקים מנהרה בזמן שכל חיפוש שם פנימי נכשל משום שהגדרות ה-DNS מעולם לא הגיעו.
| Conversation | When it happens | What has to be true |
|---|---|---|
| Endpoint lookup | Before the client contacts a hostname | An underlying resolver path can answer for the endpoint name |
| OpenVPN transport | During tunnel establishment | The gateway listens on its configured transport, address and port, and nothing filters it |
| Application DNS | During or after the protected session | A resolver the client can reach, plus routing that carries its queries |
קרא את הטבלה כרשימת בדיקה ולא כתיאור. אם שם נקודת הקצה לא נפתר, שום דבר אחר כך לא יכול לעבוד, והמנהרה לא מתחילה.
מספר הפורט לא נותן שם לאפליקציה
פורט 53 נושא DNS לפי מוסכמה, ומפעיל OpenVPN יכול גם לפרסם שם מאזין, וזו בדיוק הסיבה שהמספר הוא מזהה גרוע. הפעלת OpenVPN על UDP 53 היא עדיין הפעלת OpenVPN, ושאילתת DNS לשרת בפורט 53 לא אומרת דבר על האם מנהרה מותרת. שורות proto ו-remote בפרופיל מגדירות את נקודת הקצה החיצונית; מספר הפורט לא מגדיר דבר בעצמו.
זה חותך לשני הכיוונים באבחון: בדיקת UDP גנרית לפורט 53 מוכיחה שפורט עונה, לא ששירות ה-VPN עונה. בדוק עם הלקוח האמיתי והפרופיל האמיתי, כי רק זה מתרגל את לחיצת היד שהשירות מצפה לה.
הוכח את המאזין לפני שאתה מאשים את הרשת
בשרת, ודא מה קשור באמצעות ss -lunp | grep 53 והשווה לפרוטוקול ולפורט של הפרופיל. מרשת הלקוח, הרץ את הלקוח ברמת פירוט גבוהה יותר כדי שהיומן יראה איזו כתובת ואיזו תעבורה הוא ניסה. אם השרת מאזין והחבילות של הלקוח לא מגיעות, הנתיב או המדיניות מסרבים להן, וזו שיחה עם בעל הרשת ולא סיבה להחליף פורט.
פורט אחר עוזר רק כשהשירות באמת מאזין שם והפריסה מתירה זאת. העברת מאזין כדי לחמוק מסינון של רשת מנוהלת היא החלטת מדיניות, לא שלב בפתרון תקלות. שאל את בעל הרשת מה מותר לפני שאתה משנה את השירות, כי מעקף שמפר מדיניות נסגר בכל מקרה אחר כך. רשום את התשובה הזאת ליד הפרופיל כדי שהאדם הבא לא יחזור על הבקשה.
בדוק DNS אחרי המנהרה, בנפרד
ברגע שהמנהרה עולה, בדוק את מצב הפותר בממשק ה-VPN ושאל שם פנימי אחד ושם ציבורי אחד. אם שמות פנימיים נכשלים בזמן שהמנהרה נושאת תעבורה, הגדרות ה-DNS שנדחפו לא יושמו, וזו שאלת אינטגרציה של הלקוח ולא שאלת תעבורה. אם שמות ציבוריים נכשלים ושמות פנימיים עובדים, מדיניות המנהרה המפוצלת עושה את מה שהוגדרה לעשות.
השאר שינויי DNS אצל בעל הפותר. דריסת תצורת פותר מנוהלת כדי להעביר בדיקה אחת עלולה לשבור שמות פרטיים לכל השאר במחשב. אם המנהרה דוחפת פותר והלקוח מתעלם ממנו, תקן את אינטגרציית הלקוח במקום להוסיף רשומה סטטית במקום אחר. רשומות סטטיות מסתירות את הכשל עד שמישהו מחליף רשת. רשום איזה פותר אמור לענות לכל מרחב שמות.