שימוש ב-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 אל ה-backend. בתרחיש הזה, Edge פועל כלקוח TLS.

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

• https://en.wikipedia.org/wiki/Server_Name_Indication
• http://blog.layershift.com/sni-ssl-production-ready/

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

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

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

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

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

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

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

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

• מידע על מארחים וירטואליים
• הגדרת גישת TLS ל-API עבור הענן הפרטי
• מאגרי מפתחות ומאגרי אישורים

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

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

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

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

הגדרת צמד ברירת מחדל של אישור ומפתח ב-Edge for the Cloud

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

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

הגדרת צמד ברירת מחדל של אישור ומפתח ב-Edge for the Private Cloud

ב-Edge for the Private Cloud, אם לא נמצאה התאמה בין התוסף 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 אל ה-Backend

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

שימוש ב-SNI ב-backend ב-Edge for the Private Cloud

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

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

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