פרק 2
איך זה עובד
כדי להבין את פעולתה של קלאודפלייר, יש להבחין בין שני תפקידים נפרדים לחלוטין שהיא ממלאת בארכיטקטורת הרשת:
- ספקית DNS סמכותית (Authoritative DNS Provider): המערכת שעונה לשאילתות הניתוב של האינטרנט ומחזירה את כתובת היעד עבור הדומיין.
- פרוקסי הפוך לתעבורת HTTP/HTTPS (Reverse Proxy): שרתי קצה המקבלים את תעבורת הגלישה בפועל, מבצעים סינון ועיבוד, ומעבירים אותה הלאה לשרת המקור.
ההפרדה הזו היא המפתח להבנת אופן הפעולה: ניתן להשתמש בקלאודפלייר כספקית DNS בלבד, או להפעיל את שכבת הפרוקסי המלאה כדי ליהנות מהגנה והאצה.
1. שלב ה-DNS:
[לקוח] ──(שאילתת DNS: איפה example.com?)──> [שרתי DNS של קלאודפלייר]
│
┌─────────────┴─────────────┐
▼ ▼
רשומה בסטטוס Proxied רשומה בסטטוס DNS Only
(ענן כתום) (ענן אפור)
מוחזרת כתובת Anycast מוחזרת כתובת השרת האמיתית
2. שלב התעבורה (HTTP/HTTPS):
[Proxied] ──> [לקוח] ──> [Edge של קלאודפלייר (WAF, Cache, SSL)] ──> [שרת המקור]
[DNS Only] ──> [לקוח] ─────────────────────────────────────────────> [שרת המקור הישיר]#ענן כתום מול ענן אפור (Proxy Status)
בלוח הבקרה של קלאודפלייר, לצד כל רשומת DNS מופיע מתג סטטוס:
#מצב Proxied (ענן כתום)
כאשר הרשומה מוגדרת כ-Proxied, קלאודפלייר משיבה לשאילתות ה-DNS בכתובת IP מסוג Anycast השייכת לרשת שלה.
- הסתרת כתובת מקור: הגולשים והסורקים רואים אך ורק את כתובות ה-IP של קלאודפלייר.
- הפעלת כל שכבות ההגנה: חומת האש (WAF), סינון בוטים, מנגנוני Rate Limiting ובלימת מתקפות מניעת שירות (DDoS) פועלים על כל בקשה.
- האצה ומטמון (Caching): נכסים סטטיים נשמרים בשרתי הקצה ומוגשים ישירות לגולש ללא פנייה לשרת המקור.
- סיום הצפנה (TLS Termination): חיבור ה-TLS מאובטח ישירות מול שרתי הקצה.
#מצב DNS Only (ענן אפור)
כאשר הרשומה מוגדרת כ-DNS Only, קלאודפלייר פועלת כשרת שמות רגיל בלבד.
- תשובת ה-DNS מחזירה ישירות את כתובת ה-IP האמיתית של השרת שלכם.
- התעבורה זורמת ישירות בין הלקוח לשרת ללא מעבר ברשת קלאודפלייר.
- אין הגנת WAF, אין שמירה במטמון, ואין הסתרת IP עבור רשומה זו.
- מתאים לפרוטוקולים שאינם נתמכים בפרוקסי ברירת המחדל (כמו שרתי משחק מותאמים אישית או חיבורי TCP ישירים ללא Spectrum).
#ניתוב Anycast וזרימת התעבורה
קלאודפלייר מפעילה מאות מרכזי נתונים ברחבי העולם באמצעות טכנולוגיית Anycast של פרוטוקול BGP. במקום שלכל מרכז נתונים תהיה כתובת IP ייעודית משלו, כל השרתים ברחבי הגלובוס מכריזים על אותם טווחי כתובות IP.
ספקי האינטרנט (ISPs) מנתבים את המשתמש באופן אוטומטי אל נקודת הנוכחות (Point of Presence - PoP) הקרובה ביותר מבחינה טופולוגית.
#שלבי עיבוד הבקשה בשרת הקצה (On-Ramp):
- קבלת הבקשה ופענוח TLS: שרת הקצה מקים חיבור מאובטח מול הדפדפן.
- סינון מתקפות (DDoS & WAF): חומת האש מוודאת שהבקשה לגיטימית ואינה מכילה דפוסי פריצה (SQL Injection, XSS, סריקות ידועות).
- בדיקת מטמון (Edge Cache): שרת הקצה בודק האם המשאב המבוקש קיים בזיכרון המקומי. אם יש Cache Hit, התשובה נשלחת מיד חזרה לגולש.
- פנייה למקור (Origin Fetch / Cache Miss): אם המשאב דינמי או שאינו במטמון, שרת הקצה יוצר חיבור TCP/TLS מול שרת המקור ושולף את המידע.
- החזרת תשובה ושמירה במטמון: התשובה מועברת לגולש, ובמידה וכותרות ה-Cache מאפשרות זאת, נשמרת בשרת הקצה עבור הבקשות הבאות.
#כותרות HTTP המועברות לשרת המקור
כאשר בקשה עוברת דרך הפרוקסי, שרת המקור יראה את כתובת ה-IP של שרת הקצה של קלאודפלייר ולא את ה-IP הישיר של הגולש. כדי שהשרת שלכם יידע מיהו הלקוח האמיתי, קלאודפלייר מוסיפה כותרות ייעודיות לכל בקשה:
CF-Connecting-IP: כתובת ה-IP המקורית של הלקוח שפתח את החיבור.X-Forwarded-For: שרשרת כתובות ה-IP שהבקשה עברה דרכן.CF-IPCountry: קוד המדינה בת שני תווים (למשלIL,US) שממנה נשלחה הבקשה.CF-Ray: מזהה ייחודי של הבקשה (Ray ID) המשמש לניטור, מעקב ואיתור תקלות בלוגים של קלאודפלייר ובשרת המקור.
#מה קלאודפלייר אינה עושה
חשוב להבין את גבולות האחריות של השירות:
- קלאודפלייר אינה מאחסנת את קוד האתר שלכם (אלא אם אתם משתמשים במפורש במוצרי Workers או Pages).
- הפעלת פרוקסי אינה מתקנת באגים בקוד האפליקציה או איטיות בשאילתות בסיס נתונים שלא ניתן לשמור במטמון.
- אם כתובת ה-IP של שרת המקור שלכם נחשפה בעבר או מופיעה ברשומות DNS אחרות, תוקפים יכולים לעקוף את קלאודפלייר ולפנות אליו ישירות, אלא אם חסמתם גישה ישירה בחומת האש ברמת השרת.
בפרק הבא נלמד צעד אחר צעד כיצד להוסיף אתר חדש לקלאודפלייר, להגדיר את שרתי השמות (Nameservers) ולוודא שהמעבר מתבצע ללא השבתה של האתר או של תיבות הדוא"ל.