שימוש ב-SNI עם Edge

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X.
מידע

Server Name Indication (SNI) – אפשר להציג מספר יעדי HTTPS מחוץ לאותה כתובת IP הכתובת והיציאה בלי לדרוש מהיעדים האלה להשתמש באותו אישור TLS. כאשר SNI הוא מופעל אצל לקוח, הלקוח מעביר את שם המארח של נקודת הקצה של היעד כחלק לחיצת יד בפרוטוקול TLS. כך שרת ה-TLS יכול לקבוע באיזה אישור TLS להשתמש לאימות לבקשה.

לדוגמה, אם יעד הבקשה הוא https://example.com/request/path, אז לקוח ה-TLS מוסיף את התוסף server_name ללחיצת היד של TLS כפי שמוצג בהמשך:

Edge תומך ב-SNI בשביל:

  • בקשות מאפליקציית לקוח לשרת proxy ל-API. בתרחיש הזה, Edge משמש כ-TLS שרת
  • שליחת בקשות מ-Edge לקצה העורפי. בתרחיש הזה, Edge משמש כלקוח ה-TLS.

מידע נוסף על SNI זמין במאמרים הבאים:

תמיכה ב-SNI לבקשה ל-proxy ל-API ב- קצה

תמיכת SNI לבקשות לשרתי proxy ל-API נשלטת על ידי כינויי מארחים המארחים.

מידע על וירטואלי מארחים וכינויים של מארחים

ב-Edge, מארח וירטואלי מגדיר את כתובת ה-IP והיציאה, או את השם והיציאה של DNS, ב שבו נחשף שרת proxy ל-API, וכתוצאה מכך גם את כתובת ה-URL שאפליקציות משתמשות בה כדי לגשת לשרת proxy ל-API. כתובת ה-IP/שם ה-DNS תואמים לנתב Edge, ומספר היציאה הוא יציאה פתוחה נתב.

כשיוצרים את המארח הווירטואלי, מציינים גם את כינוי המארח של המארח הווירטואלי. בדרך כלל זהו שם ה-DNS של המארח הווירטואלי. במסגרת קביעת שרת ה-proxy ל-API מטפל בבקשה, הנתב משווה את הכותרת Host של הבקשה הנכנסת אל רשימה של כינויי מארחים זמינים שהוגדרו על ידי כל המארחים הווירטואליים.

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

מארח וירטואלי גם מגדיר אם ניתן לגשת לשרת ה-proxy של ה-API באמצעות פרוטוקול HTTP, או בפרוטוקול HTTPS המוצפן באמצעות TLS. כשמגדירים מארח וירטואלי לשימוש ב-HTTPS, לשייך את המארח הווירטואלי למאגר מפתחות שמכיל את האישור ואת המפתח הפרטי שמשמשים את מארח וירטואלי במהלך לחיצת יד בפרוטוקול TLS.

למידע נוסף על מארחים וירטואליים, ראו:

איך SNI פועל עם כינויים של מארחים

SNI מאפשר להגדיר כמה מארחים וירטואליים באותה יציאה, כל אחד עם אישורים ומפתחות TLS (אבטחת שכבת התעבורה). לאחר מכן, Edge קובע את המארח הווירטואלי ואת זוג האישור/מפתח שמשמש את TLS, על סמך server_name בבקשת לחיצת היד של TLS.

ה-Edge Router קורא את התוסף server_name בלחיצת היד של TLS ואז משתמשת בו כדי לחפש מול הכינויים של המארחים מכל המארחים. אם הנתב מזהה התאמה עם כינוי מארח, הנתב משתמש באישור ובמפתח ה-TLS מ- המארח הווירטואלי המשויך לכינוי המארח. אם לא נמצאה התאמה, לחיצת היד בפרוטוקול TLS תיכשל.

במקום שלחיצת היד של TLS תיכשל, תוכלו להגדיר זוג אישור/מפתחות כברירת מחדל, שמתוארים בקטעים הבאים.

הגדרת זוג אישור/מפתח כברירת מחדל ב-Edge עבור Cloud

Apigee מספקת אישור TLS ומפתח פרטי כדי לתמוך ב-HTTPS. למרות שלקוחות רבים ומעדיפים להשתמש באישור ובמפתח פרטי משלהם בזמן הפריסה, אפשר לפרוס את ממשקי ה-API באמצעות האישור והמפתח של Apigee.

ב-Edge for Cloud, אם הנתב לא יכול להתאים את כותרת ה-SNI לכינוי מארח או הלקוח לא תומך ב-SNI, אז הנתב ישתמש באישור ברירת המחדל שמסופק על ידי Apigee שהיא *.apigee.net.

הגדרת זוג אישור/מפתח כברירת מחדל ב-Edge עבור ענן פרטי

ב-Edge בענן הפרטי, אם לא נמצאה התאמה בין התוסף server_name לבין הכינויים של המארחים מכל המארחים הווירטואליים, או אם הלקוח המבקש לא תומך ב-SNI, אפשר להגדיר את נתב לשימוש באישור/במפתח ממארח וירטואלי שמוגדר כברירת מחדל בשקע. המארח הווירטואלי שמוגדר כברירת מחדל הוא מוגדר באמצעות שילוב של שם הארגון, שם הסביבה ושם המארח הווירטואלי, טופס:

orgName_envName_vhName

