استفاده از SNI با Edge

شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات

نشانگر نام سرور (SNI) اجازه می‌دهد تا چندین هدف HTTPS از یک آدرس IP و پورت یکسان، بدون نیاز به استفاده از گواهی TLS یکسان، سرویس‌دهی شوند. هنگامی که SNI روی یک کلاینت فعال می‌شود، کلاینت نام میزبان نقطه پایانی هدف را به عنوان بخشی از فرآیند اولیه TLS handshake ارسال می‌کند. این امر به سرور TLS اجازه می‌دهد تا تعیین کند که از کدام گواهی TLS باید برای اعتبارسنجی درخواست استفاده شود.

برای مثال، اگر مقصد درخواست https:// example.com /request/path باشد، کلاینت TLS پسوند server_name را به درخواست TLS handshake اضافه می‌کند، همانطور که در زیر نشان داده شده است:

Edge از SNI برای موارد زیر پشتیبانی می‌کند:

• درخواست‌ها از یک برنامه کلاینت به یک پروکسی 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 برای درخواست به پروکسی API در Edge

پشتیبانی SNI برای درخواست‌ها به پروکسی‌های API توسط نام‌های مستعار میزبان‌ها و میزبان‌های مجازی کنترل می‌شود.

درباره میزبان‌های مجازی و نام‌های مستعار میزبان

با Edge، یک میزبان مجازی ، آدرس IP و پورت، یا نام و پورت DNS را که یک پروکسی API روی آن قرار می‌گیرد و به طور گسترده‌تر، URL ای را که برنامه‌ها برای دسترسی به یک پروکسی API استفاده می‌کنند، تعریف می‌کند. آدرس IP/نام DNS مربوط به یک روتر Edge است و شماره پورت، یک پورت باز روی روتر است.

وقتی میزبان مجازی را ایجاد می‌کنید، نام مستعار میزبان مجازی را نیز مشخص می‌کنید. معمولاً این نام DNS میزبان مجازی است. به عنوان بخشی از تعیین پروکسی API که درخواست را مدیریت می‌کند، روتر هدر Host درخواست ورودی را با لیست نام‌های مستعار میزبان موجود که توسط همه میزبان‌های مجازی تعریف شده‌اند، مقایسه می‌کند.

ترکیب نام مستعار میزبان و شماره پورت برای میزبان مجازی باید برای همه میزبان‌های مجازی در نصب Edge منحصر به فرد باشد. این بدان معناست که چندین میزبان مجازی می‌توانند در صورت داشتن نام‌های مستعار میزبان متفاوت، از شماره پورت یکسانی استفاده کنند .

یک میزبان مجازی همچنین تعریف می‌کند که آیا پروکسی API با استفاده از پروتکل HTTP یا توسط پروتکل رمزگذاری شده HTTPS با استفاده از TLS قابل دسترسی است. هنگام پیکربندی یک میزبان مجازی برای استفاده از HTTPS، میزبان مجازی را با یک فروشگاه کلید مرتبط کنید که شامل گواهی و کلید خصوصی مورد استفاده میزبان مجازی در طول TLS handshaking است.

برای اطلاعات بیشتر در مورد میزبان‌های مجازی، به موارد زیر مراجعه کنید:

• درباره میزبان‌های مجازی
• پیکربندی دسترسی TLS به یک API برای ابر خصوصی
• فروشگاه‌های کلیدی و فروشگاه‌های معتمد

نحوه‌ی عملکرد SNI با نام‌های مستعار میزبان

SNI به شما امکان می‌دهد چندین میزبان مجازی را روی یک پورت تعریف کنید که هر کدام دارای گواهی‌ها و کلیدهای TLS متفاوتی باشند. سپس Edge میزبان مجازی و جفت گواهی/کلید مورد استفاده توسط TLS را بر اساس پسوند server_name در درخواست TLS handshake تعیین می‌کند.

روتر لبه، پسوند server_name را در درخواست TLS handshake می‌خواند و سپس از آن برای جستجوی نام‌های مستعار میزبان از تمام میزبان‌های مجازی استفاده می‌کند. اگر روتر تطابقی با نام مستعار میزبان تشخیص دهد، از گواهی و کلید TLS از میزبان مجازی مرتبط با نام مستعار میزبان استفاده می‌کند. اگر تطابقی پیدا نشود، handshake TLS با شکست مواجه می‌شود.

به جای اینکه TLS handshake با شکست مواجه شود، می‌توانید یک جفت گواهی/کلید پیش‌فرض تعریف کنید، همانطور که در بخش‌های بعدی توضیح داده شده است.

تعریف یک جفت گواهی/کلید پیش‌فرض در Edge برای فضای ابری

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 که به ترتیب حروف الفبا در ابتدا قرار می‌گیرد، از cert/key استفاده می‌کند. برای مثال، درخواست از طریق پورت ۴۴۳ وارد می‌شود و دو میزبان مجازی برای example org در محیط prod تعریف شده است:

• نام میزبان مجازی = default
• نام میزبان مجازی = test

در این مثال، روتر از cert/key از میزبان مجازی با نام 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. این مراحل را روی تمام روترهای باقی مانده تکرار کنید.

به جای استفاده از cert/key از میزبان مجازی پیش‌فرض، می‌توانید cert/key پیش‌فرض را به طور صریح روی روتر تعریف کنید. از روش زیر برای تعریف یک جفت cert/key پیش‌فرض صریح استفاده کنید:

1. در اولین گره روتر، گواهی و کلید خصوصی را در مکانی روی گره روتر که توسط کاربر apigee قابل دسترسی است، کپی کنید. به عنوان مثال، /opt/apigee/customer/application .
2. مالکیت فایل‌ها را به کاربر 'apigee.' تغییر دهید:

   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 برای Cloud و برای استقرارهای Private Cloud پشتیبانی می‌کند. به طور پیش‌فرض، SNI در پردازنده‌های پیام Edge برای Cloud فعال و در Private Cloud غیرفعال است.

استفاده از SNI در بک‌اند در Edge برای فضای ابری خصوصی

برای اینکه Edge برای Private Cloud با backend های موجود در Target Backend سازگار باشد، Apigee به طور پیش فرض SNI را غیرفعال کرده است. اگر target backend شما برای پشتیبانی از SNI پیکربندی شده است، می‌توانید این ویژگی را همانطور که در زیر برای نسخه Edge شما توضیح داده شده است، فعال کنید.

هیچ پیکربندی خاص دیگری برای Edge لازم نیست. اگر محیط هدف شما برای SNI پیکربندی شده باشد، Edge از آن پشتیبانی می‌کند. Edge به طور خودکار نام میزبان را از URL درخواست استخراج کرده و آن را به درخواست TLS handshake اضافه می‌کند.

فعال کردن SNI بین Edge و backend برای نسخه Edge 4.15.07.0x

برای فعال کردن SNI از روش زیر استفاده کنید:

1. در اولین گره پردازشگر پیام، فایل /opt/apigee4/conf/apigee/message-processor/system.properties را در یک ویرایشگر باز کنید.
2. ویژگی زیر را در system.properties روی true تنظیم کنید:

   jsse.enableSNIExtension=true

3. پردازنده‌های پیام را مجدداً راه‌اندازی کنید:

   /opt/apigee4/bin/apigee-service message-processor restart

4. این مراحل را روی تمام پردازنده‌های پیام باقی‌مانده تکرار کنید.

فعال کردن SNI بین Edge و backend برای 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. این مراحل را روی تمام پردازنده‌های پیام باقی‌مانده تکرار کنید.