המלצה לראוטר תומך 2 WAN עם LOAD BALANCING

Lyonia · שליחה 06/09/2020 13:13

eran405 כתב:
...
...
לבינתיים ER-X נותן לך גמישות מקסימלית כי יש לו 5 פורטים "רגילים" וסוויץ מובנה, אז בנוסף לשני WAN + חיבור אחד לסוויץ הראשי (שאם אני מבין נכון כבר יש כזה והוא יושב פיזית במקום אחר) יהיו לך עוד שני חיבורי רשת פנויים במקום הפיזי של ה-ER-X. כאמור ב-ER-4 אין את האפשרות הזאת גם בגלל מספר הפורטים "הרגילים" וגם בגלל שאין סווויץ מובנה.
...

·

וואלה

איזה רעיון מעניין למישהו שצריך 5 פורט סוויץ' דווקא של UBNT במחיר סביר (יחסי)
גם קטן גם יכול לקבל מתח מהפורט ז.א. אחלה פתרון לארון תקשורת קטן.

(דירה לא גדולה)

integral · שליחה 07/09/2020 10:50

@eran405
·
קיבלתי את עצתך. הזמנתי ER-X.

נראה איך יתפקד עם OFFLOADING. אם יהיה איטי אזמין את ה ER-4 ואהפוך אותו לסוויטש.

תודה רבה!

integral · שליחה 16/09/2020 0:54

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

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

הפעלתי גם ויזרד פשוט להגדרת QOS כדי למנוע BufferBloat

נראה איך יעבוד בעומס כבד ואז נחליט אם משדרגים ל ER-4 או לא.

liorp · שליחה 16/09/2020 1:33

הייתי ממליץ קודם כל לבדוק את תקינות הקו באמצעות טכנאי של הספק אינטרנט או התשתית.

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

integral · שליחה 16/09/2020 7:28

@liorp
·
ברור. היו פה מלא טכנאים, אבל הפרדתי לקו אינטרנטו בסוף.

ag43 · שליחה 16/09/2020 10:32

אני ממש לא מבין את התועלת בFAILOVER לאותה חברה עם אותה טכנולוגיה.

sys_admin · שליחה 16/09/2020 10:35

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

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

הפעלתי גם ויזרד פשוט להגדרת QOS כדי למנוע BufferBloat

נראה איך יעבוד בעומס כבד ואז נחליט אם משדרגים ל ER-4 או לא.
...

·

במצב זה שיצרת שני המודמים לא רק שעושים את החיוג, אלה שהם גם עושים NAT כל אחד בנפרד והנתב ששמת מאחוריהם נמצא מאחורי ה NATs של המודמים אלה, עם כל מה שנובע מכך גם מבחינת היציבות החיבור וגם מבחינת עבודה של פרוטוקולים שלא סובלים את DUAL NAT , שהיום עם הצורך של העבודה מרחוק זה דבר מהותי ביותר.
גם בכך הסדרה של ER המנגנון של https sticky sessions לא ממומש בצורה שהוא מתפקד ב כמודול IPTABLES של FIRMWARE שבציודים אלה ובגלל זה ברגע שמשתמשים ב MULTI WAN במכשירים אלה לא רק ל failover , אלה לצורך של load balancing מתחילים כבר להרגיש את הצרה זו.
והיום HTTPS זה לא רק עבודה מול אתרי אינטרנט בדפדפן, אלה שזה גם עבודה עם כל המערכות כמו דואר אלקטרוני, כמו SSL VPN, וכמו התקנים ניידים על בסיס של ANDROID ו IOS.

integral · שליחה 16/09/2020 12:25

@sys_admin

מה אתה מציע?
·

eran405 · שליחה 16/09/2020 13:25

@integral
·

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

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

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

ג. הטענה היחידה של sys_admin שאפשר להתייחס אליה בצורה עניינית זה הנושא של sticky sessions שכמובן בכלל לא רלוונטי במקרה של failover (כי אז אתה בין כה וכה משתמש בחיבור בודד ובמקרה שהוא נופל אין ברירה אלא להשתמש בחיבור השני; שם לב שגם sys_admin ציין זאת בהודעה שלו). במקרה של load balancing זה באמת דורש הגדרות נוספות כמו שמופרטת תחת sticky בהסברים של ubiquiti:
https://help.ui.com/hc/en-us/articles/2 ... -feature#4
בנוסף יש מלא מידע על זה באינטרנט, כולל בפורמים של ubiquiti, ב-reddit וכו'. אני לא נתקלתי בשום מידע על מגבלה בנושא הזה ל-edgerouters.

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

