פרופיל נעול לשרת נכשל מאחורי פרוקסי TLS: איזה דור?
Access Server 2.8 ו-2.9 בונים פרופילים נעולים לשרת בדרכים שונות. החליטו איזה נתיב הפרוקסי שלכם שובר לפני שתשנו את החזית.
משתמש אחד יכול להתחבר ואחר לא, דרך אותו פורטל, באותו יום. לשניהם יש פרופילים נעולים לשרת, שניהם על אותה גרסת Access Server, וההבדל היחיד הוא מתי נוצר הפרופיל שלהם. זהו הדפוס שכדאי לזהות, כי "נעול לשרת" מציין מדיניות ולא רצף חיבור. Access Server סיפק שני דורות של אותו חפץ, ופרוקסי הפוך TLS עומד לפני אחד מהנתיבים שלהם בלבד. שלושה תנאים קובעים באיזה ענף אתם נמצאים.
שני דורות, שני רצפי חיבור
בעיצוב הישן, שתקף עד 2.8, הקובץ המיובא הוא פרופיל פסאודו. OpenVPN Connect משתמש בו כדי לאמת מול ה-API של Access Server ב-HTTPS, מקבל פרופיל זמני נעול למשתמש ואסימון הפעלה, ורק אז מקים את ה-VPN. שני תעבורנים פועלים ברצף, והראשון הוא בקשת אינטרנט רגילה.
הפורמט שהוצג עם 2.9 אינו מבצע את האתחול הזה לכל חיבור. זהו פרופיל מקורי שיכולים להשתמש בו OpenVPN לקוחות תואמים, ולא רק OpenVPN Connect. הורדה או ייבוא שלו דרך URL עדיין עשויים לכלול HTTPS — זהו שלב פרסום, לא משיכת פרופיל זמני לכל חיבור.
| Older server-locked (≤2.8) | Newer server-locked (2.9+) | |
|---|---|---|
| Before the tunnel | Web API call with credentials | Nothing; the profile is already local |
| Client requirement | OpenVPN Connect | Any compatible client |
| What a TLS web proxy can break | The bootstrap, before any VPN attempt | Download only, not the connection |
| Expected HTTP log on connect | A request from the client | Often nothing at all |
שדרוג אינו משכתב בהכרח פרופילים שכבר הונפקו, לכן גרסת שרת נוכחית עדיין עשויה לחלק את החפץ הישן. גרסת השרת אומרת לכם מה אפשרי, לא מה המשתמש הזה ייבא.
שלושה תנאים שבוחרים את הענף שלכם
התנאי הראשון הוא הדור של החפץ. בקשו את הקובץ, ראו כיצד נוצר, וציינו את גרסת הלקוח שייבא אותו. אם אינכם יכולים לקבוע את הדור מהקובץ, פרופיל חדש שהונפק לחשבון בדיקה יאמר לכם מה השרת מייצר היום, וזה מידע שונה מזה שבידי המשתמש שנכשל.
התנאי השני הוא מה החזית שלכם מסיימת בפועל. פרוקסי הפוך HTTP בשכבה שבע שמפרק TLS אינו אותו אובייקט כמו מעביר TCP בשכבה ארבע, וגם לא מעביר UDP. הסידור הרגיל של Access Server בפורט 443 גורם לדמון OpenVPN TCP לזהות תעבורת דפדפן ולהעביר אותה לשירותי האינטרנט, ולכן הכנסת מסיים HTTPS לא קשור מלפנים אינה שומרת על טיפול הפרוטוקול של אותו דמון. שיתוף המספר 443 אינו הופך שני עיצובים לשקולים.
התנאי השלישי הוא היכן הכשל נוחת. כשל לפני VPN וכשל בערוץ הבקרה נראים דומים בלקוח שאומר רק "מתחבר", אך הם משאירים ראיות במקומות שונים. אם הפורמט הישן פעיל, האתחול הוא מועמד. אם הפורמט החדש פעיל, יומן גישה לאינטרנט ריק הוא צפוי ואינו מוכיח דבר לשום כיוון.
כשהחפץ ישן: האתחול נכשל ראשון
קראו את השגיאה בפועל של הלקוח ולא את מצבו הסופי. השדות המעניינים הם שגיאת HTTPS, זהות השרת שהלקוח ציפה לה, היעד שאליו הלכה הבקשה, והאם אימות התעודה הושלם. אחר כך התאימו אותם ליומני שירות האינטרנט והפרוקסי בצד השרת.
הגעה של דפדפן לדף הכניסה אינה ראיה לכך שאימות ה-API של הלקוח הזה הצליח. אלו בקשות שונות, עם ציפיות תעודה שונות ולעתים קרובות שמות מארח שונים. אם הפורטל מוגש כראוי והלקוח עדיין נכשל, המחלוקת בנתיב האתחול, לא בסיסמה של המשתמש.
אל תגרמו להשוואה לעבור על ידי השבתת אימות TLS או הקלה של מדיניות האימות. זה הופך אי-התאמה בתצורה שניתן לאבחן לנתיב שעובד אך אינו מאומת, וזה בדיוק השינוי שהופך בדיקה זמנית לחור קבוע. תיעוד פרופילי החיבור של Access Server מתאר את שני הדורות ואת זרימת הפרופיל הזמני, וזו ההפניה לבדוק לפני שמניחים שהפרוקסי אשם.
כשהחפץ חדש: קראו את ערוץ הבקרה במקום
עם פרופיל בסגנון 2.9, הלקוח הולך ישר לנקודת הקצה המקורית של ה-VPN. חקרו את נקודות הקצה בפרופיל, את התעבורן שבשימוש, ואת שגיאת ערוץ הבקרה. אם הלקוח אינו שולח בקשת HTTP מעולם, זה עקבי עם העיצוב ואינו תסמין.
כאן גם שאלת הפרוקסי משנה צורה. פריקת HTTPS אינה יכולה לשבור זרם TCP בלבד שהיא אינה רואה, אך היא עדיין יכולה לשבור את ההורדה שמפרסמת את הפרופיל, ומעביר TCP בלבד לא יישא UDP כלל. בדקו איזה תעבורן הפרופיל מבקש לפני שמסיקים שהחזית לא רלוונטית.
העברת TLS לזרם בודד היא סידור צר. היא אינה מספקת העברת UDP, ואינה משחזרת את התנהגות העברת השירותים של הדמון עצמו בפורט 443. אם החזית שלכם עושה אחד מאלה, אמרו איזה, כי התיקון שונה.
תיקונים שנשארים צרים
הבדיקה הפחות פולשנית היא ליצור פרופיל חדש נתמך לחשבון בדיקה ולהתחבר דרך נקודת הקצה המקורית המיועדת עם אותן דרישות אימות. אם זה עובד והפרופיל הישן השמור לא, הפרדתם את החפץ מהשרת ומהפרוקסי בצעד אחד.
הפצת פרופיל נעול למשתמש מסירה לחלוטין את התלות באתחול הישן, כי אין חילופי פרופיל זמני שיכול להיכשל. יש להנפיק אותו למשתמש המיועד, לעולם לא להעתיק ממנהל, והוא משנה למה הלקוח מורשה, אז התייחסו אליו כהחלטת מדיניות ולא כעקיפה.
אחר כך תקנו את פריסת הפרסום כך שכל נתיב נדרש קיים: נתיב האינטרנט להורדות ולשימוש בפורטל, ונתיב ה-VPN המקורי על התעבורן שהפרופילים מצפים לו. החזיקו את עבודת הפרוקסי בשכבה אחת. מנהרה נעולה למשתמש שעובדת מוכיחה שהנתיב הזה עובד; היא אינה מוכיחה שכל סידור פרוקסי תומך בכל דור, וכשל אתחול ישן אינו דן את הפורמט החדש יותר.
- זהו את הדור של החפץ לפני שנוגעים בפרוקסי.
- קבעו אם הכשל מתרחש לפני המנהרה או בתוכה.
- אשרו מה החזית מסיימת: HTTP, זרם TCP או UDP.
- בדקו פרופיל שהונפק זה עתה מול נקודת הקצה המקורית כשהמדיניות לא משתנה.