איך Reverse Proxy מעביר בקשות מתחת למכסה המנוע¶
כמעט כל אתר רציני היום לא חושף ישירות את שרתי האפליקציה שלו לאינטרנט. במקום זה, בקשות מגיעות קודם לרכיב שיושב בכניסה, בודק, ולפעמים משנה את הבקשה, ורק אז מעביר אותה הלאה לשרת האמיתי שמטפל בה בפועל. הרכיב הזה נקרא reverse proxy, וההבדל בינו לבין פרוקסי רגיל הוא בדיוק מי הוא מייצג.
ההבדל בין פרוקסי רגיל ל-Reverse Proxy¶
פרוקסי רגיל (forward proxy) עובד בשם הלקוח - הוא יושב בין המשתמש לאינטרנט, ומייצג את המשתמש כלפי חוץ, למשל VPN שמסתיר את כתובת ה-IP האמיתית שלכם מהאתרים שאתם גולשים בהם. reverse proxy עושה בדיוק ההפך - הוא יושב מול השרתים, ומייצג אותם כלפי הלקוחות. מבחינת הדפדפן שלכם, אתם מדברים עם אתר אחד, בכתובת אחת - אתם בכלל לא יודעים, ולא צריכים לדעת, שמאחורי הכתובת הזאת עומדים כמה שרתים שונים.
מה בדיוק Reverse Proxy עושה עם כל בקשה¶
כשבקשה מגיעה ל-reverse proxy, כמו nginx או HAProxy, הוא בודק אותה, ולפי כללים שהוגדרו מראש, מחליט מה לעשות איתה - אולי לנתב לפי הכתובת המבוקשת לשרת אחד או אחר (כל בקשה ל-/api הולכת לשרתי הבקאנד, כל בקשה לשאר הנתיבים הולכת לקבצים סטטיים), אולי לאזן עומס בין כמה עותקים של אותו שרת, ולפעמים גם להגיש תשובה בעצמו ישירות מקאש, בלי לגעת בכלל בשרת שמאחוריו.
הבקשה שמגיעה בסוף לשרת האמיתי כבר לא זהה במאה אחוז לבקשה המקורית - ה-reverse proxy בדרך כלל מוסיף כותרות משלו, החשובה שבהן X-Forwarded-For, שמכילה את כתובת ה-IP האמיתית של הלקוח המקורי. בלי הכותרת הזאת, השרת מאחורי ה-proxy היה רואה תמיד רק את כתובת ה-IP של ה-proxy עצמו כשולח הבקשה, ומאבד לגמרי מידע חשוב, למשל לצורכי לוגים או הגבלת קצב לפי משתמש.
טרמינציית TLS - למה זה נטל שכדאי להסיר מהשרתים¶
תפקיד נפוץ נוסף ל-reverse proxy הוא טרמינציית TLS - החיבור המוצפן, עם כל לחיצת היד שהסברנו בפוסט על TLS, מסתיים בפועל ב-proxy עצמו. מהרגע הזה, התעבורה בין ה-proxy לשרתי האפליקציה שמאחוריו יכולה לעבור בלי הצפנה נוספת, בדרך כלל ברשת פנימית מוגנת. זה מוריד מהשרתים עצמם את העומס החישובי של הצפנה ופענוח, ומרכז את ניהול תעודות ה-TLS במקום אחד, במקום לפזר את זה על כל שרת בנפרד.
שכבת הגנה נוספת, לא רק ניתוב¶
בגלל ש-reverse proxy הוא נקודת הכניסה היחידה מבחוץ, הוא גם מיקום טבעי להוסיף שכבות הגנה - חסימת בקשות חשודות, הגבלת קצב לפני שבקשה בכלל מגיעה לשרת האמיתי, והסתרה מוחלטת של המבנה הפנימי של המערכת. תוקף שסורק את הרשת שלכם מבחוץ רואה רק את ה-reverse proxy, ולא יודע כמה שרתים באמת עומדים מאחוריו, באילו גרסאות תוכנה הם רצים, או איך הם מאורגנים.
למה זה נראה כמו רכיב תשתית משעמם אבל הוא בסיסי¶
מפתחים שמפרסים אפליקציה בפעם הראשונה לפעמים מנסים לחשוף את שרת האפליקציה עצמו, כמו שרת פיתוח של פריימוורק כלשהו, ישירות לאינטרנט. זה עובד לזמן קצר, ונשבר ברגע שצריך לאזן עומס, לנהל תעודת TLS, או להוסיף שכבת הגנה - כל אחד מהם דורש בדיוק את הרכיב שכבר קיים מיועד לזה. הבנה של reverse proxy היא בדיוק מה שהופך "זה עובד על המחשב שלי" ל"זה עובד בייצור, בקנה מידה, בבטחה".
הבנה של רכיבי תשתית כאלה, לא רק כתיבת קוד אפליקציה, היא בדיוק מה שבונים בהדרגה בקורס הרשתות שלנו.
קורס הרשתות המלא נמצא כאן, חינם ובעברית, עם תרגול מעשי על תשתית רשת אמיתית.
יש לכם שאלה על הגדרת reverse proxy לפרויקט שלכם? שאלו בדיסקורד.
לסיכום¶
Reverse proxy יושב בין הלקוחות לשרתים, ומייצג את השרתים כלפי חוץ - הפוך מפרוקסי רגיל שמייצג את הלקוח. הוא מנתב בקשות, מאזין תעודת TLS במקום אחד, מוסיף כותרות כמו X-Forwarded-For כדי לא לאבד מידע על הלקוח המקורי, ומהווה שכבת הגנה נוספת שמסתירה את המבנה הפנימי של המערכת. זו הסיבה שכמעט כל מערכת בייצור עובדת מאחורי אחד.