📘 תיעוד 35

ניתוב

Cloudflare Tunnel מנתב תעבורה מרשת Cloudflare אל שירותים הפועלים מאחורי cloudflared. כאשר אתם מפרסמים יישום, אתם ממפים שם מארח ציבורי לשירות מקומי, לדוגמה, app.example.com ל-http://localhost:8080, ו-Cloudflare מחילה שמירה במטמון של CDN, הגנת WAF והגנת DDoS לפני העברת הבקשה למקור שלכם.

#יישומים מפורסמים

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

ניתן לפרסם מספר יישומים על גבי מנהרה בודדת. עבור כל יישום, ציינו:

• Public hostname: הדומיין או תת-הדומיין שמשתמשים מבקרים בו (לדוגמה, app.example.com).
• Service: הכתובת המקומית או הסוקט (socket) שבהם היישום פועל (לדוגמה, http://localhost:8080).

כאשר אתם מוסיפים נתיב דרך לוח הבקרה (dashboard), Cloudflare יוצרת באופן אוטומטי רשומת DNS המצביעה משם המארח לתת-הדומיין של המנהרה שלכם (<UUID>.cfargotunnel.com).

הערה

נתיבי שמות מארח ציבוריים מעבירים תעבורה דרך פרוקסי של Cloudflare. בתוכניות Free, Pro ו-Business, התנאים הספציפיים לשירות ↗ דורשים מכם להשתמש בשירות ייעודי בתשלום כדי להגיש וידאו וקבצים גדולים אחרים.

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

#פרוטוקולים נתמכים

הטבלה להלן מפרטת את סוגי השירותים שניתן לנתב לשם מארח ציבורי. שירותים שאינם HTTP דורשים התקנת cloudflared בלקוח כדי שמשתמשי קצה יוכלו להתחבר.

#כתובות שירות מסוג IPv6

כאשר ערך השירות הוא כתובת IPv6 מפורשת (literal), עטפו את הכתובת בסוגריים מרובעים כפי שמוגדר ב-RFC 3986 ↗. הסוגריים נדרשים כדי שתווי ה-: בכתובת לא יתבלבלו עם מפריד היציאה (port).

שמות מארח וכתובות IPv4 אינם זקוקים לסוגריים, http://localhost:8000 ו-http://192.0.2.1:8000 תקינים כפי שהם.

#רשומות DNS

כאשר אתם יוצרים מנהרה, Cloudflare מפיקה תת-דומיין בכתובת <UUID>.cfargotunnel.com. אתם מפנים רשומת CNAME אל תת-דומיין זה כדי לנתב תעבורה משם המארח שלכם אל המנהרה.

תת-הדומיין cfargotunnel.com מעביר תעבורה ב-proxy רק עבור רשומות DNS שנמצאות באותו חשבון Cloudflare. אם מישהו מגלה את ה-UUID של המנהרה שלכם, הוא אינו יכול ליצור רשומת DNS בחשבון אחר כדי להעביר דרכה תעבורה ב-proxy.

#יצירת רשומת DNS

כדי ליצור רשומת DNS עבור Cloudflare Tunnel:

1. היכנסו אל לוח הבקרה של Cloudflare ↗ ועברו אל DNS Records עבור הדומיין שלכם.
   מעבר אל Records ↗
2. בחרו ב-Add record.
3. הזינו את הערכים הבאים:

• Type: CNAME
• Name: תת-דומיין של היישום שלכם
• Target: <UUID>.cfargotunnel.com

4. בחרו ב-Save.

עבור מנהרות בניהול מקומי, הריצו את הפקודה הבאה כדי ליצור רשומת CNAME המצביעה על תת-הדומיין של המנהרה שלכם:

cloudflared tunnel route dns <UUID or NAME> www.app.com

פעולה זו יוצרת רשומת CNAME אך אינה מעבירה תעבורה ב-proxy אלא אם המנהרה פועלת.

הערה

כדי ליצור רשומות DNS באמצעות cloudflared, קובץ ה-cert.pem חייב להיות מותקן במערכת שלכם.

רשומת ה-DNS והמנהרה אינן תלויות זו בזו. באפשרותכם ליצור רשומות DNS המצביעות על מנהרה שאינה פועלת. אם מנהרה נעצרת, רשומת ה-DNS אינה נמחקת: המבקרים יראו שגיאת 1016.

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

#איזון עומסים

השתמשו במאזן עומסים ציבורי כדי לחלק תעבורה בין שרתים המריצים את היישומים המפורסמים שלכם. הדבר מספק מעבר לגיבוי בעת כשל המבוסס על בדיקות תקינות (health checks) וניתוב תעבורה חכם בין אזורים.

graph LR
    accTitle: Load balancing traffic to applications behind Cloudflare Tunnel

    A[Internet] --> C{Cloudflare <br> Load Balancer}
    C -- Tunnel 1 --> cf1
    C -- Tunnel 2 --> cf2
    subgraph F[Data center 2]
        cf2[cloudflared]
        S3[App server]
        S4[App server]
        cf2-->S3
        cf2-->S4
    end
    subgraph E[Data center 1]
        cf1[cloudflared]
        S1[App server]
        S2[App server]
        cf1-->S1
        cf1-->S2
    end

#עותקים משוכפלים (Replicas) לעומת מאזני עומסים

הפעלת מספר עותקים משוכפלים (replicas) של cloudflared על אותו UUID של מנהרה מספקת יתירות בסיסית: אם מארח אחד נכשל, עותקים משוכפלים אחרים ממשיכים לשרת תעבורה. עם זאת, מאזן העומסים מתייחס לכל העותקים המשוכפלים בעלי אותו UUID של מנהרה כאל נקודת קצה יחידה.

עבור ניתוב תעבורה מדויק ושיוך הפעלה (session affinity), חברו כל מארח באמצעות UUID שונה של מנהרה, כדי שמאזן העומסים יוכל לפנות אליהם באופן עצמאי.

#הוספת מנהרה לקבוצת משאבים (pool) של מאזן עומסים

דרישות מוקדמות

Cloudflare Tunnel עם נתיב יישום מפורסם אחד לפחות.

כדי ליצור מאזן עומסים עבור יישומים מפורסמים של Cloudflare Tunnel:

1. בלוח הבקרה של Cloudflare, עברו לדף Load Balancing.
   מעבר אל Load Balancing ↗
2. בחרו ב-Create load balancer, ולאחר מכן בחרו ב-Public load balancer.
3. תחת Select website, בחרו את הדומיין של נתיב היישום המפורסם שלכם.
4. בדף Hostname, הזינו שם מארח עבור מאזן העומסים (לדוגמה, lb.example.com).
5. בדף Pools, בחרו ב-Create a pool והזינו שם תיאורי.
6. הוסיפו נקודת קצה (endpoint) של מנהרה עם הערכים הבאים:

• Endpoint Name: שם השרת המריץ את היישום
• Endpoint Address: <UUID>.cfargotunnel.com (את ה-Tunnel ID ניתן למצוא בלוח הבקרה של Cloudflare תחת Networking > Tunnels)
• Header value: שם המארח של נתיב היישום המפורסם שלכם (לדוגמה, app.example.com)
• Weight: 1 (אם יש רק נקודת קצה אחת)
  הערה
  קבוצת מקור (origin pool) יחידה אינה יכולה להפנות לאותו UUID של מנהרה פעמיים.

7. בחרו ב-Fallback pool. עיינו במדיניות ניתוב תעבורה לאפשרויות ניתוב.
8. (מומלץ) בדף Monitors, צרפו צג (monitor) לנקודת הקצה. עבור יישום HTTP או HTTPS, צרו צג HTTPS:

• Type: HTTPS
• Path: /
• Port: 443
• Expected Code(s): 200
• Header Name: Host
• Value: app.example.com

9. שמרו ופרסו את מאזן העומסים.

כדי לבדוק, גשו אל היישום שלכם באמצעות שם המארח של מאזן העומסים (lb.example.com).

ניטור מקורות מנהרה מסוג TCP

צגי TCP אינם נתמכים עבור נקודות קצה של מנהרה. במקום זאת, צרו נקודת קצה לבדיקת תקינות (health check) במארח של cloudflared והשתמשו בצג HTTPS. לדוגמה, תוכלו להשתמש ב-cloudflared כדי להחזיר תגובת קוד סטטוס HTTP קבועה:

1. הוסיפו נתיב יישום מפורסם עבור בדיקת התקינות:

• Hostname: health-check.example.com
• Service Type: HTTP_STATUS
• HTTP Status Code: 200

2. צרו צג עם ההגדרות הבאות:

• Type: HTTPS
• Path: /
• Port: 443
• Expected Code(s): 200
• Header Name: Host
• Value: health-check.example.com

צג זה מאמת ש-cloudflared נגיש. הוא אינו בודק האם שירות המקור (upstream) מקבל בקשות.

העדפת חיבור מקומי

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

Cloudflare משתמשת בניתוב Anycast ↗ כדי לנתב בקשות משתמשי קצה למרכז הנתונים הקרוב ביותר. cloudflared מעדיף לשרת בקשות באמצעות חיבורים באותו מרכז נתונים, מה שעשוי להשפיע על אופן חלוקת התעבורה בין נקודות הקצה.

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

#הגדרות Cloudflare

יישומים מפורסמים יורשים את הגדרות Cloudflare עבור שם המארח שלהם, כולל כללי מטמון, כללי WAF, ותצורות כללים אחרות. תוכלו לשנות הגדרות אלו עבור כל שם מארח בלוח הבקרה של Cloudflare ↗.

אם אתם משתמשים במאזן עומסים, ההגדרות מוחלות על שם המארח של מאזן העומסים במקום זאת.