שער S3 או נקודת קצה של ממשק ללקוח מקומי?

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

הפרד בין סוגי נקודות הקצה לפי המקום שבו הבקשה מתחילה

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

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

aws ec2 describe-vpc-endpoints --query "VpcEndpoints[].{Id:VpcEndpointId,Type:VpcEndpointType,Service:ServiceName,State:State}" --output table

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

בנה את הנתיב לכתובת הממשק לפני שתבדוק את S3

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

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

ip route get 10.60.4.37
nc -vz 10.60.4.37 443
openssl s_client -connect 10.60.4.37:443 -servername bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com </dev/null

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

החלט איזו תשובת DNS מקבלת האפליקציה

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

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

dig +short bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com
aws s3api head-bucket --bucket example-artifacts --endpoint-url https://bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com

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

נגישות אינה הרשאה

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

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

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