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

[RamiX]

שלום לכם, זהו פוסט ראשון שלי כאן, לאחר שצפיתי ולמדתי המון מפורום זה.

שאלתי למקצוענים היא כך:
עד היום בחברה שלי היה IP קבוע אשר שימש אותי בפיירוול של AWS לחסימת גישה לשרתים. לשרתים שלנו (הפרודקשן) חייבים לגשת אך ורק מהחברה.
אתמול עברנו להוט 200 מגה, ולמרות שהבטיחו לי שיש אפשרות ל IP קבוע, מסתבר שזה סיפור. כך שהתעוררתי היום כאשר אין לי IP קבוע בחברה.
השאלה היא האם אפשר לחסום את הגישה לשרתים בצורה אחרת שלא מסתמכת על IP קבוע. כמובן שכיום הגישה לשרתים מוגנת בנוסף ב CERTIFICATES אך זה לא מספק.
או לחלופין, האם יש דרך בכל זאת להגדיר IP קבוע דרך הוט (הם הציעו לקחת ראוטר של FORTINET אך לא מתאים לי מאחר ובחברה יש תשתית קיימת עם ראוטר רציני מאוד)

תודה לעונים

[ilane]

הפיתרון זה לקנות IP וקו "נל"ן" ולא להשתמש בחייגן

[RamiX]

הפיתרון זה לקנות IP וקו "נל"ן" ולא להשתמש בחייגן

...

·
מה זה קו נל"ן ?
הקו החדש של הוט הוא ללא חייגן, וזו עיקר הבעיה

[sys_admin]

הפתרון המאובטח והיגיוני הוא להשתמש בערוץ VPN Site to Site ( מן הסתם ב OpenVPN ) מוצפן בין הרשת INTRANET וירטואלית שיצרתם בשרתים של AMAZONE , לבין רשת פיזית שלכם. כך לא יהיה משנה מה הכתובת החיצונית שספק מקצה לכם ( אם בכלל ), גם התעבורה לא תהייה גלוייה לכל, גם אך אחד אחר לא מהרשת פנימית שלכם לא יוכל להתחבר לשרתים וירטואליים שיצרתם או בכלל לרשת זו שיצרתם ב AMAZONE, וגם כל התקשורת בין השרתים וירטואליים והרשת LAN שלכם תהייה בתוך הרשת הפרטית שלכם. זה דבר שהוא א' ב' בתכנון של עבודה רשתית מול שרתים שנמצאים בחוות שרתים מרוחקת באחסון ובטח ובטח, אם מדובר על שרתים וירטואליים שם.

[ilane]

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

פיתרון אפשרי זה להריץ סקריפט בקרון שיזהה שינוי של הIP (למשל ידע לשלוף את IP מאתר כמו what is my IP ולהשוות אותו מול הבדיקה הקודמת)
במידה והIP השתנה להשתמש בaws cli כדי לעדכן את הsecurity groups

https://docs.aws.amazon.com/cli/latest/ ... gress.html

אני די בטוח שאפשר למצוא מימושים של זה בgithub...

[eran405]

@RamiX
·

אני לא מכיר את ה-firewall של AWS אבל אם הוא משתמש ב-iptables אז זה באמת בעיה להשתמש ב-FQDN ישירות. במקרים כאלה הפתרון הכי פשוט הוא להריץ סקריפט פשוט שבודק האם ה-IP השתנה כל X זמן ואם צריך מעדכן את ה-iptables.

בנוסף שם לב שההגנה שציינת שכבר יש לך, בעזרת CERTIFICATES, היא הגנה אמיתית של אבטחת מידע ושווה הרבה יותר מאשר הגבלה לפי כתובת מקור (דבר שבכלל לא נחשב הגנה לפי אבטחת מידע). להגבלה לפי כתובת מקור יש די הרבה התקפות מהסוג של IP spoofing שבחלק המקרים לא כזה קשה לבצע. להגנה שמוגדרת היטב עם CERTIFICATES לא אמורה להיות התקפה בכח חישוב סביר. כמו שציינתי לעיל די בטוח שיש דרך פשוטה יחסית שתוכל להפעיל "הגנה" לפי IP דינמי אם זה באמת מרגיע אותכם (במעשי זה יכול להקשות על תוקפים, במיוחד עם התוקפים מחפשים מטרות קלות, אבל כאמור זאת לא באמת הגנה וכמעט זניח יחסית להגנה אמיתית עם CERTIFICATES).

