למה GRE ו-ESP נכשלים דרך שער NAT של AWS

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

מערך הכללים אינו מערך הפרוטוקולים

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

מפרט פרוטוקולי שער ה-NAT של AWS מונה TCP, UDP ו-ICMP עבור השירות המנוהל. זו הקבוצה הנתמכת כולה. כלל הרשאה לפרוטוקול IP אחר אינו יכול להרחיב אותה, משום שהכלל מוערך הרבה לפני שמגיעים לנתיב ההעברה של השער.

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

PPTP מראה למה בדיקת פורט משקרת

PPTP היא הדוגמה הישנה הברורה ביותר לבדיקת פורט שאינה מוכיחה דבר. היא פותחת חיבור בקרה ב-TCP על פורט 1723 ואז מעבירה את נתוני המנהרה מעל GRE, שהוא פרוטוקול IP 47. פרוטוקול 47 אינו פורט TCP 47, ולשני המספרים אין שום קשר זה לזה מלבד שיתוף ספרות.

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

אותו היגיון חל על כל פרוטוקול שערוץ הבקרה שלו הוא TCP או UDP בעוד נתיב הנתונים שלו אינו כזה.

IPsec שורד רק כ-UDP

IPsec הוא המקרה שבו התשובה מותנית ולא שלילה מוחלטת. AWS מתעדת מעבר NAT כהסדר הנתמך עבור IPsec דרך שער NAT. עם NAT-T מנוהל משא ומתן, ESP נעטף בתוך UDP והשער רואה UDP רגיל במקום פרוטוקול 50.

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

VPN מבוסס TCP או UDP מתאים למערך ההובלה המתועד ועדיין עלול להיכשל מסיבות של ניתוב, סינון או אימות. התאמה למערך היא הכרחית, לא מספקת.

בדקו את הנתיב לפני הרחבת המדיניות

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

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

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

כאשר ההובלה אינה מתאימה

אם הפרוטוקול החיצוני מחוץ למערך הנתמך, התיקון הוא ארכיטקטוני: בחרו הובלה שהנתיב יכול לשאת, או העבירו את היציאה למשהו שנושא את זו שאתם צריכים. OpenVPN מעל UDP, WireGuard מעל UDP ומנהרות מבוססות TLS מתאימים כולם למערך המתועד. מופע NAT בניהול הלקוח הוא האפשרות כאשר פרוטוקול מסוים חייב לעבור והעלות התפעולית של הפעלתו מקובלת.

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

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