האם שימוש ב L2TP/IPsec לצורך Exit Node בלבד מסוכן?

פורום רשתות, IT ומחשוב כללי - רשתות, ראוטרים, מחשבים ניידים, אביזרים וכו'.
DanielGR
סמל אישי של משתמש
גורו רשתות
גורו רשתות
תגובות: 1471
הצטרף: יולי 2023
שם מלא: DanielG
מיקום: Israel
נתן תודות: 225 פעמים
קיבל תודות: 282 פעמים

שליחה #41 

3. ההעדפה שלך ל-TCP מול UDP בכלל לא ברורה: להפך, TCP בתוך TCP נותן ביצועים מזעזעים, וממש לא מומלץ. השימוש של Wireguard ב-UDP נועד באופן ספציפי כדי להימנע מהבעיות האלה. הפרוטוקול בנוי כדי להסתדר עם packet loss, וכמובן שהאחריות על ה-data מנוהלת ע״י הפרוטוקולים הפנימיים. מהבחינה הזו wireguard לא שונה מ-IPSec, שעובד ב-layer 2, גם מעל האינטרנט הציבורי.
...
דיון מעניין. נקודת מבט נוספת לגבי מימוש ה-Tunnel על TCP: אני מגיע מתחום ה-VOIP, ספציפית - SIP. הקמת השיחה מתבצעת על TCP, ואילו המדיה- קול ווידאו ממומש על RTP מעל UDP. הבחירה בUDP איננה מקרית, משום שבמדיה זורמת בזמן אמיתי אי אפשר לשדר מחדש Packet שהלך לעיבוד כי זה יגרום ל-Delay של כל ה-Packets העוקבים.

כעת, הרצת שיחת קול או ווידאו על גבי תווך הממומש ב-TCP היא די בעייתית כאשר קיים Packet loss והרשת איננה אמינה. מה שקורה שמנגנון ה-Retransmission של ה-TCP ידאג לשידור מחדש של Packets, ובכך יגרם Delay מצטבר בשיחה, אובדן סינכרון בין הקול והווידאו (lipsync). TCP ישבש לגמרי את ה-Packet timing. בהיבט הזה UDP עדיף, ובכל שכבות הרשת - צריך שתהיה שכבה אחת שתטפל ב-Retransmission - TCP ולא שתיים.
רשימת הציוד: MikroTik CCR2004-1G-12S+2XS |CRS317-1G-16S-RM | CRS504-4XQ-IN

dr0r
חבר ותיק
חבר ותיק
תגובות: 2186
הצטרף: נובמבר 2018
שם מלא: דרור
מיקום: תל אביב
נתן תודות: 86 פעמים
קיבל תודות: 362 פעמים

שליחה #42 

01/02/2025 22:40  
DanielGR כתב:
דיון מעניין. נקודת מבט נוספת לגבי מימוש ה-Tunnel על TCP: אני מגיע מתחום ה-VOIP, ספציפית - SIP. הקמת השיחה מתבצעת על TCP, ואילו המדיה- קול ווידאו ממומש על RTP מעל UDP. הבחירה בUDP איננה מקרית, משום שבמדיה זורמת בזמן אמיתי אי אפשר לשדר מחדש Packet שהלך לעיבוד כי זה יגרום ל-Delay של כל ה-Packets העוקבים.

כעת, הרצת שיחת קול או ווידאו על גבי תווך הממומש ב-TCP היא די בעייתית כאשר קיים Packet loss והרשת איננה אמינה. מה שקורה שמנגנון ה-Retransmission של ה-TCP ידאג לשידור מחדש של Packets, ובכך יגרם Delay מצטבר בשיחה, אובדן סינכרון בין הקול והווידאו (lipsync). TCP ישבש לגמרי את ה-Packet timing. בהיבט הזה UDP עדיף, ובכל שכבות הרשת - צריך שתהיה שכבה אחת שתטפל ב-Retransmission - TCP ולא שתיים.
...
בהחלט. ולעומת זאת, עם TCP מעל TCP אפשר להגיע ל-TCP meltdown. ניתן למנוע את זה ע״י הגדלת ה-timeout המינימלי ל-retransmission בתוך ה-tunnel, אבל אם משתמשים ב-UDP העניין פשוט לא קיים. אפילו OpenVPN ממליצים להשתמש ב-UDP.

