שימוש ב-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 לבקשה ל-API proxy ב-Edge

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

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

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

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

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

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

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

איך SNI עובד עם כינויי מארח

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

נתב Edge קורא את התוסף 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, ובסביבה prod הוגדרו שני מארחים וירטואליים עבור הארגון example:

  • שם המארח הווירטואלי = 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. בצומת הנתב הראשון, מעתיקים את האישור ואת המפתח הפרטי למיקום בצומת של הנתב נגיש למשתמש API. לדוגמה, /opt/apigee/customer/application.
  2. משנים את הבעלות על הקבצים למשתמש API: 
    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 בענן הפרטי, כדי לשמור על תאימות לאחור לקצה העורפי הקיים של היעד, 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 לבין הקצה העורפי בגרסה 4.16.01 ואילך של Edge

כדי להפעיל 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. חוזרים על השלבים האלה בכל שאר מעבדי ההודעות.