אתם צופים במסמכי העזרה של Apigee Edge.
כניסה למסמכי העזרה של Apigee X. info
באמצעות 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 זמין במאמרים הבאים:
- 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 תואמים ל-Edge Router, ומספר היציאה הוא יציאה פתוחה ב-Router.
כשיוצרים את המארח הווירטואלי, מציינים גם את הכינוי של המארח הווירטואלי.
בדרך כלל זהו שם ה-DNS של המארח הווירטואלי. כחלק מהקביעה של שרת ה-API המחובר שיטפל בבקשה, הנתב משווה את הכותרת Host
של הבקשה הנכנסת לרשימה של כתובות המארח החלופיות הזמינות שמוגדרות על ידי כל המארחים הווירטואליים.
השילוב של הכינוי של המארח ומספר היציאה של המארח הווירטואלי חייב להיות ייחודי לכל המארחים הווירטואליים בהתקנה של Edge. כלומר, מספר מארחים וירטואליים יכולים להשתמש באותו מספר יציאה אם יש להם כינויים שונים למארחים.
מארח וירטואלי מגדיר גם אם הגישה ל-API proxy תתבצע באמצעות פרוטוקול HTTP או באמצעות פרוטוקול HTTPS מוצפן באמצעות TLS. כשמגדירים מארח וירטואלי לשימוש ב-HTTPS, צריך לשייך את המארח הווירטואלי למאגר מפתחות שמכיל את האישור ואת המפתח הפרטי שבהם המארח הווירטואלי משתמש במהלך לחיצת היד ב-TLS.
מידע נוסף על מארחים וירטואליים זמין במאמרים הבאים:
איך SNI פועל עם כתובות אימייל חלופיות של מארח
בעזרת SNI אפשר להגדיר כמה מארחים וירטואליים באותו יציאה, לכל אחד מהם עם אישורי TLS ומפתחות שונים. לאחר מכן, Edge קובע את המארח הווירטואלי ואת זוג האישור/המפתח ש-TLS משתמש בהם, על סמך התוסף server_name
בבקשה של לחיצת היד ב-TLS.
Edge Router קורא את התוסף 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 לענן הפרטי
ב-Edge לענן הפרטי, אם לא נמצאה התאמה בין התוסף server_name
לכינויים של המארח מכל המארחים הווירטואליים, או אם הלקוח המבקש לא תומך ב-SNI, אפשר להגדיר את הנתב כך שישתמש בתעודה/במפתח של מארח וירטואלי שמוגדר כברירת מחדל ביציאה. מארח הווירטואלי שמוגדר כברירת מחדל מוגדר על ידי שילוב של שם הארגון, שם הסביבה ושם המארח הווירטואלי, בפורמט הבא:
orgName_envName_vhName
הנתב משתמש בתעודה/המפתח מהשילוב של orgName_envName_vhName שמופיע ראשון בסדר האלפביתי. לדוגמה, הבקשה נכנסת ביציאה 443, ויש שני מארחים וירטואליים שמוגדרים לארגון example
בסביבה prod
:
- שם המארח הווירטואלי =
default
- שם המארח הווירטואלי =
test
בדוגמה הזו, הנתב משתמש בתעודה/המפתח מהמארח הווירטואלי בשם default
כי example_prod_default
מופיע בסדר האלפביתי לפני example_prod_test
.
כדי להפעיל את המארח הווירטואלי שמוגדר כברירת מחדל:
- בצומת הראשון של הנתב, עורכים את
/opt/apigee/customer/application/router.properties
. אם הקובץ הזה לא קיים, יוצרים אותו. - מוסיפים לקובץ את המאפיין הבא כדי להגדיר מארח וירטואלי שמוגדר כברירת מחדל:
conf_load_balancing_load.balancing.driver.nginx.fallback.conf.enabled=true
- מפעילים מחדש את הנתב:
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
- חוזרים על השלבים האלה בכל שאר הנתבים.
במקום להשתמש בתעודה/במפתח מהמארח הווירטואלי שמוגדר כברירת מחדל, אפשר להגדיר במפורש את התעודה/המפתח שמוגדרים כברירת מחדל בנתב. כדי להגדיר זוג מפתח/אישור ברירת מחדל מפורש:
- בצומת הראשון של ה-Router, מעתיקים את האישור והמפתח הפרטי למיקום בצומת ה-Router שזמין למשתמש apigee. לדוגמה,
/opt/apigee/customer/application
. - משנים את הבעלות על הקבצים למשתמש apigee.
chown apigee:apigee /opt/apigee/customer/application/myCert.pem
chown apigee:apigee /opt/apigee/customer/application/myKey.pem
- עורכים את
/opt/apigee/customer/application/router.properties
. אם הקובץ הזה לא קיים, יוצרים אותו. - מוסיפים לקובץ את המאפיינים הבאים כדי שתוכלו לציין את האישור/המפתח שמוגדרים כברירת מחדל:
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 - מגדירים את המאפיינים הבאים ב-
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
- מפעילים מחדש את הנתב:
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
- חוזרים על השלבים האלה בכל שאר הנתבים.
תמיכה ב-SNI לבקשות מ-Edge לקצה העורפי
Edge תומך בשימוש ב-SNI ממעבדי הודעות כדי לטרגט נקודות קצה ב-Apigee Edge for Cloud ובפריסות בענן פרטי. כברירת מחדל, SNI מופעל במעבדי ההודעות של Edge בענן ומושבת בענן הפרטי.
שימוש ב-SNI לקצה העורפי ב-Edge לענן הפרטי
כדי ש-Edge for the Private Cloud יהיה תואם לאחור לקצוות עורפיים קיימים של יעד, Apigee השביתה את SNI כברירת מחדל. אם הקצה העורפי של היעד מוגדר לתמוך ב-SNI, תוכלו להפעיל את התכונה הזו בגרסה של Edge לפי ההוראות שבהמשך.
לא נדרשות הגדרות נוספות ספציפיות ל-Edge. אם סביבת היעד מוגדרת ל-SNI, Edge תומך בה. Edge מחלץ באופן אוטומטי את שם המארח מכתובת ה-URL של הבקשה ומוסיף אותו לבקשת לחיצת היד של TLS.
הפעלת SNI בין Edge לבין הקצה העורפי ב-Edge מגרסה 4.15.07.0x
כדי להפעיל את SNI:
- בצומת הראשון של Message Processor, פותחים את הקובץ
/opt/apigee4/conf/apigee/message-processor/system.properties
בכלי לעריכת טקסט. - מגדירים את המאפיין הבא למצב true ב-
system.properties
:jsse.enableSNIExtension=true
- מפעילים מחדש את מעבדי ההודעות:
/opt/apigee4/bin/apigee-service message-processor restart
- חוזרים על השלבים האלה בכל שאר מעבדי ההודעות.
הפעלת SNI בין Edge לקצה העורפי בגרסה 4.16.01 ואילך של Edge
כדי להפעיל את SNI:
- עורכים את
/opt/apigee/customer/application/message-processor.properties
בצומת הראשון של Message Processor. אם הקובץ הזה לא קיים, יוצרים אותו. - מוסיפים לקובץ את המאפיין הבא:
conf_system_jsse.enableSNIExtension=true
- מפעילים מחדש את מעבד ההודעות:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- חוזרים על השלבים האלה בכל שאר מעבדי ההודעות.