מחפש פתרון לחסימת גישה לשרת AWS ללא IP קבוע

פורום רשתות, IT ומחשוב כללי - רשתות, ראוטרים, מחשבים ניידים, אביזרים וכו'.
sys_admin
חבר מביא חבר
חבר מביא חבר
הודעות: 3685
הצטרף: ינואר 2014
מיקום: גליל מערבי
נתן תודות: 9 פעמים
קיבל תודות: 718 פעמים

נושא שלא נקרא #16 

RamiX כתב:
...
...
·

מהדיון הבנתי בסוף שהכוונה היא להקים את ה VPN ב AWS (ולא בחברה כאן ולחבר אליה את השרתים)
האמת שזה חומר למחשבה.

אבל חברים, אני חייב לציין שאני קורה את התגובות וזה דיון מרתק. באמת חבל"ז
...
·
ב AWS מקימים את שרת VPN ובחברה את היחידה של לקוח VPN וה vpn road warriors יתחברו כבר גם לשרת שב AWS, ומשם יקבלו גישה גם לשרתים שהם aws instances וגם להגיע משם למשאבים הדרושים שבחברה בישראל. זהו עולם המופלא של אינטרנט ו IP. רק מומלץ מאוד, אם לא מבינים בידיוק איך לבצע את הפעולות הפשוטות אלה להזמין בן אדם שטיפה מבין במחשבים ויכול לבצע את כל זה.

eran405
אחראי תחום רשתות
אחראי תחום רשתות
הודעות: 3388
הצטרף: פברואר 2012
נתן תודות: 380 פעמים
קיבל תודות: 790 פעמים

נושא שלא נקרא #17 

@sys_admin
·

מוזר, ה-Site to Site ב-OpenVPN הוא באמת Client/Server. יש בכלל הבדל ב-OpenVPN בין Site to Site VPN לבין Remote Access VPN ואם כן מה הוא? האם הצד של ה-Server יכול להרים את החיבור מול ה-Client או שה-Server רק מאזין? האם אפשר להגביל את החיבור של של ה-Client רק לכתובת מסויימת לפי FQDN כמו ש @RamiX מבקש? האם לפחות יש ב-OpenVPN מנגון אבטחה שמאמת בצורה קריפטולוגית את הזהות של שני הצדדים?

כנראה שה-IPSec Site to Site שיש לדוגמא ב-StrongSwan שונה לגמרי: במקרה הזה שני הצדדים סימטריים לגמרי ומכירים אחד את השני, מה שנותן שני יתרונות (אם אני מבין נכון את המצב ב-OpenVPN):

א. כל אחד מהצדדים יכול להרים את החיבור במידת הצורך.

ב. כל אחד מהצדדים יכול לוודא שהצד השני הוא באמת מי שמצפים: דבר ראשון, בהנחה שלשני הצדדים יש IP פומבי מוודאים את הכתובת ממנה מגיע החיבור (הצד שיוזם את החיבור מן הסתם משתמש ב-IP של הצד השני). בנוסף יש מנגון אבטחה לוודא את זהות שני הצדדים, שיכול להשתמש ב-X.509 certificates או במפתחות RSA או ב-PSK (חלש מבחינת אבטחה ולכן פחות מומלץ).

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

שלא לדבר על משהו כמו WireGuard שבכלל נראה הרבה יותר נקי ורובוסטי (לצערי, עדיין לא יצא לי להשתמש בו בפועל). בתקווה זה העתיד.
נערך לאחרונה על ידי eran405 ב 05/06/2019 19:59, נערך פעם 1 בסך הכל.

eran405
אחראי תחום רשתות
אחראי תחום רשתות
הודעות: 3388
הצטרף: פברואר 2012
נתן תודות: 380 פעמים
קיבל תודות: 790 פעמים

נושא שלא נקרא #18 

RamiX כתב: מהדיון הבנתי בסוף שהכוונה היא להקים את ה VPN ב AWS (ולא בחברה כאן ולחבר אליה את השרתים)
האמת שזה חומר למחשבה.
...
·

אפשר ככה ואפשר ככה. זה מאד תלוי בצרכים שלכם.

אם כל או לפחות רב התקשורת של החיבורים מרחוק (ה-roadwarriors) היא להתחבר ל-AWS, זה לא ממש הגיוני שהם יתחברו לשרת VPN בחברה ומשם ינותבו על גבי חיבור ה-Site to Site ל-AWS (זה כמובן אפשרי אבל למה?).

אם כל או לפחות רב התקשורת של החיבורים מרחוק (ה-roadwarriors) היא להתחבר למחשבים/שרתים שיושבים באתר של החברה אז יותר הגיוני להתחבר לשרת VPN בחברה. במקרה המדובר זה קצת פחות נורא אם הם בכל זאת מתחברים ל-AWS ומשם מנותבים על גבי ה-Site to Site לאתר של החברה כי מן הסתם החיבור של ה-AWS "קצת" יותר רציני מהחיבור שיש לאתר של החברה.