אפשר גם לשקול את ההצעה לעיל של VPN Site to Site, ושה-VPN יהיה מוגן ע"י CERTIFICATES או מפתחות קריפטולוגיים בנוסף לכתובות של שני הצדדים. אלא אם יש בעיה במימוש של ההמגנון "הרגיל" של הגישה ל-AWS אני לא רואה למה שזה יתן יותר אבטחה אבל אולי זה פתרון יותר נח במקרה שלכם.

לגבי ה-VPN site to site:

א. OpenVPN שציון לעיל הוא באמת אופציה אחת אבל יש עוד הרבה כמו IKEv2 או WireGuard ועוד. תבדוק מה נתמך בצורה טובה ע"י AWS וע"י הציוד שיש בקצה שלכם.

ב. ההערה של @ilane לא נכונה כי בכל ה-VPNים שיצא לי לעבוד איתם אין שום בעיה להשתמש ב-FQDN ולכן אין שום בעיה עם ה-IP דינמי. יותר מזה אפשר אפילו לעשות site to site כאשר אחד הצדדים מאוחרי NAT ותמיד הצד השני הוא זה שיוזם את החיבור.

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

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

[sys_admin]

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

פיתרון אפשרי זה להריץ סקריפט בקרון שיזהה שינוי של הIP (למשל ידע לשלוף את IP מאתר כמו what is my IP ולהשוות אותו מול הבדיקה הקודמת)
במידה והIP השתנה להשתמש בaws cli כדי לעדכן את הsecurity groups

https://docs.aws.amazon.com/cli/latest/ ... gress.html

אני די בטוח שאפשר למצוא מימושים של זה בgithub...

...

·

כל הרעיון בתפיסה של VPN Site To Site הוא בזה שהאתר שמתחבר לאתר שנמצא בו שרת VPN זה, לא משנה מה כתובת WAN שהוא מקבל וכתבות זו יכולה להיות קבועה, משתנה או אפילו לא ציבורית ( מאחורי NAT ). בגלל זה בפתרון זה משתמשים מתאיגדי ענק ועד לסניפים מרוחקים של עסקים זעירים. גם הרמת אבטחה ונוחות שמקבלים בצורה כזו היא בסדרי גודל גבוההים יותר מכל פתרון אחר. כבר החלק הזה שהשרתים המרוחקים, שבפועל נמצאים באתר מרוחק ( ביבשה אחרת ), מתפקדים בתוך הרשת מקומית ואך אחד לא יכול לגשת עליהם מבחוץ, אלה, אם כן הוגדר אחרת בכללים של FIREWALL אירגוני, כבר החלק הזה נותן את כל התמונה של היתרונות הרבים שכלולים בתפיסה זו. גם מדובר על פתרון הכי תקני וטריוויאלי בנושא, שניתן לממש אותו גם עם כלים חינמיים ובדוקים, כאלה כמו PFSENSE למשל ( בשני הצדדים ), מה שכן, גם AMAZON תומכים ומנגישים אותו כך שניתן לפרוס את PFSENSE בצורה מהירה ופשוטה. גם האמינות ושרידות של מימוש זה הוכחה כבר מזה עשרות שנים וגם אני משתמש בזה בפרוייקטים רבים שאני מתכנן.

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

[eran405]

כל הרעיון בתפיסה של VPN Site To Site הוא בזה שהאתר שמתחבר לאתר שנמצא בו שרת VPN ....

...

·

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

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

כלומר צדקת בהכל חוץ מהטרמינולוגיה של ה-site to site. אפשר כמובן להתווכח עד מחר על טרמינולוגיה אבל ממנה שאני מכיר בציודים שונים ובמקורות באינטרנט תמיד Site to Site מדבר על מה שהסברתי לעיל:
https://ipwithease.com/site-to-site-vpn ... ccess-vpn/
https://openvpn.net/vpn-server-resource ... in-detail/
https://openvpn.net/for/remote-access/

[RamiX]

הפתרון של ה VPN הוא רעיון מעולה.
אבל עכשיו שאני חושב על זה, היעדר IP קבוע גורם לי בעיה יותר חמורה, כרגע כל פעם שצריך להתחבר ל VPN לחברה ממקום מרוחק, צריך לשנות את ה IP (באיזור שלנו יש הרבה הפסקות חשמל כך שהסבירות שזה ישתנה גבוהה)
האם אפשר לחבר VPN לפי דומיין?

[eran405]

האם אפשר לחבר VPN לפי דומיין?

...

·

כן, אין שום בעיה.

[sys_admin]

