ערוץ בקרה מול ערוץ נתונים ב-VPN: בדקו את השכבה הנכונה

הלקוח אומר מחובר, השרת רואה עמית, והאפליקציה עדיין לא מגיעה לשום מקום. בנקודה הזו השאלה המועילה אינה איזו צופן להחליף, אלא איזה ערוץ נכשל. OpenVPN נותן שם מפורש לשתי פונקציות: ערוץ בקרה שמנהל משא ומתן על החיבור ומנהל אותו, וערוץ נתונים שנושא את התעבורה המוגנת. IKEv2 מבטא פיצול דומה באמצעות אגודת ה-IKE ואגודת ה-CHILD. בצעו את הבדיקות שלהלן לפי הסדר, כי תיקון של נתיב הנתונים שמוחל על תקלה בנתיב הבקרה מבזבז חלון שינוי.

תנו שם לערוץ לפני שאתם מדבגים אותו

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

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

בדקו את חילופי הבקרה

ודאו שלחיצת היד מושלמת וששני הצדדים מסכימים על התעבורה, גרסת TLS ושיטת האימות. יומני OpenVPN מדפיסים שורות נפרדות לערוץ הבקרה ולערוץ הנתונים, ובשורת הבקרה מופיע חוסר התאמה בתעודה, בגרסת TLS או ב-tls-crypt.

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

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

בדקו את ערוץ הנתונים בנפרד

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

לאחר מכן בדקו מה ההפעלה התקינה. PUSH_REPLY יכול להוסיף מסלולים, שרת DNS והוראת redirect-gateway, וכל אחד מהם יכול לשלוח תעבורה למקום שהאפליקציה לא יכולה להשתמש בו. ב-IKEv2 השאלה המקבילה היא אם הבוררים של אגודת CHILD תואמים לכתובות בזרימה בפועל.

tls-auth ו-tls-crypt שייכים לערוץ הבקרה. הם מאמתים או מצפינים את לחיצת היד ואינם בוחרים את צופן הנתונים של האפליקציה. אם תוסיפו אחד מהם בציפייה לשינוי בנתיב הנתונים, הדבר היחיד ששיניתם הוא לחיצת היד.

קשרו בין השמות ל-IKEv2 ול-OpenVPN

ל-IKEv2 יש אגודת אבטחה של IKE ואגודת CHILD אחת או יותר. אגודת IKE נושאת את חילופי הבקרה; אגודת CHILD נושאת את התעבורה המוגנת ואת הבוררים שלה. עליהן מנהלים משא ומתן ומחדשים מפתחות לפי לוחות זמנים נפרדים, ולכן אחת יכולה להיות תקינה בזמן שהאחרת אינה.

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

שמרו על המיפוי מפורש בהערותיכם: ערוץ הבקרה של OpenVPN ואגודת IKE SA הם צד הניהול, ערוץ הנתונים של OpenVPN ואגודת CHILD SA הם צד התעבורה, והמימושים אינם ניתנים להחלפה גם כשהפיצול נראה דומה.

הפסיקו לשנות את ההגדרה הלא נכונה

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

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

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