OMRIJ
חבר ותיק
חבר ותיק
תגובות: 2660
הצטרף: מרץ 2007
נתן תודות: 40 פעמים
קיבל תודות: 349 פעמים

שליחה #43 

אני לא חושב שהוא המליץ לעבוד עם TCP
אבל זה שיש לך אפשרות במידת הצורך זה עדיין יתרון

Batnun
חבר מביא חבר
חבר מביא חבר
תגובות: 3626
הצטרף: מאי 2005
נתן תודות: 126 פעמים
קיבל תודות: 481 פעמים

שליחה #44 

אחלה שרשור!

הנקודה ש-sys_admin@ מנסה להדגיש (ובצדק), היא ששימוש ב-TCP פורט 443 יעיל מאוד כשאתה מנסה להתחבר ל-VPN מאחורי פיירוול...

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

אני אישית מעדיף WireGuard, ומשתמש לצורך זה בפורט UDP/443 כיוון שפורט זה אמור להיות פתוח לצורך תמיכה בפרוטוקול QUIC שהוא חלק מסנדרט HTTP3.
ליתר בטחון אני מפנה ל-WireGuard גם את פורטים UDP/53 ו-UDP/123 שגם להם יש סיכוי גבוה להיות מאופשרים. לגיבוי אני עדיין מחזיק שרת OpenVPN בפורט TCP/443...

האמת שעד לפני כמה ימים לא הייתי מודע ל-OpenVPN DCO וכמה הוא משפר את הביצועים. מעניין מאוד!


Batnun

.
Intel NUC 13 Extreme i9-13900K - 64GB - 2TB SSD
Nvidia 4090 FE - Samsung G95SC 49" OLED

DanielGR
סמל אישי של משתמש
גורו רשתות
גורו רשתות
תגובות: 1471
הצטרף: יולי 2023
שם מלא: DanielG
מיקום: Israel
נתן תודות: 225 פעמים
קיבל תודות: 282 פעמים

שליחה #45 

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

בסביבה מאובטחת לא מספיק לפתוח פורטים 80 ו-443 TCP, הפיירוול יבדוק גם שכל Packet היא חלק תקין מפרוטוקול Layer 7 קרי HTTP ו-HTTPS, כלומר הוולידציה היא לא רק ברמה של פורט. אם מדובר ב-WEB PROXY אז בכלל אין ניתוב IP לאינטרנט, וגלישה עובדת ברמה של דפים ולא פורטים.

OpenVPN יעבוד בכל מקרה גם דרך WEB PROXY, מה ש-WireGuard לא יכול לעשות.

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

הטיעון נכון, אבל... בסוף מדובר בסביבה מבוקרת (לאפשר חיבור מאובטח מרשת ציבורית למקום עבודה לדוגמא). ובסביבה מבוקרת ניתן לשלוט כיצד מאבטחים כל שרת ובאיזה רמה. פיתרון גישה מבוסס WireGuard לא פחות מאובטח מגישה מבוססת OPENVPN.
רשימת הציוד: MikroTik CCR2004-1G-12S+2XS |CRS317-1G-16S-RM | CRS504-4XQ-IN

Batnun
חבר מביא חבר
חבר מביא חבר
תגובות: 3626
הצטרף: מאי 2005
נתן תודות: 126 פעמים
קיבל תודות: 481 פעמים

שליחה #46 

03/02/2025 15:34  
DanielGR כתב:
לדייק במקצת את מה שנאמר:

בסביבה מאובטחת לא מספיק לפתוח פורטים 80 ו-443 TCP, הפיירוול יבדוק גם שכל Packet היא חלק תקין מפרוטוקול Layer 7 קרי HTTP ו-HTTPS, כלומר הוולידציה היא לא רק ברמה של פורט. אם מדובר ב-WEB PROXY אז בכלל אין ניתוב IP לאינטרנט, וגלישה עובדת ברמה של דפים ולא פורטים.
...

ליתר בטחון יש לי גם Apache Guacamole שרץ על שרת וירטואלי, ונותן לי גישה מאובטחת לרשת הפנימית על HTML5 8)


Batnun

.
Intel NUC 13 Extreme i9-13900K - 64GB - 2TB SSD
Nvidia 4090 FE - Samsung G95SC 49" OLED

שלח תגובה

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