TCP PORT FORWARD
- פותח הנושא xcalibur
- פורסם בתאריך
Testosterone
New member
Apache on CentOS?
Testosterone
New member
חץ צודק. כבר התחלת עם NGINX
ואתה די קרוב לסיום, אז תמשיך איתו.
ואתה די קרוב לסיום, אז תמשיך איתו.
iptables ?
no need to install / setup any stuff just use the build in iptables (send all trafice from port 443 to 2.2.2.2:443)
sysctl net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 2.2.2.2:443
iptables -t nat -A POSTROUTING -j MASQUERADE
no need to install / setup any stuff just use the build in iptables (send all trafice from port 443 to 2.2.2.2:443)
sysctl net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 2.2.2.2:443
iptables -t nat -A POSTROUTING -j MASQUERADE
אם כבר, וסתם לידע כללי
אז דע גם שעוד משהו שאפשר לעשות בדוגמא היפה ש - mavor ציין בפניך, זה לציין מס' to-destination-- (אחד אחרי השני, עם רווחים). אם בוחרים להשתמש ביכולות זו למטרת "load-balancing", יש עדיין הרבה עבודה לעשות מאחורי הקלעים, לדוגמא: למרות שיכול להיות שאחד מהשרתים שמוזכרים בחוק למטה, Iptables עדיין ינסה להעביר אליו את ה - packet. כמו שבטח הבנת, חוץ מלנסות ו"להתחכם" על-מנת לפתור זאת (משהו שהוא תמיד כיף
), יש כלים שנולדו לעשות דברים כאלה.
load-balancing - נושא מאד מרתק לטעמי.
בהצלחה רבה!
+דניאל.
אז דע גם שעוד משהו שאפשר לעשות בדוגמא היפה ש - mavor ציין בפניך, זה לציין מס' to-destination-- (אחד אחרי השני, עם רווחים). אם בוחרים להשתמש ביכולות זו למטרת "load-balancing", יש עדיין הרבה עבודה לעשות מאחורי הקלעים, לדוגמא: למרות שיכול להיות שאחד מהשרתים שמוזכרים בחוק למטה, Iptables עדיין ינסה להעביר אליו את ה - packet. כמו שבטח הבנת, חוץ מלנסות ו"להתחכם" על-מנת לפתור זאת (משהו שהוא תמיד כיף
load-balancing - נושא מאד מרתק לטעמי.
בהצלחה רבה!
+דניאל.
הנה, מ - man iptables של CentOS 6.2
ֻ
DNAT
This target is only valid in the nat table, in the PREROUTING and OUTPUT chains, and user-defined chains which are only
called from those chains. It specifies that the destination address of the packet should be modified (and all future pack-
ets in this connection will also be mangled), and rules should cease being examined. It takes one type of option:
--to-destination [ipaddr][-ipaddr][
ort[-port]]
which can specify a single new destination IP address, an inclusive range of IP addresses, and optionally, a port
range (which is only valid if the rule also specifies -p tcp or -p udp). If no port range is specified, then the
destination port will never be modified. If no IP address is specified then only the destination port will be modi-
fied.
In Kernels up to 2.6.10 you can add several --to-destination options. For those kernels, if you specify more than one
destination address, either via an address range or multiple --to-destination options, a simple round-robin (one
after another in cycle) load balancing takes place between these addresses. Later Kernels (>= 2.6.11-rc1) don’t have
the ability to NAT to multiple ranges anymore.
ֻ
DNAT
This target is only valid in the nat table, in the PREROUTING and OUTPUT chains, and user-defined chains which are only
called from those chains. It specifies that the destination address of the packet should be modified (and all future pack-
ets in this connection will also be mangled), and rules should cease being examined. It takes one type of option:
--to-destination [ipaddr][-ipaddr][
ort[-port]]which can specify a single new destination IP address, an inclusive range of IP addresses, and optionally, a port
range (which is only valid if the rule also specifies -p tcp or -p udp). If no port range is specified, then the
destination port will never be modified. If no IP address is specified then only the destination port will be modi-
fied.
In Kernels up to 2.6.10 you can add several --to-destination options. For those kernels, if you specify more than one
destination address, either via an address range or multiple --to-destination options, a simple round-robin (one
after another in cycle) load balancing takes place between these addresses. Later Kernels (>= 2.6.11-rc1) don’t have
the ability to NAT to multiple ranges anymore.
דלית - delete
New member
load balancing בקרנל
בדקת באמצעות ipvs עם keepalived?
או עם TCPHA?
http://www.linuxvirtualserver.org/software/ipvs.html
http://www.keepalived.org/
http://dragon.linux-vs.org/~dragonfly/htm/tcpha.htm
לכאורה גם keepalived וגם tcpha מאפשרים loadbalancing חכם שמזהה מכונות שנפלו.
לא ניסיתי מעולם, אין לי מושג אם בכלל מתאים לדרישות.
בדקת באמצעות ipvs עם keepalived?
או עם TCPHA?
http://www.linuxvirtualserver.org/software/ipvs.html
http://www.keepalived.org/
http://dragon.linux-vs.org/~dragonfly/htm/tcpha.htm
לכאורה גם keepalived וגם tcpha מאפשרים loadbalancing חכם שמזהה מכונות שנפלו.
לא ניסיתי מעולם, אין לי מושג אם בכלל מתאים לדרישות.
דלית - delete
New member
והתובנות?
שאלתי את פותח השרשור, אבל אם יש נסיון אישי - איך הכלים הללו לעומת פתרון מבוסס IPTABLES או מכונות פרוקסי ייעודיות כמו nginx או squid?
לא באופן כללי, אלא ספציפית לדרישות שהועלו כאן.
שאלתי את פותח השרשור, אבל אם יש נסיון אישי - איך הכלים הללו לעומת פתרון מבוסס IPTABLES או מכונות פרוקסי ייעודיות כמו nginx או squid?
לא באופן כללי, אלא ספציפית לדרישות שהועלו כאן.
באופן כללי: הכלים שהועלו בשרשור
לא תמיד מחליפים אחד את השני, אלא לעיתים גם עובדים אחד עם השני. לדוגמא, תחשוב על התסריט הבא (שווה ציור האמת
): LB כלשהוא, שמורכב (למשל) משני שרתים, אחד Active ואחד Passive שבכל רגע נתון מבתצעת בדיקה של "האם ה - Active נפל" ואם כן, ה - Passive יכנס לפעולה. ה - LB הזה "מחזיק" מה שנקרא VIP או בשם המלא Virtual IP, דהיינו כתובת IP צפה (אותה כתובת שתעבור בין שרת אחד לשני בשעת הצורך). ה - LB המדובר מקבל את בקשות הלקוח ומעביר אותו, למשל, ל - Nginx שמשרת כ - Reverse Proxy. ל - Nginx הזה מוגדר Backend של מס' שרתי Apache (לדוגמא) שבשעה טובה ובתאכלס, שולחים את החומר חזרה ללקוח
זו הייתה דוגמא אחת מיני רבות. יש הרבה שאלות שצריכות להישאל בבנייה של מערכת מורכבת, ואין ספק זה מצד אחד מעניין אך מצד שני מורכב. עוד סוגיה למחשבה היא נושא ה - SSL. עבודת SSL יכולה להוות "את החוליה החלשה" בדרך אל-היעד, כולל זמן CPU גדול, ושיקול חשוב הוא "היכן" תבוצע פעילות ה - SSL. ב - LB? ב - Reverse Proxy? בחברי ה - Backend בעצמם? גם שאלה זו יכולה להשפיע בחירה בכלי הנכון. LB שונים עובדים בשכבות שונות של מודול שבע השכבות. בקיצור - עולם יפה ומאתגר.
לגבי בקשתו של פותח השרשור: אני מניח ששימוש ב - Nginx כפי שתאר די מתאים לו. במיוחד אם ירצה להתרחב למס' שרתים נוספים ב - Backend.
שיהיה לנו אחלה של שבוע ויום עצמאות שמח!
+דניאל.
לא תמיד מחליפים אחד את השני, אלא לעיתים גם עובדים אחד עם השני. לדוגמא, תחשוב על התסריט הבא (שווה ציור האמת
זו הייתה דוגמא אחת מיני רבות. יש הרבה שאלות שצריכות להישאל בבנייה של מערכת מורכבת, ואין ספק זה מצד אחד מעניין אך מצד שני מורכב. עוד סוגיה למחשבה היא נושא ה - SSL. עבודת SSL יכולה להוות "את החוליה החלשה" בדרך אל-היעד, כולל זמן CPU גדול, ושיקול חשוב הוא "היכן" תבוצע פעילות ה - SSL. ב - LB? ב - Reverse Proxy? בחברי ה - Backend בעצמם? גם שאלה זו יכולה להשפיע בחירה בכלי הנכון. LB שונים עובדים בשכבות שונות של מודול שבע השכבות. בקיצור - עולם יפה ומאתגר.
לגבי בקשתו של פותח השרשור: אני מניח ששימוש ב - Nginx כפי שתאר די מתאים לו. במיוחד אם ירצה להתרחב למס' שרתים נוספים ב - Backend.
שיהיה לנו אחלה של שבוע ויום עצמאות שמח!
+דניאל.
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.