מה באמת עושה שדה ה-Proxy בפרופיל VPN של Apple
מילוי שדה פרוקסי לא הופך VPN ל-HTTP. יש שני חיבורים, והשדה מגיע רק לאחד מהם.
מילוי שדה ה-Proxy בהגדרת VPN של Apple מרגיש כאילו הוא אמור לנתב את המנהרה דרך פורט אינטרנט. הוא לא. השדה בוחר מתווך ברמת היישום לתעבורה שאפליקציה תואמת בוחרת לשלוח לשם. לעומת זאת, החיבור של לקוח ה-VPN עצמו לשער שלו נקבע לפי הפרוטוקול, המאזין והתעבורה שהגדרתם, ואלו החלטות נפרדות.
שני חיבורים, שני בעלים
כל הגדרה כזאת כוללת חיבור מהלקוח לשער וחיבור מהאפליקציה ליעד. הקטע Proxy מדבר על השני, למרות שהוא יושב באותו פרופיל כמו הראשון.
| Connection | What decides its behaviour |
|---|---|
| VPN client to VPN gateway | The supported protocol, the listening port, the transport and the network policy in between |
| Application to a selected proxy | The application's own proxy support, the configured proxy policy, and the route to that next hop |
מדריך הגדרות הפרוקסי של Apple מפרט HTTP, HTTPS, SOCKS ותצורת פרוקסי אוטומטית, וזה תיאור של בחירות פרוקסי של אפליקציות. אף אחד מהערכים האלה לא אומר דבר על איך חבילת IPsec או WireGuard מגיעה לשער.
הנה בדיקה מהירה שפוטרת את השאלה. נקבו בפורט ובפרוטוקול שלקוח ה-VPN מדווח ביומן שלו. אם השורה הזאת עדיין אומרת UDP 500 או UDP 51820, שדה הפרוקסי לא שינה בה דבר.
מתי השדה הוא הכלי הנכון
יש מקרה אמיתי שבו פרוקסי עומד לפני המנהרה, אבל זו תכונה של הלקוח ולא שדה בפרופיל. המדריך של OpenVPN מתעד את --http-proxy עבור חיבורי TCP שמועברים דרך פרוקסי HTTP CONNECT. השימוש בו דורש את אפשרות הלקוח המתאימה, שער שאפשר להגיע אליו בדרך הזאת ופרוקסי שמתיר CONNECT לפורט שבשימוש.
אם הלקוח שלכם חושף את האפשרות הזאת והרשת מתירה CONNECT לפורט, זה יכול לעבוד. אם הלקוח לא חושף אותה, מילוי פרוקסי מערכת לא משפיע על המנהרה כלל.
מתי זה לא משנה דבר
פרופיל IKEv2 או IPsec לא הופך למנהרת HTTP מפני ששדה הפרוקסי מלא. גם WireGuard לא, שתבנית התצורה שלו אינה מכירה מושג של פרוקסי. גם שינוי הפורט של השער לא משנה את הפרוטוקול שלו. ונקודת קצה שמשיבה ל-HTTPS רגיל אינה מאזין VPN אוטומטית.
אותה מלכודת תופסת את מי שמעתיק פרופילים מתקופת PPTP ממדריכים ישנים של iPad. האפשרויות עדיין קיימות בממשק; השירות שמאחוריהן כבר לא מדבר בפרוטוקול הזה.
להחליט איזו שכבה לתקן
שאלו איזו שכבה נכשלה לפני שאתם משנים משהו. אם הלקוח לא מצליח להקים הפעלה, הבעיה בתעבורה ושדה הפרוקסי לא רלוונטי. אם המנהרה פועלת אבל אפליקציה אחת לא מגיעה לשרת שלה, כדאי לבדוק את פרוקסי האפליקציה. אם המנהרה פועלת וכל האפליקציות נכשלות, החשודים הם הניתוב וה-DNS בתוך המנהרה.
במקרה הראשון, שאלו את המפעיל איזו תעבורה או רשת חלופית מאושרת הוא תומך. OpenVPN מעל TCP 443 קיים מפני שרשתות מסוימות מתירות רק את זה, והוא עדיין דורש שהשרת יאזין לו.
אל תתייחסו לפורט UDP חסום כאישור לאלתור. שמרו על בדיקות התעודה או הזהות של השער במקום לכבות אותן כדי שלחיצת היד תתאים.
אשרו את שתי השכבות אחת בכל פעם
אשרו קודם את המנהרה: בדקו בעמוד המצב של הלקוח הפעלה שהוקמה ומספר בתים שאינו אפס. אחר כך קראו את הגדרת הפרוקסי ישירות, עם scutil --proxy לתצורה האפקטיבית או networksetup -getwebproxy Wi-Fi לערך השמור. אחר כך בדקו אפליקציה אחת שמכבדת את פרוקסי המערכת ואחת שמתעלמת ממנו, כי הרבה אפליקציות מקוריות מתעלמות ממנו.
שלושה תוצאות, שלושה תיקונים שונים.
אם שתי השכבות מדווחות על הצלחה והאפליקציה עדיין נכשלת, בדקו ניתוב מפוצל, DNS והגדרות הרשת של האפליקציה עצמה. זו שכבה שלישית, וגם היא לא שדה הפרוקסי.