למה הפרוקסי של Cloudflare לא יכול לשאת OpenVPN על שם אחד

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

שני שמות, שני סוגי העברה

תנו לאתר רשומה דרך פרוקסי כדי שתעבורת ה-HTTP וה-HTTPS שלו תעבור דרך Cloudflare. תנו ל-VPN רשומה של DNS בלבד שמפענחת ישירות לכניסת ה-VPN הציבורית, ותנו ללקוח להשתמש בפורט UDP או TCP שהוא הוגדר עבורו.

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

המדריך לפורטים של הרשת של Cloudflare מפרט אילו פורטים הפרוקסי הרגיל של האינטרנט מקבל. הרשימה הזו עוסקת ב-HTTP וב-HTTPS על אותם פורטים, ולא בפרוטוקולים שרירותיים שבמקרה חולקים מספר.

הפורט אינו הפרוטוקול

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

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

רשומת DNS בלבד היא התשובה המשעממת שעובדת, והיא זו שכדאי לפנות אליה קודם.

מכונה אחת עדיין צריכה שני מאזינים

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

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

האישורים הולכים אחרי החיבור שהם מגנים עליו

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

Cloudflare סומך על אישור המקור הזה במצב Full (strict), והוא אינו אישור דפדפן מהימן באופן כללי. אם מישהו מבקר ישירות בשם המארח של DNS בלבד ומקבל אזהרה, זו התוצאה הצפויה של נתיב אמון שהשתנה, ולא הוכחה שההצפנה נעצרה.

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

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

החשיפה הולכת אחרי השם

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

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

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

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