S3: נקודת קצה של שער או של ממשק לגישה מהרשת המקומית

שני סוגים של נקודות קצה של S3 נראים ניתנים להחלפה בסקירת תכנון ומתנהגים אחרת לגמרי ברגע שהלקוח נמצא מחוץ לאתר. נקודת קצה של שער היא אינטגרציה עם טבלת הניתוב בתוך VPC, ולכן בקשה מ-VPN של האתר לעולם לא מגיעה אליה כיעד פרטי. נקודת קצה של ממשק מציבה כתובות פרטיות על ממשקי רשת, וזה משהו שנתיב היברידי באמת יכול להגיע אליו. כל מה שלהלן תלוי במי מהשניים שבחרתם.

החליטו לפי כניסת הרשת, לא לפי שם השירות

התחילו מהמקום שבו התעבורה נוצרת, כי זו השאלה שסוג נקודת הקצה עונה עליה. עומס עבודה בהקשר VPC נתמך יכול להשתמש בנקודת קצה של שער ולעולם לא צריך כתובת פרטית משלו. עומס עבודה באתר המקומי צריך כתובת פרטית שאליה הוא יכול לנתב, וזה מה שנקודת קצה של ממשק מספקת. אם תכנון מערבב את שניהם, שני סוגי נקודות הקצה יכולים להתקיים יחד ב-VPC אחד, וזה סידור רגיל ולא כפילות.

ערבוב ביניהם אינו הבעיה. ההנחה שסוג אחד מכסה את האחר היא הבעיה.

סווגו את הלקוח לפני שתבחרו משהו. סביבת עבודה בתוך ה-VPC, מכולה מאחורי שער NAT ויישום בסניף הם שלושה מקורות שונים, ורק האחרון מחייב את הכניסה ההיברידית. כתבו את הסיווג הזה לצד מלאי נקודות הקצה כדי שהבודק הבא יראה מדוע כל נקודת קצה קיימת.

מה דורש נתיב הממשק מקצה לקצה

נקודת קצה של ממשק מעניקה נגישות לכתובות פרטיות, ונגישות היא רק אחד מארבעה דרישות. הרשת המקומית צריכה נתיב לכתובות האלה, צד ה-VPC צריך נתיב חזרה, קבוצת האבטחה של נקודת הקצה חייבת לאפשר את טווח המקור, וכל מכשיר בדיקה ביניהם חייב לאפשר את הזרימה. נתיב למופע כלשהו ב-VPC אינו מוכיח אף אחד מהארבעה.

עבדו מהקצה הרחוק לאחור. ודאו שממשקי הרשת של נקודת הקצה קיימים בתת-הרשתות שאתם מצפים להן, ואז ודאו שקבוצת האבטחה שלה מאפשרת את הטווח המקומי האמיתי ולא מציין מקום. לאחר מכן בדקו שהמנהרה או הקו נושאים את נתיב החזרה באותו כיוון. הבדיקה היא הצעד שאנשים מדלגים עליו, כי רכיב אמצעי שמתיר את החיבור עדיין יכול להפיל גוף תגובה גדול יותר, וזה נראה כמו בעיית תפוקה ולא בעיית מדיניות.

בדקו עם הפעולה המורשית הקטנה ביותר שזמינה ולא עם הורדה גדולה. הכשל מופיע מוקדם יותר ועם פחות תעבורה להסביר.

ה-DNS הולך אחרי מקור השאילתה, לא אחרי ה-VPC

נקודת קצה שקיימת אינה מפנה דבר בעצמה. היישום מקבל את השם שהמפענח שלו החזיר, והמפענח עונה לפי התצוגה שמותרת לו. מופע בתוך ה-VPC ומחשב נייד במשרד שואלים שתי שאלות שונות ושניהם יכולים לקבל תשובות נכונות ושונות. אימות של אחד ומסקנה על האחר הוא הדרך שבה בדיקה שעוברת הופכת לפריסה שנכשלת.

קראו את הגדרת ה-DNS הפרטית של נקודת הקצה כחלק מהתכנון, לא כתיבת סימון שמפעילים אחרי העלייה לאוויר.

אם המפענח במשרד צריך לראות את התצוגה של ה-VPC, הנתיב הזה חייב להיבנות בכוונה, בדרך כלל דרך נקודת קצה נכנסת של מפענח. שאלו מההקשר של היישום עצמו ורשמו איזה מפענח ענה. תוצאה שנאספה במארח מפתח בתוך ה-VPC מתארת את התצוגה של המפתח ולא שום דבר אחר.

הרשאה נפרדת מנגישות

נקודת קצה נגישה מחזירה שגיאות לבקשות שהמנהל הראשי אינו מורשה לבצע, והשגיאה הזו משמעה שהמערכת פועלת כמתוכנן. מדיניות זהות, מדיניות דלי וכל מדיניות נקודת קצה מוערכות בשכבות משלהן. גישה לרשת מעולם לא העניקה הרשאה.

קבלו את התכנון על בסיס שתי תוצאות: קריאה מורשית לא מזיקה שמצליחה, ודחייה צפויה לזהות או לדלי שאינם נכללים.

aws ec2 describe-vpc-endpoints --filters Name=vpc-id,Values=vpc-0123456789abcdef0
dig +short s3.us-west-2.amazonaws.com @10.0.0.2

רשמו את שם נקודת הקצה, היעד שנפתר והקשר המדיניות לצד כל תוצאה, כי שינוי DNS אחד מאוחר יותר יכול לבטל את כל המסקנה. השוו את העלות הנוכחית ואת המשקל התפעולי של שני סוגי נקודות הקצה לפני שאתם מספקים משהו. נקודת קצה של ממשק קונה כניסה פרטית היברידית, היא אינה דרישה אוניברסלית, ונתיב השער נשאר לעתים קרובות התשובה הטובה יותר לעומסי עבודה בתוך ה-VPC. הבחירה היא לכל לקוח והיא נשארת ניתנת לבדיקה.