📘 תיעוד 154

ניתוב

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

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

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

אפשר לפרסם כמה יישומים על מנהרה אחת. לכל יישום מציינים:

• שם מארח ציבורי: הדומיין או תת-הדומיין שמשתמשים מבקרים בו (לדוגמה, app.example.com).
• שירות: הכתובת המקומית או הסוקט שבהם היישום רץ (לדוגמה, http://localhost:8080).

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

הערה

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

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

#מגבלות על יישומים שפורסמו

מנהרה אחת בניהול מרוחק תומכת בערך ב-5,000 עד 10,000 יישומים שפורסמו. המגבלה מבוססת על גודל תצורת המנהרה, שיכול להגיע עד 1 MB.

תצורת המנהרה היא קבוצת כללי ingress והגדרות origin ש-Cloudflare שומרת עבור מנהרה בניהול מרוחק כשמוסיפים יישומים שפורסמו בלוח הבקרה או באמצעות ה-API. כל יישום שפורסם מוסיף כלל ingress אחד, וכלל טיפוסי הוא 100 עד 200 בתים. כללים עם שמות מארח ארוכים, נתיבים, או הרבה פרמטרי origin תופסים יותר מקום ומקטינים את מספר היישומים שפורסמו שמנהרה יכולה להכיל.

יישומים שפורסמו אינם נספרים במגבלת החשבון עבור נתיבים. נתיבים הם נתיבי CIDR ושם מארח עבור תעבורת רשת פרטית, ויש להם מגבלה נפרדת של 50,000 לכל חשבון.

אם צריך לפרסם יותר יישומים, מפזרים אותם על פני כמה מנהרות. כל חשבון כולל 1,000 מנהרות. כדי להריץ יותר, עיינו במנהרות לפלטפורמות.

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

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

#כתובות שירות IPv6

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

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

#רשומות DNS

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

FedRAMP High

בחשבונות בסביבת FedRAMP High ↗︎ של Cloudflare, רשומות CNAME חייבות להצביע אל תת-הדומיין של המנהרה <UUID>.fed-cfargotunnel.com במקום <UUID>.cfargotunnel.com. רשומת CNAME שמצביעה אל <UUID>.cfargotunnel.com תחזיר שגיאת 530 עם קוד שגיאה 1033, גם כשהמנהרה תקינה. למידע נוסף, עיינו ב-שגיאה 1033.

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

#יצירת רשומת 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 אבל אינו מעביר תעבורה כפרוקסי אלא אם המנהרה רצה.

הערה

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

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

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

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

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

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

#עותקים לעומת מאזני עומסים

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

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

#הוספת מנהרה למאגר של מאזן עומסים

דרישות קדם

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

   הערה

   מאגר origin יחיד אינו יכול להפנות לאותו UUID של מנהרה פעמיים.

7. בחרו Fallback pool. עיינו במדיניות הכוונת תעבורה לאפשרויות ניתוב.

8. (מומלץ) בדף Monitors, צרפו מוניטור לנקודת הקצה. עבור יישום 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 אינם נתמכים עבור נקודות קצה של מנהרה. במקום זאת, צרו נקודת קצה לבדיקת תקינות על המארח של 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 ותצורות Rules אחרות. אפשר לשנות את ההגדרות האלה עבור כל שם מארח בלוח הבקרה של Cloudflare ↗︎.

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