VPN מול פרוקסי: מה כל אחד מכסה ומה לא
VPN מכסה את תעבורת האפליקציות שמנותבת דרכו; פרוקסי מכסה רק את האפליקציה שאתם מגדירים. בדקו כיסוי, הצפנה, DNS והתנהגות בעת כשל לפני שתבחרו.
גם VPN וגם פרוקסי קדמי משנים את הכתובת שהאתר רואה, ושם נגמרות רוב ההשוואות. ההבדל שקובע את ההגדרה שלכם הוא הכיסוי: פרוקסי קדמי הוא מתווך שהאפליקציה שלכם בוחרת להשתמש בו, שלא כמו פרוקסי הפוך שעומד מול אתר, ואילו VPN מעביר כל מה שמערכת ההפעלה מנתבת למנהרה. הצפנה, טיפול ב-DNS והתנהגות בעת כשל נובעים כולם מהחלוקה הזו. בצעו את חמשת הבדיקות האלה לפי הסדר, והראשונה שתיכשל תגיד לכם איזה כלי אתם באמת צריכים.
אילו אפליקציות המתווך מכסה?
תוסף פרוקסי בדפדפן חל רק על פרופיל הדפדפן הזה. לקוחות דואר, מנהלי חבילות ודפדפן נוסף ממשיכים להשתמש בהגדרות שלהם, ואפליקציות מסוימות מתעלמות לגמרי ממשתני הפרוקסי של המערכת. VPN מכסה את מה שטבלת הניתוב שולחת למנהרה, וזה יכול להיות כל האפליקציות או תת-קבוצה במנהרה מפוצלת בהתאם למסלולים ולמדיניות הלקוח.
בדקו את האפליקציות החשובות במקום להסיק מטעינת עמוד אחת. curl https://ifconfig.me עוקב אחר משתני הפרוקסי של הסביבה; אפליקציית שולחן עבודה עשויה שלא. ב-Windows, netsh winhttp show proxy מדפיס את פרוקסי WinHTTP שהשירותים משתמשים בו, וזו הגדרה שונה מזו של הדפדפן.
האם הקפיצה מוצפנת, והיכן TLS מסתיים?
פרוטוקול פרוקסי הוא נקודת מפגש, לא ערובה. SOCKS5 מעביר TCP בלי להצפין אותו, ופרוקסי HTTP פשוט נושא את שורת הבקשה ואת הכותרות בטקסט גלוי. HTTPS דרך פרוקסי משתמש בפקודת CONNECT, ולכן הפעלת ה-TLS שלכם עדיין מסתיימת ביעד ולא בפרוקסי. המדריך של MDN לשרתי פרוקסי ולמנהור מתאר את ההבחנה הזו מצד הפרוטוקול.
VPN מצפין את הקטע שבין המכשיר שלכם לנקודת הקצה שלו. מעבר לנקודת הקצה חלים אותם כללים כמו בכל רשת אחרת, ולכן מנהרה לבדה אינה מגנה על אפליקציה ששולחת פרטי התחברות ב-HTTP פשוט. אף אחד משני העיצובים לא מסתיר חשבון מחובר, קובץ cookie או טביעת אצבע של דפדפן.
curl -v -x http://127.0.0.1:3128 https://example.com/ -o /dev/null
curl -v -x socks5h://127.0.0.1:1080 https://example.com/ -o /dev/nullהפלט המפורט מראה אם curl שלח CONNECT לפורט 443 או GET פשוט עם כתובת URL מלאה. עם socks5h:// שם המארח נמסר לפרוקסי בתוך בקשת SOCKS5 והוא מעביר הלאה TLS שאינו יכול לקרוא, כך שהוא רואה את השם ואת מספר הבתים. דרך פרוקסי http://, כתובת https:// היא CONNECT, ולכן גם הפרוקסי הזה רואה את שם היעד ואת הנפח, אך לא את הבקשה או את גוף התגובה.
איזה פותר רואה את השם?
פתרון שמות יכול להתרחש מקומית לפני שהבקשה יוצאת, או מרחוק בפרוקסי. עם curl, socks5h:// שולח את שם המארח לפרוקסי ואילו socks5:// פותר אותו קודם מקומית. הגדרות הפרוקסי של הדפדפן מציעות אפשרות DNS דומה, וקבצי PAC יכולים לנתב מארחים שונים בדרכים שונות.
שני פרוטוקולים יכולים לעקוף פרוקסי בלי שום תצורה שגויה. WebRTC אוסף מועמדים דרך STUN, ו-QUIC מריץ HTTP/3 מעל UDP, שפרוקסי TCP אינו יכול לשאת. הדפדפן יחזור ל-TCP אם UDP 443 חסום, ולכן חסימת UDP 443 בחומת האש של המארח (או בנתב לרשת שלמה), ולא דגל בדפדפן, היא הדרך האמינה להשאיר את HTTP/3 בתוך מסלול הפרוקסי.
בדקו את הפותר מנקודת המבט של היעד, לא של המחשב הנייד שלכם. בקשה שמגיעה עם כתובת היציאה של הפרוקסי אך עם שם שנפתר מקומית עדיין מספרת לפותר המקומי אילו אתרים אתם מבקרים.
מה קורה כשהמתווך נכשל?
פרוקסי מפורש נכשל סגור: עצרו את תהליך הפרוקסי והדפדפן או האפליקציה מחזיר שגיאת חיבור במקום לצאת ישירות. הגדרות PAC ו-WPAD הן אלה שנכשלות פתוחות - אם לא ניתן להביא את הסקריפט, הלקוח נופל חזרה ל-DIRECT והאתר רואה שוב את הכתובת האמיתית שלכם. VPN יכול להיכשל פתוח או סגור בהתאם ללקוח ולשאלה אם מתג הרג או כלל חומת אש פעילים.
בדקו את מקרה הכשל בכוונה: עצרו את שירות הפרוקסי וטענו מחדש; אם אתם מקבלים עמוד שגיאה במקום טעינה ישירה, כוונו את כתובת ה-PAC למארח שאינו נגיש כדי לראות את הנפילה לאחור. אם העמוד עדיין נטען במסלול הרגיל שלכם, הפרוקסי אינו מציע הגנה מפני התקלה של עצמו, וזו תכונה שכדאי להכיר לפני שמסתמכים עליו.
הסדר קובע מה האתר רואה. פרוקסי שהתעבורה היוצאת שלו עוברת ב-VPN משאיר לאתר את כתובת נקודת הקצה של ה-VPN; הציבו את הפרוקסי מחוץ למנהרה (VPN לפרוקסי במארח מרוחק) והאתר יראה במקום זאת את כתובת היציאה של אותו פרוקסי. כך או כך, שתי הקפיצות יכולות לרשום דברים שונים.
חמש בדיקות, לפי הסדר
רשימת הבדיקה שלמטה היא כל ההחלטה במקום אחד. הכיסוי בא ראשון משום שהוא מסלק את רוב אי-ההתאמות: אם האפליקציה שחייבת להיות מכוסה אינה מכבדת את ההגדרה, שום דבר בהמשך הרשימה לא יציל אותה.
| Check | Forward proxy | VPN |
|---|---|---|
| What is covered | The app or browser you configure | Traffic the OS routes into the tunnel, all or split |
| Encryption scope | Protocol-dependent; SOCKS5 alone encrypts nothing | Device to VPN endpoint |
| DNS path | Local or remote, depending on the setting | Normally inside the tunnel |
| Failure mode | Explicit config: connection error; PAC/WPAD: DIRECT fallback | Client policy: fail-open or kill switch |
| What the site sees | The proxy's exit address | The VPN endpoint's exit address |
לאחר מכן אשרו את התוצאה עם האפליקציה שגרמה לשינוי. טענו עמוד בדפדפן המוגדר, הביאו את אותו עמוד עם curl, והשוו את הכתובת שכל אחד מדווח עליה. אם הם חלוקים, עדיין פועל תוסף, כלל PAC או עקיפה ברמת האפליקציה, ושום כוונון מנהרה לא יתקן זאת.
רשמו מה הגדרתם: אילו אפליקציות משתמשות בפרוקסי, אם ה-DNS מקומי או מרוחק, אם UDP חסום, ומהי התנהגות הכשל. המלאי הקטן הזה הוא מה שמאפשר את ההשוואה הבאה, כי „כתובת ה-IP השתנתה“ מעולם לא אמר לכם איזו מחמש הבדיקות האלה עברה.