אם לא פשוט תלך על מה שעובד לך, ורק אם וכאשר תתקל בבעיה תשבור את הראש מה הדרך הכי פשוטה להתמודד או לעקוף אותה. בגבולות הטעם הטוב, הפתרון שעובד לך טוב במעשי הוא תמיד הפתרון הכי טוב.

integral · שליחה 16/09/2020 14:21

@eran405

מה שהיה קורה זה כשהייתי מנתק כבל לבדוק במצב ברידג', זה לא היה חוזר, או שהיה חוזר רק לאחת מיציאות הסוויטש ומשגע את הקליינטים. יכול להיות שבגלל שהויזרד בברירת המחדל לא נותן IP ל eth0+1 או בגלל שאין לי IP קבוע מהספקים או בגלל הגדרות DNS או בגלל שהויזרד קושר את ה eth ולא את ה PPPOE . אין לי מושג ומאמין שאפשר לפתור זאת עם הגדרות נכונות יותר. אבל, אני צריך גם לעבוד אז עברתי ל DOUBLE NAT.

בתצורה הנוכחית ה FAIL עובד מושלם. מנתק כבל או עושה DISABLE ל Eth ואין נפילה. זה גם עובד סבבה אחרי שהוספתי QOS פשוט למרות שמוריד קצת את הקצבים.

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

, אבל אם יש למישהו רעיון אשמח לשמוע

יש לי הרגשה שהוידיאו הזה יפתור את העניין, כשאוכל אראה אותו עד הסוף:

sys_admin · שליחה 16/09/2020 17:02

integral כתב:@sys_admin

מה אתה מציע?
·
...

·

מה שאני מציע זה דבר ראשון להעביר את הציוד קצה של הספק תשתית למצב של BRIDGE ודבר שני להשתמש במכשיר שתומך כמו שצריך ב LOAD BALANCING ורמז דק, כל הסדרה של ER היא לא תומכת בכך בצורה תקינה, בנוסף לשאר הצרות שיש בסבוניות אלה. בקשר לנושא של sticky sessions שלא ממומש בצורה תקינה בציוד זה כבר כתבתי ויש עוד מספר רב של בעיות מהותיות עם תוכנה של קו ציוד זה, שבמשך שנים הסברתי אותן בפורום זה.

הציוד שכן יכול להיות מתאים, לזה יכולות להיות מספר אפשרויות, מציוד ביתי הכי פשוט וזול שתומך ב OpenWRT , למשל אפילו C7 של TP-LINK ועד מערכת יותר גמישה עם ביצועים אחרים לגמרי, כמו pFsense או כמו OPNsense, שניתן להתקין אותן על כל פלטפורמה X64 , גם פיזית וגם וירטואלית. יש לי מערכות כאלה שפרוסות על פלטפורמות החל ממערכות משובצות סיניות ועד למכונות וירטואליות בתוך שרתי ESXI ו Hyper-V .

אם רוצים לנסות את OpenWRT, אז יש את ההסבר של מנגנון שלו:
https://openwrt.org/docs/guide-user/net ... iwan/mwan3

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

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

integral · שליחה 16/09/2020 17:54

@sys_admin
·
אני רואה את מה שאתה אומר, כי מהוידיאו שעברתי עליו בחופזה צריך לעשות כל מיני קומבינות כדי לעבוד כמו שצריך עם PPPOE כפול וזה חבל.

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

ag43 · שליחה 16/09/2020 19:27

ממליץ בחום על PFSENSE. יש לי שקט ב2 רשתות נפרדות עם מאות משתמשים מאז שהתקנתי אותה (X2).
הסתדרתי איתה בקלות (מלבד הFW שקצת עיצבן בהתחלה).
נתתי להן מכונה וירטואלית עם 2 מעבדי XEON ו8 גיגה זכרון בהתחלה. הנצילות שלהן היתה 5% במקסימום ובד"כ 1-2%. קלילה מאוד.

Lyonia · שליחה 16/09/2020 19:32

ag43 כתב:נתתי להן מכונה וירטואלית עם 2 מעבדי XEON ו8 גיגה זכרון בהתחלה. הנצילות שלהן היתה 5% במקסימום ובד"כ 1-2%. קלילה מאוד.
...

