הגדרת Squid Proxy עבור מטמון ובקרת גישה

הגדרת פרוקסי מטמון קדמי עם בקרת גישה

חשוב על זה: כאשר עשרות שרתים ב-VPC מורידים בו-זמנית חבילות ממאגרים חיצוניים, התעבורה רוויה את הערוץ, וכל בקשה חוזרת גורמת לעלויות יציאה נוספות. לצוות המהנדסים המוסמכים שלנו יש ניסיון של 7+ שנים בהשקת פרוקסי ייצור ויותר מ-40 פרויקטים מוצלחים שהטמיעו Squid. אנו מגדירים את הפרוקסי כפרוקסי מטמון קדמי שפותר בעיה זו: הוא מגיש נתונים ממטמון מקומי, ומפחית תעבורה חיצונית ב-60-80%. עבור אשכול טיפוסי של 50 שרתים, זה יכול לחסוך יותר מ-2,000 דולר בחודש בעמלות יציאה. בנוסף, השרת מספק שליטה מלאה—רשימות לבנות של דומיינים, חסימת פורטים, ובדיקת HTTPS באמצעות SSL Bump. הפתרון עובד עבור אשכולות קטנים ותשתיות ארגוניות עם אלפי מארחים. אנו מבטיחים שיעור פגיעה של לפחות 70% תוך שבועיים. בקשו ביקורת על התשתית הנוכחית שלכם—נקבע את פוטנציאל החיסכון בתעבורה.

בעיות שאנו פותרים

עומס בערוץ החיצוני

כל שרת ברשת פרטית מוריד באופן עצמאי את אותם חבילות (apt, pip, npm, תמונות Docker). ללא פרוקסי, זה מסתכם בעשרות גיגה-בייט של תעבורה כפולה מדי חודש. Squid עם מטמון ufs על SSD או rock על RAM-disk מגיש קבצים מאחסון מקומי, ומפחית את העומס על הקישור החיצוני פי 5–10.

חוסר בקרת גישה

שרתים בתת-רשת מבודדת לא צריכים לקבל גישה ישירה לאינטרנט. הפרוקסי דרך ACL (dstdomain, url_regex) מגביל משאבים מותרים. אנו משתמשים ברשימות לבנות, קבצי רשימות לבנות, ואינטגרציה עם Active Directory דרך ntlm_auth לאימות גרעיני.

בדיקת תעבורת HTTPS

ללא SSL Bump, לא ניתן לראות מה מועבר בתוך חיבורי HTTPS. הפרוקסי שלנו עם מצב bump מפענח תעבורה, ומאפשר שמירת משאבים מאובטחים במטמון וחסימת תוכן זדוני. עם זאת, אנו מיישמים bump רק כאשר יש לכך הצדקה—עבור מאגרים קריטיים או לפי מדיניות אבטחה.

כיצד אנו מגדירים את הפרוקסי: מקרה מבחן

מהניסיון שלנו: לקוח עם 50 מכונות וירטואליות ב-Yandex Cloud, כולן מתעדכנות ממאגרים חיצוניים. מחסנית: Ubuntu 22.04, Squid 6.6, Terraform לפריסה. המהנדס שלנו:

1. פריס מופע Squid עם דיסק SSD של 200 GB למטמון (מעבד 3.5 GHz, 16 GB RAM, רשת 1 Gbps).
2. הגדיר squid.conf עם ACLs לתת-רשתות פרטיות וקובץ רשימה לבנה של 30 דומיינים (מאגרים, Docker Hub, GitLab).
3. הפעיל cache_dir ufs /var/spool/squid 50000 16 256 (מטמון 50 GB) ו-maximum_object_size 200 MB.
4. חיבר squidclient mgr:info לניטור שיעור פגיעה.
5. הגדיר רישום ל-access.log ורוטציה עם logrotate.
6. הפיץ סקריפטים להגדרת http_proxy על לקוחות (apt, Docker, systemd).

תוצאה: שיעור פגיעה של 73% בשבוע השני, תעבורה חיצונית ירדה מ-1.5 TB ל-400 GB בחודש. חיסכון—מעל 50% בעלויות יציאה.

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

מסקנה: Squid מנצח בבקרת גישה ובדיקת תעבורה; Nginx מנצח במטמון סטטי טהור ב-RPS גבוה. אנו משתמשים ב-Squid כאשר נדרש פרוקסי קדמי מלא.

אופטימיזציה של השרת לעומסים גבוהים

• השתמשו ב-cache_dir rock על SSD—מהיר יותר מ-ufs, פחות פרגמנטציה.
• הגדילו את cache_mem ל-30-50% מה-RAM, אך לא מעבר ל-maximum_object_size_in_memory (בדרך כלל 1-4 MB).
• הפעילו memory_pools_limit ו-prefix_write_cache להפחתת פרגמנטציה.
• הגדירו workers (ריבוי חוטים) עבור Squid 6+: workers 4 ו-cpu_affinity_map.
• השתמשו ב-collapse_forwarding למיזוג בקשות במקביל לאותו URL.
• תומך בעד 10,000 חיבורים במקביל עם כוונון נכון.

לפרמטרי הגדרה נוספים, ראו מדריך ההגדרות של Squid.

טעויות הגדרה טיפוסיות

• שכחת אתחול המטמון (squid -z)—השרת לא יתחיל.
• אי הגדרת http_access allow localhost—המופע לא יכול להתחבר לעצמו.
• cache_dir קטן מדי—המטמון מתמלא מהר, שיעור הפגיעה יורד.
• SSL Bump ללא התקנת CA על הלקוחות—הדפדפנים מתלוננים על התעודה.

תהליך העבודה

מה כלול בעבודה

• תיעוד: קבצי הגדרות, דיאגרמת רשת, הוראות תפעול.
• הגדרת מערכת ניטור (Prometheus + Grafana עבור Squid).
• הכשרת מנהלים: עבודה עם ACL, ניתוח לוגים, ניהול מטמון.
• תמיכה טכנית בהשקה: 7 ימים לאחר העלייה לאוויר.
• הגדרה בסיסית מתחילה ב-1,500 דולר; המחיר מותאם לאחר הביקורת.

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

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