הנתב משתמש באישור/במפתח מהשילוב של orgName_envName_vhName מופיע ראשון בסדר אלפביתי. לדוגמה, הבקשה מגיעה ביציאה 443, ויש שני מארחים וירטואליים שהוגדרו לארגון example בסביבה prod:

  • שם המארח הווירטואלי = default
  • שם המארח הווירטואלי = test

בדוגמה הזו, הנתב משתמש באישור/במפתח מהמארח הווירטואלי שנקרא default כי example_prod_default מופיע בסדר אלפביתי לפני example_prod_test.

כדי להפעיל את המארח הווירטואלי שמוגדר כברירת מחדל:

  1. בצומת הנתב הראשון, עורכים את /opt/apigee/customer/application/router.properties. אם הקובץ לא קיים, יוצרים אותו.
  2. כדי להגדיר מארח וירטואלי כברירת מחדל, מוסיפים את המאפיין הבא לקובץ:
    conf_load_balancing_load.balancing.driver.nginx.fallback.conf.enabled=true
  3. מפעילים מחדש את הנתב:
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  4. חוזרים על השלבים האלה בכל הנתבים הנותרים.

במקום להשתמש באישור/במפתח מהמארח הווירטואלי שמוגדר כברירת מחדל, אפשר להגדיר באופן מפורש אישור/מפתח ברירת מחדל בנתב. יש להשתמש בתהליך הבא כדי להגדיר ברירת מחדל מפורשת זוג אישור/מפתח:

  1. בצומת הנתב הראשון, מעתיקים את האישור והמפתח הפרטי למיקום בצומת הנתב. שאליו משתמש ה-apigee יכול לגשת. לדוגמה, /opt/apigee/customer/application.
  2. לשנות את הבעלות על הקבצים ל-'apigee'. user:
    chown apigee:apigee /opt/apigee/customer/application/myCert.pem
    chown apigee:apigee /opt/apigee/customer/application/myKey.pem
  3. עריכה של /opt/apigee/customer/application/router.properties. אם הקובץ לא קיים, יוצרים אותו.
  4. כדי לציין את אישור/מפתח ברירת המחדל, מוסיפים את המאפיינים הבאים לקובץ:
    conf_load_balancing_load.balancing.driver.nginx.fallback.server.default.ssl.template.enabled=true
    conf_load_balancing_load.balancing.driver.nginx.fallback.conf.enabled=true
  5. צריך להגדיר את המאפיינים הבאים ב-router.properties כדי לציין את המיקום של האישור והמפתח:
    conf_load_balancing_load.balancing.driver.nginx.ssl.cert=/opt/apigee/customer/application/myCert.pem
    conf_load_balancing_load.balancing.driver.nginx.ssl.key=/opt/apigee/customer/application/myKey.pem
  6. מפעילים מחדש את הנתב:
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  7. חוזרים על השלבים האלה בכל הנתבים הנותרים.

תמיכה ב-SNI לבקשות מ-Edge אל הקצה העורפי

Edge תומך בשימוש ב-SNI ממעבדי הודעות כדי לטרגט נקודות קצה ב-Apigee Edge ב-Cloud ולפריסות של ענן פרטי. כברירת מחדל, SNI מופעל במעבדי הודעות Edge בענן ומושבת בענן הפרטי.

באמצעות SNI לקצה העורפי ב-Edge עבור ענן פרטי

ב-Edge for Cloud Private Cloud, כדי לבצע תאימות לאחור לקצוות העורפיים הקיימים ביעד: Apigee השביתה SNI כברירת מחדל. אם הקצה העורפי של היעד מוגדר לתמיכה ב-SNI, אפשר להפעיל את התכונה הזו כמו שמתואר בהמשך בגרסת Edge שבה אתם משתמשים.

לא נדרשות הגדרות נוספות ספציפיות ל-Edge. אם סביבת היעד מוגדרת SNI, דפדפן Edge תומך בו. Edge מחלץ באופן אוטומטי את שם המארח מכתובת ה-URL של הבקשה ומוסיף אותו לבקשת לחיצת היד בפרוטוקול TLS.

הפעלת SNI בין Edge לקצה העורפי בגרסת Edge 4.15.07.0x

מבצעים את התהליך הבא כדי להפעיל SNI:

  1. בצומת הראשון של מעבד ההודעות, פותחים את הקובץ. /opt/apigee4/conf/apigee/message-processor/system.properties בעורך/ת.
  2. צריך להגדיר את המאפיין הבא כ-TRUE ב-system.properties:
    jsse.enableSNIExtension=true
  3. מפעילים מחדש את מעבדי ההודעות:
    /opt/apigee4/bin/apigee-service message-processor restart
  4. חוזרים על השלבים האלה בכל מעבדי ההודעות שנותרו.

הפעלת SNI בין Edge לקצה העורפי בגרסת Edge 4.16.01 ואילך

כדי להפעיל SNI:

  1. בצומת הראשון של מעבד ההודעות, עורכים את /opt/apigee/customer/application/message-processor.properties. אם הקובץ לא קיים, יוצרים אותו.
  2. מוסיפים את המאפיין הבא לקובץ:
    conf_system_jsse.enableSNIExtension=true
  3. מפעילים מחדש את מעבד ההודעות:
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  4. חוזרים על השלבים האלה בכל מעבדי ההודעות שנותרו.