מצב SOCKS של NetGuard מכסה TCP, לא כל פרוטוקול

NetGuard תופס את ממשק ה-VPN של אנדרואיד כדי לסנן תעבורה, ויכול להעביר חיבורים נתמכים לנקודת קצה SOCKS. שתי העובדות האלה נקראות לעתים קרובות כ״הטלפון נמצא ב-VPN״, מסקנה שהמנגנון אינו תומך בה. המסנן רואה מנות; ה-proxy רואה רק את החיבורים שהועברו אליו בפועל. בין שתי הקביעות האלה עומדת כל שאלת הכיסוי.

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

שני נתיבי העברה בתוך אפליקציה אחת

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

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

הצהרה על UDP אינה מימושה

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

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

DNS הוא נתיב שלישי, לא פרט קטן

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

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

תעבורת ה-proxy אינה פרטית אוטומטית

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

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

בדוק כיסוי במטריצה, לא בטעינת עמוד

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

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