רישום קפיצת ה-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 הראשונה אינה מספקת לא את הרשאת הפרוקסי הזו ולא הוראת בחירת מסלול ליישום.

מאמרים קשורים