האם הכל זה רק לנתב??? אולי לא מספיק וצריך יותר כוח איבוד

·

eran405 · שליחה 16/09/2020 22:08

integral כתב: מה שהיה קורה זה כשהייתי מנתק כבל לבדוק במצב ברידג', זה לא היה חוזר, או שהיה חוזר רק לאחת מיציאות הסוויטש ומשגע את הקליינטים. יכול להיות שבגלל שהויזרד בברירת המחדל לא נותן IP ל eth0+1 או בגלל שאין לי IP קבוע מהספקים או בגלל הגדרות DNS או בגלל שהויזרד קושר את ה eth ולא את ה PPPOE . אין לי מושג ומאמין שאפשר לפתור זאת עם הגדרות נכונות יותר. אבל, אני צריך גם לעבוד אז עברתי ל DOUBLE NAT.
...

הרבה מילים אבל ללא פרטים טכניים רלוונטים ולכן קשה להבין מה בדיוק עשית ומה קורה שאתה מנתק את הכבל. חשוד לי החלק "הויזרד קושר את ה eth ולא את ה PPPOE", כי למיטב הבנתי אתה אמור להגדיר דרך ההויזרד את חיבורי ה-pppoe ולכן הוא כן אמור לקשור אותם, אחרת זה נשמע לי כמו bug. בלי לראות קונפיגורציה קשה להגיד. אם משום מה לא הגדרת את ה-pppoe דרך ה-wizard אלא רק אחר כך אולי שווה לנסות להפעיל את ה-wizard שוב ולהגדיר את ה-pppoe דרך ה-wizard.

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

א. מה-GUI לבחור backup/restore config, שעושה גיבוי יותר מלא הכולל את ה-config.boot וגם עוד קבצים, אבל זה מאד נדיר ורק לדברים מתקדמים שתעשה שינויים מחוץ ל-config.boot. בשביל להגיע לקובץ config.boot צריך לפתוח את ה-.tar.gz.

