פתרון לעקיפת מערכות התעדוף של ספקי האינטרנט

[jpost]

בבדיקת המהירות של הפורום ניתן היה לראות בבירור שהמערכות של התעדוף אינן פועלות על פורט 80 שמיועד לגלישה.
בהשוואת המהירות בין HTTP ל HTTPS וגם בין HTTP ל FTP ניתן היה לראות שבשעות העומס ה HTTP עבד תקין בזמן ש FTP ו HTTPS הואטו.

הפתרון שאני מציע הוא שימוש בפורט 80 גם לשירותים אחרים כגון FTP HTTPS NEWS וטורנט.
הבעיה היא שהשירותים האלה ניתנים ע"י צד שלישי שנותן אותם בפורט שונה מ 80.

לכל Packet יש Source Port ו Destination Port. מערכות התעדוף אינן מודעות לכיווניות של המידע. ברגע שאחד מהפורטים הוא 80, לא מבוצעת האטה.

הפתרון הוא לשנות את ה Source Port בנתב ע"י שימוש ב NAT מיוחד, כך שכל ה Packet שיוצאים מהבית לכיוון הרשת הם בעלי Source Port עם ערך 80.
אומנם ה Destination Port יהיה בעל הערך הרגיל, בו ניתנים השירותים השונים, אבל מערכות התעדוף של הספק יתייחסו ל Packet כ HTTP ולא יאטו אותו.

[urisavor]

רעיון נחמד
השאלה אם הם לא מחפשים http header בתוך הpacket. זה תלוי במערכת ה dpi ורמת התחכום שלה. יש כאלו (אין לי ידע לגבי מה מותקן בישראל) שגם ינהלו state machine, ואז לא תהיה להן בעייה לעלות על הטריק הזה.
כמו-כן, זה לא יעבוד ליותר מאפליקציה (ומחשב!) אחת בו-זמנית, כי הNAT לא יוכל להבדיל עבור מי הגיעה התשובה (לשם כך בדיוק הוא משתמש בsource port).

בכ"ז - שווה לנסות.

[Shed]

כמו שנאמר כבר, ביצוע NAT שמוציא את כל התעבורה ב-source port אחיד הוא למעשה pat ולא nat של אחד לרבים.
במיקרים מסויימים אפשר להשתמש ב-PAT עבור רשת פנימית עם מספר רב של מחשבים, בתנאי שכל אחד מהמחשבים גולש ליעד שונה.

בנוסף, מערכות bw throttling רבות יודעות להסתכל ולהקשיב עד לרמת האפליקציה, כולל state-full inspection ובדיקת תאימות ל-RFC. המערכות האלה נמצאות בשימוש רוב ה-hotspots בתשלום ברחבי העולם (על מנת למנוע dns tunnels), ובלא מעט ספקי אינטרנט, כולל בישראל. ל-allot הישראלית יש מוצר כזה שנקרא netenforcer.

[urisavor]

גם לAllot ...

[jpost]

Shed, מדובר על פתרון ביתי ולא עבור hotspots או חברות.
בנוסף זה לא רק PAT אלא NAT רגיל שיש כבר בנתב בשילוב מרכיב של PAT מתוחכם.

ניתן להתגבר על גלישה ליעדים זהים ממספר מחשבים ע"י אי ביצוע שינוי Source Port ליעדים שיעדם הוא כבר בפורט 80.
במידה שיש גישה ממספר מחשבים ליעד זהה (בפורט אחר מ 80) לא יבוצע שינוי Source Port באותו מקרה.

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

[jpost]

urisavor,
ה NAT/PAT לפורט 80 יכול לשמש למספר גדול של אפליקציות ומחשבים, כל עוד הם משתמשים בשירותים שונים.

NAT רגיל ממיר ביציאה
LAN Source IP + LAN Source Port -> WAN Source IP + Random WAN Source Port

ובחזור חיפוש בטבלה לפי מפתח WAN Destination Port
והחלפה של
LAN Destination IP + LAN Destination Port במקוריים


ה NAT המיוחד ממיר ביציאה
LAN Source IP + LAN Source Port -> WAN Source IP + Source Port 80

ובחזור חיפוש בטבלה לפי מפתח של Source IP + Source Port
והחלפה של
LAN Destination IP + LAN Destination Port במקוריים

[Shed]

פתרון כזה הוא מאוד פשוט למימוש על ידי iptablesו ומחשב ישן (שמריץ לינוקס, אלא מה?). היו לי בעבר כמה וכמה מימושים דומים לצרכים פרטיים שעשו עוד כל מיני פעולות על הפאקטים היוצאים והנכנסים.

זה נכון שיש קופסאות שונות בנקודות שונות ברשת, אבל בכל מקרה יש קופסא שיושבת בדיוק בקצה ה-last mile בין היוזר למרכזייה ותפקידה הוא לזהות את התעבורות השונות ולתעדף אותן בהתאם. במקרה של NV למשל, מדובר בשרתי ה-lns / pppoe AC שיושבים בחיפה. הקופסאות האלה יכולות, בהגדרה, לראות את כל התעבורה ולבצע בדיקת תאימות ל-RFC מלאה.

מאז שסקייפ ו-imesh התחילו לבצע תעבורות P2P על גבי פורט 80, תוך שימוש ב-http tunnels הכלים המתוחכמים הפכו להיות נפוצים יותר ויותר. ספקיות האינטרנט יודעות היטב שהן לא יכולות להסתמך על בדיקות ברמה 3 ו-4 בלבד על מנת לבצע קלאסיפיקציה מלאה של התעבורה, ושהן צריכות לנבור בפאקטים, לפעמים עד שכבה 7.

[jpost]

Shed,

יש לך שורה פשוטה של iptables שמבצעת את זה ?
חשבתי לכתוב איזה chain פשוט, אבל אם יש לך רעיון איך לבצע את זה רק בעזרת ה iptables אני אשמח.

[drorar]

כל מילה של Shed. זה לא יעבוד.

[jpost]

כל מילה של Shed. זה לא יעבוד.

...

באיזה ספק ?

[drorar]

בכל אחד מהגדולים בטוח לא. גם בקטנים הייתי שם את הכסף שלי על "לא".