מן הסתם שכל הרעיון של תפיסת VPN Site To Site גם של OpenVPN הוא בזה, שיש שרת ( במרכז ) , שעליו מתחברים לקוחות ( סניפים ) שזה יכול להיות סניף בודד או סניפים רבים. גם מאחורי שרת של OpenVPN Site To Site יש את הסגמנט של תת רשת LAN שלו, שהוא מנתב אותה לכל הלקוחות ( לסניפים ) וגם מאחורי הלקוחות נמצאות רשתות משנה שלהם, שהם מנתבים אותם לכיוון של השרת זה וכך ניתן גם להגיע מסניף אחד לשני, אם יש צורך, כאילו שמדובר ברשת אחת. כמובן שבכל צומת חיבור ( בכל מערכת PFSENSE למשל, שמבצעת את הטרמינצייה של החיבורים ) קיים גם מנגנון של FIREWALL שקובע על ידי חוקים קשיחים, למי מותר לתקשר עם מי.

אלה הם דברים בסיסיים ביותר של רשתות תקשורת, כפי שהם קיימים כבר עשרות שנים. צירפתי כמה צילומי מסך, אחד משרת VPN SITE TO SITE, אחד מהלקוח שלו ואחד של ניתוב של גישה מסגמנט רשת אחת, שנמצא מאחורי לקוח VPN לסגמנט אחר, שגם נמצא מאחורי לקוח VPN שני, והם עוברים דרך שרת VPN Site To Site המדובר.

[sys_admin]

הפתרון של ה VPN הוא רעיון מעולה.
אבל עכשיו שאני חושב על זה, היעדר IP קבוע גורם לי בעיה יותר חמורה, כרגע כל פעם שצריך להתחבר ל VPN לחברה ממקום מרוחק, צריך לשנות את ה IP (באיזור שלנו יש הרבה הפסקות חשמל כך שהסבירות שזה ישתנה גבוהה)
האם אפשר לחבר VPN לפי דומיין?

...

·
ברגע שיש לך שרת VPN ב AWS, זה ממש לא משנה שהכתובת IP של שספק כאן נותן לך משנה או בכלל היא לא ציבורית. ואת זה כבר הסברתי כאן לפני זה. ברגע שאתה מתחבר, אתה מתחבר ל IP של AMAZON, ושם בדרך כלל יש פחות הפסקות חשמל. כך אתה מגיע כבר לשרתים שלך וברגע שגם מחובר הצד של LAN שלך, אתה מגיע כבר גם לרשת הפנימית שלך בארץ. עד כדי כך פשוט וקל ובלי צורך בחיבור לדומייו.

[sys_admin]

הדבר שצריך להדאיג אותך הרבה יותר זה זה שאותו חיבור שאתה קורה לו 200M של הוט, הוא בעצם חיבור עם מהירות שליחה של עד 5M, בדרך כלל כ 3M. ולעבוד עם חיבור של 3M ועם צרכים שקיימים לנו בשני עשורים אחרונים, זה "טיפ טיפה" יומרני, אם לא להגיד אפילו בלתי אפשרי בעליל.

[RamiX]

...

...

·
ברגע שיש לך שרת VPN ב AWS, זה ממש לא משנה שהכתובת IP של שספק כאן נותן לך משנה או בכלל היא לא ציבורית. ואת זה כבר הסברתי כאן לפני זה. ברגע שאתה מתחבר, אתה מתחבר ל IP של AMAZON, ושם בדרך כלל יש פחות הפסקות חשמל. כך אתה מגיע כבר לשרתים שלך וברגע שגם מחובר הצד של LAN שלך, אתה מגיע כבר גם לרשת הפנימית שלך בארץ. עד כדי כך פשוט וקל ובלי צורך בחיבור לדומייו.

...

·

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

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

[RamiX]

הדבר שצריך להדאיג אותך הרבה יותר זה זה שאותו חיבור שאתה קורה לו 200M של הוט, הוא בעצם חיבור עם מהירות שליחה של עד 5M, בדרך כלל כ 3M. ולעבוד עם חיבור של 3M ועם צרכים שקיימים לנו בשני עשורים אחרונים, זה "טיפ טיפה" יומרני, אם לא להגיד אפילו בלתי אפשרי בעליל.

...

·

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

[sys_admin]

...

...

·

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

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

...

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

[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 שבכלל נראה הרבה יותר נקי ורובוסטי (לצערי, עדיין לא יצא לי להשתמש בו בפועל). בתקווה זה העתיד.

[eran405]

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

...

·

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

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

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

[sys_admin]

@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]

@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 עדיין בפיתוח אקטיבי עם כל החסרונות שמשתמעים מזה.