تسجيل قفزة TCP لوكيل CONNECT المؤسسي في Istio

استخدم نمط ServiceEntry للوكيل الخارجي في وضع sidecar لمستمع الوكيل، مع إبقاء اختيار التطبيق للوكيل وتفويض الهدف منفصلين.

لعبء عمل يختار بالفعل وكيل CONNECT مؤسسيًا، يرى الـ sidecar اتصالًا بذلك المستمع. سجّل مسار القفزة الأولى كـ TCP وفق نمط الوكيل الخارجي الموثق في وضع sidecar:

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: corporate-forward-proxy
spec:
  hosts:
    - proxy.corp.example
  addresses:
    - 203.0.113.10/32
  ports:
    - number: 3128
      name: tcp-proxy
      protocol: TCP
  location: MESH_EXTERNAL
  resolution: NONE

استبدل عنوان IP والمنفذ بنقطة نهاية الوكيل الفعلية. يطابق هذا المثال TCP حسب العنوان؛ hosts لا يختار موقعًا مشفرًا داخل النفق.

لا يزال التطبيق بحاجة إلى إدخال الوكيل المدعوم لديه، مثل HTTPS_PROXY=http://203.0.113.10:3128 لعميل متوافق. لا يجعل ServiceEntry تطبيقًا غير مُهيأ يُصدر طلبات وكيل.

سجّل مسار الوكيل هذا بدلًا من كل موقع يمرّ عبره لاحقًا. الوكيل الأمامي يفتح الاتصال اللاحق ويقرر ما إذا كان الحساب والوجهة المطلوبة مسموحين. إذن الـ mesh للقفزة الأولى TCP لا يمنح ذلك التفويض ولا تعليمات اختيار المسار للتطبيق.

مقالات ذات صلة