sys_admin
חבר מביא חבר
חבר מביא חבר
הודעות: 3685
הצטרף: ינואר 2014
מיקום: גליל מערבי
נתן תודות: 9 פעמים
קיבל תודות: 718 פעמים

נושא שלא נקרא #19 

eran405 כתב:@sys_admin
·

מוזר, ה-Site to Site ב-OpenVPN הוא באמת Client/Server. יש בכלל הבדל ב-OpenVPN בין Site to Site VPN לבין Remote Access VPN ואם כן מה הוא? האם הצד של ה-Server יכול להרים את החיבור מול ה-Client או שה-Server רק מאזין? האם אפשר להגביל את החיבור של של ה-Client רק לכתובת מסויימת לפי FQDN כמו ש @RamiX מבקש? האם לפחות יש ב-OpenVPN מנגון אבטחה שמאמת בצורה קריפטולוגית את הזהות של שני הצדדים?

כנראה שה-IPSec Site to Site שיש לדוגמא ב-StrongSwan שונה לגמרי: במקרה הזה שני הצדדים סימטריים לגמרי ומכירים אחד את השני, מה שנותן שני יתרונות (אם אני מבין נכון את המצב ב-OpenVPN):

א. כל אחד מהצדדים יכול להרים את החיבור במידת הצורך.

ב. כל אחד מהצדדים יכול לוודא שהצד השני הוא באמת מי שמצפים: דבר ראשון, בהנחה שלשני הצדדים יש IP פומבי מוודאים את הכתובת ממנה מגיע החיבור (הצד שיוזם את החיבור מן הסתם משתמש ב-IP של הצד השני). בנוסף יש מנגון אבטחה לוודא את זהות שני הצדדים, שיכול להשתמש ב-X.509 certificates או במפתחות RSA או ב-PSK (חלש מבחינת אבטחה ולכן פחות מומלץ).

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

שלא לדבר על משהו כמו WireGuard שבכלל נראה הרבה יותר נקי ורובוסטי (לצערי, עדיין לא יצא לי להשתמש בו בפועל). בתקווה זה העתיד.
...
·
דבר ראשון שצריכים להבין זה את הנקודה ש OpenVPN זו מערכת גמישה ביותר, מאובטחת ביותר וגם בעלת אפשרויות מגוונות כאלה שאף פרוטוקול VPN שקיים לא יכול להתקרב לפרומיל של יכולות שלה. קיימים בה אפשרויות עבודה מרובות מתצורת שרת לקוח מתקדמת ועד ל P2P עם מפתחות סטטיים. מן הסתם שלא נשתמש בתצורה של P2P עם מפתחות סטטיים, כפי שזה קיים בפרוטוקולים אחרים, אלה שנשתדל לנצל את האפשרויות הגלומות בפרוטוקול זה. מבחינת האבטחה והצפנה מדובר על מערכת שעובדת עם מספר רמות של הצפנה, שאחת מהן היא רמה של שימוש בסרטיפיקטים שנדרש להנפיק אותם ב Certificate Autority , שאותו ננהל גם, למשל גם ב PFSense . מנגנון זה נותן אפשרות לייצר גם מפתחות ציבוריים ופרטיים ברמות קושי שונות וגם לבצע Certificate Revocation לסרטיפיקטים שנחשפו, למשל מחשב נייד שנגנב, ובו הייה מותקן לקוח של OpenVPN . תוך שנייה ניתן לחסום את הלקוח הספציפי זה מלהתחבר לשרת. כמובן שגם קיימות רמות אימות על בסיס של CN שבתוך הסרטיפיקט ועל זה מתלבשת שכבה של הגנה על בסיס של שם משתמש וסיסמה, שמזוההים דרך שרת RADIUS שגם הוא יכול להיות חיצוני או מובנה ב PFSense . פרוטוקול זה יודע גם לרתום גם התקני האצת הצפנה בחומרה, כאלה למשל כמו AES-NI, כך שניתן להגיע למהירויות העברת נתונים גבוהות ביותר.
פרוטוקול זה ניתן להפעיל גם מעל TCP או מעל UDP לפי הצורך, בניגוד לכל מני פרוטוקולי VPN שבהם לא ניתן לשנות את התעבורה. גם הוא תומך ב Dual Stack לצורך ה IPv6 וכך לכל רשת מרוחקת אני גם מספק קישוירות כזו, דבר שלא אפשרי בלעדיו. פרוטוקול זה משמש גם כמנהל של טבלאות ניתוב ( כפרוטוקול ניתוב דינאמי ) ומאפשר לנתב את הרשתות המרוחקות למרכז והפוך. ואם כל זה לא מספיק, פרוטוקול זה יודע גם להעביר את שכבה 2 של מודל ה OSI מעל לשכבה שלוש, שזה אומר שהוא יכול להעביר את Ethernet מעל IP ( ממש לחבר כמה broadcasts domains דרך חיבור אינטרנט !!! ) . האפשרויות שזה פותח הן ממש דימיוניות. כל מה שקיים כאן מחינם עף מערכת קניינית בעשרות אלפי דולרים לא יכולה לספק. זו ממש דוגמה חייה לביטוי שידע זה כוח ובמקרה זה, זה כוח עצום.

