شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات
نشاندهنده نام سرور (SNI) به چندین هدف HTTPS اجازه میدهد تا از یک آدرس IP و پورت یکسان بدون نیاز به استفاده از گواهی TLS یکسان از آن اهداف استفاده شود. هنگامی که SNI در یک کلاینت فعال می شود، مشتری نام میزبان نقطه پایانی هدف را به عنوان بخشی از دست دادن اولیه TLS ارسال می کند. این به سرور TLS اجازه می دهد تا تعیین کند که کدام گواهی TLS باید برای اعتبارسنجی درخواست استفاده شود.
به عنوان مثال، اگر هدف درخواست https:// example.com /request/path
باشد، مشتری TLS پسوند server_name
مانند شکل زیر به درخواست handshake TLS اضافه می کند:
Edge از SNI برای موارد زیر پشتیبانی می کند:
- درخواست از یک برنامه مشتری به یک پروکسی API. در این سناریو، Edge به عنوان سرور TLS عمل می کند
- درخواست از Edge به باطن. در این سناریو، Edge به عنوان مشتری TLS عمل می کند.
برای اطلاعات بیشتر در مورد SNI، نگاه کنید به:
- https://en.wikipedia.org/wiki/Server_Name_Indication
- http://blog.layershift.com/sni-ssl-production-ready/
پشتیبانی از SNI برای درخواست پروکسی API در Edge
پشتیبانی SNI برای درخواستها به پراکسیهای API توسط نامهای مستعار میزبان و میزبانهای مجازی کنترل میشود.
درباره میزبان مجازی و نام مستعار میزبان
با Edge، یک میزبان مجازی آدرس IP و پورت یا نام و پورت DNS را تعریف میکند که در آن یک پراکسی API در معرض دید قرار میگیرد و بهطور پسوند URL که برنامهها برای دسترسی به پروکسی API از آن استفاده میکنند. آدرس IP/نام DNS مربوط به Edge Router است و شماره پورت یک پورت باز روی روتر است.
هنگامی که میزبان مجازی را ایجاد می کنید، نام مستعار میزبان میزبان مجازی را نیز مشخص می کنید. معمولاً این نام DNS میزبان مجازی است. به عنوان بخشی از تعیین پراکسی API که درخواست را مدیریت می کند، روتر هدر Host
درخواست ورودی را با لیست نام مستعار میزبان موجود تعریف شده توسط همه میزبان های مجازی مقایسه می کند.
ترکیب نام مستعار میزبان و شماره پورت برای میزبان مجازی باید برای همه میزبانهای مجازی در نصب Edge منحصربهفرد باشد. این بدان معناست که چندین میزبان مجازی می توانند از یک شماره پورت استفاده کنند اگر نام مستعار میزبان متفاوتی داشته باشند.
یک میزبان مجازی همچنین تعیین می کند که آیا پروکسی API با استفاده از پروتکل HTTP یا با پروتکل HTTPS رمزگذاری شده با استفاده از TLS قابل دسترسی است. هنگام پیکربندی یک میزبان مجازی برای استفاده از HTTPS، میزبان مجازی را با یک فروشگاه کلید مرتبط کنید که حاوی گواهی و کلید خصوصی است که توسط میزبان مجازی در هنگام دست دادن TLS استفاده میشود.
برای اطلاعات بیشتر در مورد هاست های مجازی، نگاه کنید به:
نحوه کار SNI با نام مستعار میزبان
SNI به شما این امکان را می دهد که چندین هاست مجازی را در یک پورت تعریف کنید که هر کدام دارای گواهینامه ها و کلیدهای TLS متفاوتی هستند. سپس Edge میزبان مجازی و جفت گواهی/کلید مورد استفاده توسط TLS را بر اساس پسوند server_name
در درخواست Handshake TLS تعیین میکند.
Edge Router پسوند server_name
در درخواست Handshake TLS می خواند و سپس از آن برای جستجوی نام مستعار میزبان از همه میزبان های مجازی استفاده می کند. اگر روتر مطابق با نام مستعار میزبان را تشخیص دهد، روتر از گواهی و کلید TLS از میزبان مجازی مرتبط با نام مستعار میزبان استفاده می کند. اگر مطابقت پیدا نشد، دست دادن TLS ناموفق است.
به جای اینکه دست دادن TLS با شکست مواجه شود، میتوانید یک جفت گواهی/کلید پیشفرض، همانطور که در بخشهای بعدی توضیح داده شد، تعریف کنید.
تعریف یک جفت گواهی/کلید پیشفرض در Edge برای Cloud
Apigee یک گواهی TLS و کلید خصوصی برای پشتیبانی از HTTPS ارائه می دهد. در حالی که بسیاری از مشتریان ترجیح می دهند از گواهینامه و کلید خصوصی خود در زمان استقرار استفاده کنند، شما می توانید API های خود را با استفاده از گواهی و کلید Apigee مستقر کنید.
در Edge for the Cloud، اگر روتر نتواند هدر SNI را با نام مستعار میزبان مطابقت دهد یا اگر کلاینت از SNI پشتیبانی نمی کند، روتر از گواهی پیش فرض ارائه شده توسط Apigee استفاده می کند که *.apigee.net است.
تعریف یک جفت گواهی/کلید پیشفرض در Edge برای Private Cloud
در Edge برای Private Cloud، اگر هیچ تطابقی بین پسوند server_name
و نام مستعار میزبان از همه میزبانهای مجازی یافت نشد، یا اگر مشتری درخواستکننده از SNI پشتیبانی نمیکند، میتوانید روتر را برای استفاده از گواهی/کلید از یک مجازی پیشفرض پیکربندی کنید. میزبان در بندر میزبان مجازی پیش فرض با ترکیبی از نام سازمان، نام محیط و نام میزبان مجازی به شکل زیر تعریف می شود:
orgName_envName_vhName
روتر از cert/key از ترکیب orgName_envName_vhName استفاده می کند که به ترتیب حروف الفبا اول است. به عنوان مثال، درخواست در پورت 443 وارد می شود و دو میزبان مجازی برای example
org در محیط prod
تعریف شده است:
- نام میزبان مجازی =
default
- نام میزبان مجازی =
test
در این مثال، روتر از cert/key از میزبان مجازی با نام 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
- این مراحل را در همه روترهای باقی مانده تکرار کنید.
به جای استفاده از cert/key از میزبان مجازی پیش فرض، می توانید به صراحت گواهی/کلید پیش فرض را در روتر تعریف کنید. از روش زیر برای تعریف یک جفت گواهی/کلید پیش فرض صریح استفاده کنید:
- در اولین گره روتر، گواهی و کلید خصوصی را در مکانی در گره روتر کپی کنید که توسط کاربر 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 برای Cloud و برای استقرار Private Cloud پشتیبانی میکند. بهطور پیشفرض، SNI در پردازشگرهای پیام Edge برای Cloud فعال و در Private Cloud غیرفعال است.
استفاده از SNI برای باطن در Edge برای Private Cloud
برای اینکه Edge for the Private Cloud سازگار با پشتیبانهای هدف موجود باشد، Apigee SNI را به طور پیشفرض غیرفعال کرد. اگر باطن هدف شما برای پشتیبانی از SNI پیکربندی شده است، می توانید این ویژگی را همانطور که در زیر توضیح داده شده است برای نسخه Edge خود فعال کنید.
هیچ پیکربندی خاص Edge مورد نیاز نیست. اگر محیط هدف شما برای SNI پیکربندی شده است، Edge از آن پشتیبانی می کند. Edge به طور خودکار نام میزبان را از URL درخواست استخراج می کند و آن را به درخواست Handshake TLS اضافه می کند.
SNI را بین Edge و Backend برای Edge نسخه 4.15.07.0x فعال کنید
برای فعال کردن SNI از روش زیر استفاده کنید:
- در اولین گره Message Processor، فایل
/opt/apigee4/conf/apigee/message-processor/system.properties
را در یک ویرایشگر باز کنید. - ویژگی زیر را در
system.properties
روی true قرار دهید:jsse.enableSNIExtension=true
- پردازشگرهای پیام را مجددا راه اندازی کنید:
/opt/apigee4/bin/apigee-service message-processor restart
- این مراحل را در تمام پردازشگرهای پیام باقیمانده تکرار کنید.
SNI را بین Edge و Backend برای Edge نسخه 4.16.01 و جدیدتر فعال کنید
برای فعال کردن SNI از روش زیر استفاده کنید:
- در اولین گره پردازشگر پیام،
/opt/apigee/customer/application/message-processor.properties
را ویرایش کنید. اگر آن فایل وجود ندارد، آن را ایجاد کنید. - ویژگی زیر را به فایل اضافه کنید:
conf_system_jsse.enableSNIExtension=true
- پردازشگر پیام را مجددا راه اندازی کنید:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- این مراحل را در تمام پردازشگرهای پیام باقیمانده تکرار کنید.