ב. דרך ה-CLI בעזרת "show configuration", אפשר להוסיף "cat |" בסוף השורה אם אתה רוצה את כל הפלט (לדוגמא בשביל לעשות copy paste לכל הקונפיגוצורה, או אפשר להשתמש ב-scp או ישירות על ה-config.boot או לשמור את הפלט של show configuration לקובץ זמני). ה-show configuration טוב בשביל לשתף את הקונפיגורציה בפורמים כי הוא כבר עושה sanitization לדברים הכי בסיסיים (סיסמאות וכו'; עדיין נדרש עוד מעבר לוודא שאין עוד לדברים לצנזר). בנוסף לי זה הפורמט הכי נח לשמור את הקונפיגורציות השונות שלי ולעשות diff גרפי בשביל להבין מה שיניתי ביניהן. שווה להזכיר גם את אופציית ה-"show configuration commands" שמוציאה פקודות שאפשר להדביק ב-CLI בשביל לשחזר את החלק הזה של הקונפיגורציה.

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

לגבי זה שה-failover לא עובד, יש לך שאלה מוגדרת היטב אז הכי טוב להצטרף לפורמים שלהם (שקישרתי קודם) ולשאול שם. מה שכן אין טעם לשאול כמו שאתה הצגת את השאלה כאן. צריך לשתף פרטים טכניים רלוונטים: לכל הפחות את הקונפיגורציה המלאה של הראוטר (אחרי sanitization כמובן) ופירוט טכני על מה קורה כשאתה מנתק את הכבל, כגון הפלט של "show load-balancing status" ו-"show ip route" וכו'. ככל שתשתף יותר פרטים רלוונטים גדל הסיכוי שירצו ויצליחו לעזור לך.

אם תשתף פה את הפרטים הטכניים כגון אלה שפירטתי לעיל, אנסה להעיף מבט ולהגיד אם משהו קופץ לי (כאמור אין לי ניסיון עם load balancing על edgerouter ולכן אני ממליץ יותר על הפורמים שלהם).

לבסוף, לגבי הנושא שה"הויזרד בברירת המחדל לא נותן IP ל eth0+1", זה לפחות משהו שיש לי ניסיון אישי איתו (לא ב-dual WAN אבל בחיבור הבודד כן). אם אני זוכר נכון זה תקין ומקובל בשביל חיבור pppoe שאינו דורש חיבור ברמת ה-IP אל המודם. עדיין אולי תרצה להגדיר IP בשביל שתוכל להגיע בנוחות לממשק ניהול של כל אחד מהמודמים, הקונפיגורציה לצורך כזה אמורה להיראות משהו כמו:

interfaces {
ethernet eth0 {
address 192.168.5.5/24
description "Internet (PPPoE)"
duplex auto
pppoe 0 {
...

service {
nat {
rule 5011 {
description Modem
destination {
address 192.168.5.0/24
}
log disable
outbound-interface eth0
protocol all
type masquerade
}

בהנחה שיש לך שני מודמים עם חיבור של pppoe, תצטרך לשכפל כל אחת מההגדרות בשביל eth0 ו-eth1 וכמובן להחליף את 192.168.5 ל-subnet המתאים של אותו המודם (עדיף שלכל מודם יהיה subnet משלו, על אף שאני די בטוח שאם עוד קצת קונפיגורציה אפשר גם לגרום לזה לעבוד אם לשני המודמים יש את אותו ה-subnet). כל זאת נדרש רק במידה שאתה מגדיר את המודם/ראוטרים במצב bridge, במצב של double NAT אתה אמור להיות מסוגל להכנס לממשק ניהול של המודם/ראוטרים ללא הגדרות מיוחדות (בהנחה שיש להם subnetים שונים, דבר שאתה חייב גם בשביל פעילות תקינה במקרה של double NAT).

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

integral · שליחה 17/09/2020 8:29

@eran405

תודה רבה!

נראה לי שבהזדמנות הראשונה אבדוק שוב את מצב ה PPPOE הכפול מאפס בתצורת BRIDGE.
·

integral · שליחה 17/09/2020 14:26

@eran405

ניסיתי שוב ושוב לא ממש עובד על PPP0E. מפעיל בעיקר אחד מהם. אולי זה עניין של MTU?

זו הקונפיגורציה:

[left]
ubnt@ubnt:~$ show configuration |cat
firewall {
all-ping enable
broadcast-ping disable
group {
network-group PRIVATE_NETS {
network 192.168.0.0/16
network 172.16.0.0/12
network 10.0.0.0/8
}
}
ipv6-receive-redirects disable
ipv6-src-route disable
ip-src-route disable
log-martians disable
modify balance {
rule 10 {
action modify
description "do NOT load balance lan to lan"
destination {
group {
network-group PRIVATE_NETS
}
}
modify {
table main
}
}
rule 20 {
action modify
description "do NOT load balance destination public address"
destination {
group {
address-group ADDRv4_pppoe0
}
}
modify {
table main
}
}
rule 30 {
action modify
description "do NOT load balance destination public address"
destination {
group {
address-group ADDRv4_pppoe1
}
}
modify {
table main
}
}
rule 70 {
action modify
modify {
lb-group G
}
}
}
name WAN_IN {
default-action drop
description "WAN to internal"
rule 10 {
action accept
description "Allow established/related"
state {
established enable
related enable
}
}
rule 20 {
action drop
description "Drop invalid state"
state {
invalid enable
}
}
}
name WAN_LOCAL {
default-action drop
description "WAN to router"
rule 10 {
action accept
description "Allow established/related"
state {
established enable
related enable
}
}
rule 20 {
action drop
description "Drop invalid state"
state {
invalid enable
}
}
}
options {
mss-clamp {
mss 1412
}
}
receive-redirects disable
send-redirects enable
source-validation disable
syn-cookies enable
}
interfaces {
ethernet eth0 {
description WAN
duplex auto
pppoe 0 {
default-route auto
firewall {
in {
name WAN_IN
}
local {
name WAN_LOCAL
}
}
mtu 1492
name-server auto
password ****************
user-id XXXXXXXXXXX
}
speed auto
}
ethernet eth1 {
description "WAN 2"
duplex auto
pppoe 1 {
default-route auto
firewall {
in {
name WAN_IN
}
local {
name WAN_LOCAL
}
}
mtu 1492
name-server auto
password ****************
user-id XXXXXXXXX
}
speed auto
}
ethernet eth2 {
duplex auto
speed auto
}
ethernet eth3 {
duplex auto
speed auto
}
ethernet eth4 {
duplex auto
speed auto
}
loopback lo {
}
switch switch0 {
address 192.168.1.1/24
description Local
firewall {
in {
modify balance
}
}
switch-port {
interface eth2 {
}
interface eth3 {
}
interface eth4 {
}
}
}
}
load-balance {
group G {
interface pppoe0 {
}
interface pppoe1 {
}
}
}
service {
dhcp-server {
disabled false
hostfile-update disable
shared-network-name LAN {
authoritative enable
subnet 192.168.1.0/24 {
default-router 192.168.1.1
dns-server 192.168.1.1
lease 86400
start 192.168.1.38 {
stop 192.168.1.243
}
}
}
}
dns {
forwarding {
cache-size 150
listen-on switch0
}
}
gui {
https-port 443
}
nat {
rule 5000 {
description "masquerade for WAN"
outbound-interface pppoe0
type masquerade
}
rule 5002 {
description "masquerade for WAN 2"
outbound-interface pppoe1
type masquerade
}
}
ssh {
port 22
protocol-version v2
}
}
system {
conntrack {
expect-table-size 4096
hash-size 4096
table-size 32768
tcp {
half-open-connections 512
loose enable
max-retrans 3
}
}
host-name ubnt
login {
user ubnt {
authentication {
encrypted-password ****************
}
level admin
}
}
ntp {
server 0.ubnt.pool.ntp.org {
}
server 1.ubnt.pool.ntp.org {
}
server 2.ubnt.pool.ntp.org {
}
server 3.ubnt.pool.ntp.org {
}
}
syslog {
global {
facility all {
level notice
}
facility protocols {
level debug
}
}
}
time-zone UTC
}
ubnt@ubnt:~$ H

[/left]

sys_admin · שליחה 17/09/2020 16:19

eran405 כתב:

...
...
לבסוף, לגבי הנושא שה"הויזרד בברירת המחדל לא נותן IP ל eth0+1", זה לפחות משהו שיש לי ניסיון אישי איתו (לא ב-dual WAN אבל בחיבור הבודד כן). אם אני זוכר נכון זה תקין ומקובל בשביל חיבור pppoe שאינו דורש חיבור ברמת ה-IP אל המודם. עדיין אולי תרצה להגדיר IP בשביל שתוכל להגיע בנוחות לממשק ניהול של כל אחד מהמודמים, הקונפיגורציה לצורך כזה אמורה להיראות משהו כמו:

interfaces {
ethernet eth0 {
address 192.168.5.5/24
description "Internet (PPPoE)"
duplex auto
pppoe 0 {
...

service {
nat {
rule 5011 {
description Modem
destination {
address 192.168.5.0/24
}
log disable
outbound-interface eth0
protocol all
type masquerade
}

·
...

·

אם הוא יעשה שבקונפיגורציה יראה "משהו כזה", כפי שרשמת אותה מעל, אז לא יהיה לו אפילו גישה לאינטרנט, וזה מסיבה פשוטה ביותר, שבתצורה זו הממשק חוץ שמופעל לצורך מנגנון NAT הוא ממשק רשת פיזי ( eth0 ) שאין עליו כתובת חיצונית של הספק והממשק שבכלל יכול לקבל את הכתבות של ספק במקרה של חיבור PPPoE , הוא מן הסתם ממשק pppoe 0, שכל מה שנשאר ממנו בקונפיגורצייה זו, זה רק שלוש נקודות.
זו הסיבה שהשירות NAT שבמקרה זה ממומש על ידי מנגנון masquerading של iptables צריך להיראות כך לשמל:

קוד: בחירת הכל

service &#123;

nat &#123;
 rule 5010 &#123;
 log disable
 outbound-interface pppoe0
 protocol all
 type masquerade
    &#125;
  &#125;

&#125;

eran405 · שליחה 17/09/2020 18:25

@sys_admin
·

זהו קוד בדוק שעבד לי בתצורה של edgerouter מחובר למודם בתשתית בזק עם חייגן pppoe, אז לכל הפחות החלק של "לא יהיה לו אפילו גישה לאינטרנט" לא נכון. חשוב להבין שזה החלק המינימלי שנדרש להוסיף בשביל לאפשר גישה לממשקי ניהול של המודמים ולכן החוק masquerade הוא בנוסף לחוק masquerade הרגיל שמופיע כרגיל תחת rule 5010 וכנראה נראה בדיוק כמו שהבאת בדוגמא שלך (אכן כוונתי הייתה שיבינו מהשלוש נקודות שכל זאת בנוסף לכל הקונפיגורציה הרגילה). שם לב שהחוק החדש מוסיף את 5011 rule (חשוב לבחור מספר פנוי ולא לדרוס חוק קיים) והוא תופס רק לגבי התקשורת ל-subnet הרלוונטי. בנוסף ערכתי את ההודעה הקודמת והוספתי שכדאי גם להוסיף חוקי firewall בשביל הממשקי "הניהול" האילו ולחסום תקשורת נכנסת.

eran405 · שליחה 17/09/2020 19:31

@integral
·

א. רחמים, בבקשה תשתמש בבלוק Code כאשר אתה מדביק דברים כאלה כאן בפורמים (מופיע בעורך הרגיל), או אפילו יותר טוב בשביל פלט כזה ארוך, תקשר לאתר חיצוני כגון:
https://pastebin.com/2yuPr5wj

ב. אני לא רואה שום דבר שזועק לי בקונפיגורציה לעיל, ההגדרות של ה-load balancing נראות אחד לאחד בדיוק מה שמוסבר בהסבר שלהם (כאשר כמובן ממשקי ה-pppoe משוייכים ל-load balancing ולא הממשקים הפיזים):
https://help.ui.com/hc/en-us/articles/2 ... alancing#3

ג. משהו שכן שונה ממה שדיברת קודם, אתה עושה balancing מלא בין הממשקים ולא רק failover. בשביל failover בלבד אתה צריך להוסיף:

קוד: בחירת הכל

set load-balance group G interface pppoe1 failover-only

(במקרה הזה ישתמשו ב-pppoe1 רק כאשר pppoe0 יפול)
למיטב הבנתי, הקטע של failover עובד גם במקרה של balancing מלא אבל אז כדאי להגדיר הגדרות נוספות בשביל המקרה התקין שהוא מאזן בין החיבורים כגון ה-Sticky כפי שמוסבר בלינק לעיל.

ד. ספציפית לגבי ה-MTU זה נראה בדיוק כמו ההגדרות שעבדו לי בזמנו מעל תשתית בזק וחייגן pppoe. עדיין כדאי לבדוק את הנושא לדוגמא כמו שמוסבר כאן:
https://kb.netgear.com/19863/Ping-Test- ... -on-Router
אין קשר ישיר ל-load balancing חוץ מאשר זה שליתר ביטחון הייתי בודק את ה-MTU מעל כל חיבור בנפרד. דרך אגב אני לא בטוח למה מוגדר mss clamping של 1412. אני מנחש שזה הברירת מחדל שלו, כי זה גם מה שאני רואה שהוגדר בקונפיגורציה שלי בזמנו. עכשיו שאני מסתכל על זה אני מנחש שאפשר להעלות את זה ל-1452 כמו שמוסבר פה:
https://community.ui.com/questions/Mss- ... 8eef8fe2d0

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

תסביר בדיוק איזה בעיה/בעיות יש כולל פרטים טכניים שיכולים להעיד איפה הבעיה (לדוגמא מתי בדיקת פינג ל-8.8.8.8 עובדת ומתי היא לא? האם יש גם חוסר יציבות או תופעות כאלה; יתכן שאפשר להשתמש בטרייס לראות את הניתוב לחיבורים השונים וכו'). האם יש שורות רלוונטיות ב-log שלו, הכי טוב להפעיל "show log tail" מה-CLI ולהשאיר פועל ואז לנתק את הכבל ולעקוב האם מופיעות הודעות חדשות בחלון של ה-CLI.

בנוסף כמו שביקשתי קודם לפחות תבדוק ותשתף את הפלט של הפקודות שמופיעות תחת troubleshooting בהסבר שלהם:
https://help.ui.com/hc/en-us/articles/2 ... alancing#5
האם יש הבדל בין המקרה התקין כשהכבל מחובר לכאשר אתר מנתק את הכבל? האם הוא מצליח להבין שהחיבור נפל? אולי לוקח לו קצת זמן, האם יש שינוי בפלט של הפקודות הנ"ל לדוגמא 2 דקות אחרי שניתקת את החיבור? שם לב שבלינק לעיל מפורט גם לגבי אופציית ה-Route Test שיתקן שנדרשת בשביל שה-edgerouter יבין שהממשק נפל (כאמור אין לי ניסיון עם load balancing אז אני לא יכול להגיד דברים בוודאות).