Netgear OpenVPN: TUN וTAP מאזינים בפורטים שונים
קושחה של ראוטרים ביתיים יכולה לפרסם מאזינים של TUN וTAP בפורטים שונים. פרופיל שמכוון למאזין הלא נכון נכשל בזמן הרבה לפני שנבדקת תעודה כלשהי.
טלפון מתחבר ל-VPN של הראוטר בלי תלונה, ומחשב נייד שמשתמש בפרופיל מאותו עמוד הורדה נכשל בזמן. שום דבר בתעודות לא השתנה בין שתי הניסיונות, כי המחשב הנייד מעולם לא הגיע לנקודה שבה לתעודות יש משמעות. הראוטר מפרסם מאזינים נפרדים ל-TUN ול-TAP, ופרופיל עובד חייב לבחור את זה ששייך לסוג ההתקן שלו.
להחליט אחרי איזו משלוש תקלות אפשריות לרדוף זו כל העבודה כאן: הפורט, סוג ההתקן, או משא ומתן הצופן של ערוץ הנתונים.
שלושה דברים שחייבים להתאים
סוג ההתקן, שורת הממשק של הפרופיל ופורט המאזין יוצרים בחירה אחת, לא שלוש. פרופיל שמצהיר dev tun ומכוון למאזין TAP לא יכול להשלים את החיבור, וההפך נכשל באותה צורה. עבור הדגם והקושחה שלך, קרא את הפורט מעמוד ה-VPN של הראוטר עצמו ולא ממדריך, כי המספרים זזים בין גרסאות. רשום את הדגם ואת גרסת הקושחה ליד המספר הזה כדי שהאדם הבא יוכל לאמת אותו.
דוחות מהשטח מזכירים זוג כמו 12973 ל-TUN ו-12974 ל-TAP בקושחה אחת, ומספר אחר באחרת. קרא אותם כהוכחה שהגרסאות שונות, לא כקבועים להעתקה. הפרופיל צריך אז את שם המארח המתאים למרחק: שם ה-DNS הדינמי של הראוטר ולא כתובת WAN שתשתנה.
לאחר תיקון הפורט ושורת הממשק, הפרופיל נראה כמו תצורת לקוח רגילה עם שורת remote אחת ושורת dev אחת. אם השתיים לא מתאימות, שום כמות של ניסיונות חוזרים לא מייצרת חיבור.
קרא את הלוג לפי הסדר שבו הוא מודפס
לקוח OpenVPN מדווח על אירועים לפי הסדר שבו הם קורים, כך שהשורה האחרונה לפני הדממה מזהה את השכבה לבדיקה. כשההרצה מסתיימת ב-TLS Error: TLS key negotiation failed, או פשוט ממתינה לתגובה ראשונה ומוותרת, השוואת תעודות מעולם לא התרחשה. זה מצביע על נגישות, על המאזין, או על פורט שאין מאחוריו כלום. שום דבר מזה לא מתוקן על ידי החלפת קובץ ה-CA.
הרצה שמגיעה ל-VERIFY OK ואז נכשלת נמצאת במקום אחר לגמרי, עם הסיבות שלה. הפרדת שתי התוצאות האלה לפני נגיעה בקבצים מונעת את העיקוף הקלאסי דרך חבילות תעודות שלא נשאלו מעולם. לאחר שה-handshake הושלם אבל המנהרה לא עולה, הסתכל על משא ומתן הצופן ולא על נגישות.
הוסף את רשימת הצפנים שלקוח מודרני מצפה לה
לקוחות OpenVPN אחרונים דוחים ברירות מחדל ישנות שהקושחה הביתית עדיין מציעה, והתסמין הוא כשל במשא ומתן מיד אחרי handshake מוצלח. התיקון הוא שורת פרופיל אחת שמנקיבה מה הלקוח יקבל: הגדר את data-ciphers ל-AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 ו-AES-128-CBC בסדר הזה. כל אלגוריתם שהראוטר לא מיישם פשוט לא נבחר לעולם, כך שרשימה ארוכה יותר לא עולה דבר מלבד משא ומתן קצת יותר ארוך.
רישום צפנים לא מלמד את הראוטר אחד שאין לו. אם המשא ומתן עדיין נכשל, בדוק אם בעמוד הראוטר יש הגדרת צופן משלו ואם ההגדרה הזו כוללת לפחות רשומה אחת שהלקוח מקבל. שתי רשימות בלי איבר משותף יוצרות בדיוק את אותו כשל כמו פורט שגוי, ולכן שני הקצוות ראויים למבט.
ייבא פעם אחת במקום לערוך עותקים ביד
ייבוא הקובץ המתוקן ל-NetworkManager מונע תיקייה מלאה בפרופילים שונים במקצת: nmcli connection import type openvpn file client.ovpn, ואז העלה אותו בשם. שמור את הפרופיל המיובא כעותק היחיד שאתה עורך, ומחק את הכפולים שמצטברים מהורדות חוזרות.
לאחר מכן בדוק מבחוץ ל-LAN. התחברות מאותה רשת מוכיחה מעט מאוד, כי ייתכן שהתעבורה לא עוברת במנהרה כלל. ודא שבקשה אכן יוצאת דרך הראוטר, ולא רק שהלקוח מציג מצב מחובר.
החלט מה לעשות עם אזהרות
קושחה ביתית בדרך כלל טובעת רשות תעודות משלה, ולקוחות מתלוננים על אימות בדרכים שהקושחה לא יכולה לדכא. שפוט אם התלונה הזו חשובה למה שאתה מגן עליו במקום להתייחס לכל אזהרה כקטלנית, ואל תכבה אימות באופן גלובלי כדי להשתיק הודעה אחת. אזהרה שהערכת היא סיכון מתועד; הגדרת אימות שהשבתת אינה מתועדת.
כשהקושחה לא מספקת שום דרך נתמכת לתקן אזהרה שבאמת חשובה, הפער הזה תומך באירוח ה-VPN במקום אחר. הבחירה בין תיקון הפרופיל, קבלת האזהרה והעברת נקודת הקצה היא החלטה על כמה אתה סומך על התעודה ההיא. קבל אותה בכוונה, ורשום איזו אפשרות בחרת, במקום ללחוץ דרך דיאלוגים עד שהסמל הופך לירוק.