כמובן שכל הסיפורים של הגבלות לפי IP או לפי FQDN , או כל מני משחקים ברמה של ציוד SMB , שזה לגן ילדים אפשר אפילו ולא להזכיר, כי זה מצחיק למערכת כזו, למרות למי שממש רוצה זה קיים בה.
עכשיו אני מקווה שזה כבר מובן יותר למה לא ניתן אפילו להשוות את OpenVPN עם כל מני דברים אחרים שהוזכרו כאן כמו StrongSwan , שלא מסוגל אפילו לעבור בצורה תקינה דרך NAT של ספק אינטרנט ומתחיל להתנהג בצורה לא צפוייה גם ללא מעבר דרך NAT, אלה במקומות שהספקים מבצעים מניפולצייה על התעבורה, דבר הנהוג בקרב ספקי אינטרנט בישראל.

eran405
אחראי תחום רשתות
אחראי תחום רשתות
הודעות: 3388
הצטרף: פברואר 2012
נתן תודות: 380 פעמים
קיבל תודות: 790 פעמים

נושא שלא נקרא #20 

@sys_admin
·

תודה על התגובה "לעניין". לא ברור למה ניסיתי לשאול משהו.

---

לאחרים שקוראים את זה, אם הבנתם משהו (ברמה הטכנית) מהפוסט לעיל של sys_admin אשמח להסבר. באמת הייתי רוצה להבין את ההבדלים בין OpenVPN ל-IPSec עם IKEv2 לדוגמא דרך StrongSwan (ו/או אופציות מובילות אחרות). מחיפוש מעמיק יחסית באינטרנט רואים בבירור שהתמונה לא שחור לבן כמו ש-sys_admin מנסה להציג (הדבר שהוא משתמש בו הוא הכי טוב בעולם וכל השאר פשוט ***).

כמובן גם שה"ליכלוכים" על strongswan וכו' הם פשוט לא נכונים: לדוגמא כל הנושא של NAT traversal הוא חלק מהסטנדרטים של IKE (לדוגמא זה בשביל IKEv1 והוא כבר חלק מובנה מ-IKEv2). StrongSwan לדוגמא תומך בזה בצורה מלאה, ועובד מצוין, ללא קונפיגורציה מיוחדת, גם במקרה שאחד הצדדים מאחורי NAT. לדעתי הוא גם עובד במקרה ששני הצדדים מאחורי NAT, בהינתן שלפחות באחד מהם מפנים את הפורטים הרלוונטים.

אני גם לא יודע על איזה "מניפולצייה על התעבורה, דבר הנהוג בקרב ספקי אינטרנט בישראל" הוא מדבר אבל יש לי Site to Site של StrongSwan שעובד ביציבות כבר חודשים בין 015 להוטנט (במקרה הספציפי הזה ללא NAT אבל אני יודע בוודאות שהוא עובד טוב גם במקרה של NAT).
מה שכן, התמיכה של IKEv2/IPSec מעל TCP היא בין בעייתית ללא קיימת (לדוגמא StrongSwan תומך אך ורק ב-UDP; בתיאוריה כן אפשר להעביר IKEv2/IPSec מעל TCP אבל אני לא יודע אם קיים לזה מימוש). לעומת זאת ב-OpenVPN אפשר (ואולי גם מקובל?) להשתמש ב-TCP/443 ואז זה נראה כמו תקשורת HTTPS. אני כמובן לא נתקלתי באף ספק בארץ שאפילו חוסם טורנטים ובטח שלא ספק שעושה בעיות עם תקשורת של UDP באופן כללי (אפילו עם הספק חוסם את הפורטים הסטדנרטיים של IKEv2/IPSec אפשר, לפחות ב-StrongSwan, לשנות אותם).

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

מניסיוני האופציות "לגן ילדים", פשוטות יחסית להרמה ותיחזוק גם למשתמש שלא מבין יותר מידי. ממחקר לא קטן בנושא, למיטב הבנתי, אופציות כמו StrongSwan או WireGuard מאובטחות לא פחות מ-OpenVPN (כש-WireGuard יהיה בשל הוא יהיה יותר מאובטח מ-OpenVPN). במיוחד למי שמנסה לקנפג OpenVPN ומסתבך, אני ממליץ בחום להסתכל על אופציות האחרות שקיימת בפלטפורמה שלו.

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

שלח תגובה

חזור אל “רשתות, אינטרנט ו- Fiber”