חסימת GeoIP ב-nginx וב-Cloudflare: מדריך DevOps

חסימת GeoIP: היכן נשברת לוגיקת הגישה

חסימת GeoIP נראית כמו כלל פשוט: משווים את כתובת הלקוח לטווח מתוך מאגר האזורים ומחזירים סירוב. בפועל זה אחד המקומות השבירים ביותר במעגל הגישה — התקלה לא מתגלה מיד ולא במקום שבו מחפשים אותה.

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

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

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

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

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

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

מה נותן ניהול גישה לפי אזורים

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

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

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

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

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

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

השוואת גישות: nginx, Cloudflare, מאזן עומסים

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

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

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

סדר ההטמעה: מהביקורת ועד המסירה

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

1. ביקורת כללי גישה ומיפוי תעבורה. אוספים תמונה אמיתית: שיעורי בקשות לפי מדינות, מקורות בוטים, הגבלות קיימות בפרימטר ובאפליקציה. כאן גם רואים את מי המסנן יפגע ראשון.
2. סכימת סינון. קובעים את נקודת קבלת ההחלטה — קצה הרשת או שרת האינטרנט עצמו — מקור הנתונים הגיאוגרפיים והתנהגות כשהמאגר מיושן: להעביר הלאה או לדחות. בנפרד מגדירים מה עושים עם רובוטים של מנועי חיפוש והתראות משער תשלומים.
3. הגדרת מקורות הנתונים הגיאוגרפיים. מחברים מאגר כתובות מתעדכן, קובעים עדכון קבוע ובקרת אי-סנכרון בין הפרימטר לשרת, כדי שהכללים לא יתפצלו.
4. מצב רך. המסנן רק כותב ללוג ולא מחזיר סירוב. מחזיקים אותו כמה שצריך כדי לוודא: אף תרחיש לגיטימי לא נכנס להפעלות.
5. בדיקה במתאר בדיקות. מריצים בקשות טיפוסיות וגבוליות מאזורים שונים, משווים קודי תגובה וכותרות, ובודקים מראש rollback לכללים הקודמים.
6. הפעלה ומסירה עם נוהל. עוברים למצב עבודה בהדרגה, מוסרים את הסכימה, סדר עדכון המאגרים ונוהל תחזוקה: מי ואיך מוסיף חריגים, כמה מהר מבצעים rollback ואיפה רואים לוגים.

מה מועבר לידיים: קונפיגורציות ונהלים

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

• קבצי כללים — קונפיגורציות GeoIP ב-nginx ומערכי ביטויים ב-Cloudflare, מרוכזים במאגר קוד עם היסטוריית שינויים, ולא מפוזרים בין פאנלים אישיים.
• מפת סכימת מעבר הבקשה: באיזה צומת מתקבלת החלטת החסימה, אילו כותרות מגיעות לאפליקציה והיכן מוחלפת הכתובת האמיתית של הלקוח.
• מקורות הנתונים הגיאוגרפיים ולוח הזמנים לעדכונם: איזה מאגר משמש, באיזו תדירות נמשך ומה קורה כשלא ניתן להגיע למקור.
• תיעוד הרשאות: תפקידים, תחומי אחריות, היכן נשמרים מפתחות, איך מסובבים אותם ומי מאשר את ההנפקה.
• מדיניות חריגים: רשימות לבנות לרובוטים של מנועי חיפוש, ניטור, callbacks של תשלומים ושירותים פנימיים — עם סדר הוספה ואישור.
• סדר rollback לשינויים: איזו עריכה מוסרת בפקודה אחת, כמה זמן לוקח היישום ולפי אילו מדדים רואים שהחסימה באמת הוסרה.
• נוהל עדכון כללים: בדיקה במתאר בדיקות, חלון יישום, מי מאשר חסימות שנויות במחלוקת ואיך מתעדים את ההחלטה.
• אנשי קשר אחראיים משני הצדדים ונקודת אסקלציה למקרה שכלל פגע בלקוחות אמיתיים.

לפני המסירה מריצים תרחיש לפי המסמכים האלה שלב אחר שלב: להוסיף חריג, לבצע rollback לשינוי, לעדכן מאגר. אם שלב כלשהו צריך להסביר מהזיכרון — משלימים את המסמך, ולא משאירים אותו כמו שהוא.

מקרה בוחן: התראות שווא ועומס על הפרימטר

מה היה לפני השינויים

חנות אינטרנטית עם תעבורה מכמה אזורים החזיקה סינון גיאוגרפי ממש על הפרימטר: כללים ב-nginx ורשימות מדינות בצד Cloudflare. טווחי הכתובות השתנו, והכללים עודכנו ידנית — מהנדס תורן ערך קונפיגים והפעיל מחדש את השירות. התראות שווא הגיעו ל-6–8% מניסיונות הכניסה, התמיכה טיפלה בכ-40 פניות בשבוע.

תופעת לוואי — שגרה: 2–3 שעות ביום הלכו על השוואת רשימות עם לוגים, ורשומה שגויה אחת השביתה אזור שלם.

מה שינו

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

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

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

במה חסימת GeoIP ב-nginx שונה מ-Cloudflare

בשני המקרים פועלת אותה לוגיקה «אזור לפי מאגר — כלל — סירוב», אבל נקודת קבלת ההחלטה שונה. חסימת GeoIP על השרת חיה בקונפיגורציה של nginx: הבקשה מגיעה למכונה, הכתובת נבדקת מול מאגר המיקום הגיאוגרפי, ורק אז הבקשה או עוברת לאפליקציה או מקבלת סירוב. בצד CDN הבדיקה מתרחשת בצומת של הספק — לפני שהתעבורה בכלל נכנסת למתאר שלך.

מכאן הפער המרכזי — זיהוי האזור של הלקוח מאחורי פרוקסי. אם לפני השרת עומד מאזן עומסים או CDN, ה-socket מחזיר את כתובת צומת הביניים, לא את זו של המבקר.

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

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

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

גם בהשהיה ובעומס ההבדל מורגש. סינון מקומי לא מאיץ את התגובה: הבקשה עדיין תופסת חיבור ועיבוד בשרת, אבל נותנת שליטה מלאה בכללים, בלוגיקת החריגים ובלוגי הסירובים. סינון בצד CDN חותך את התעבורה מוקדם יותר — מוריד עומס מהערוץ ומהאפליקציה, אבל פחות גמיש.

בפועל משלבים בין הגישות: CDN משמש כמסנן ראשוני גס, ו-nginx — כשכבה שנייה ונקודה לכללים לא סטנדרטיים.

ספקות טכניים נפוצים לפני ההתחלה

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

החסימה לא תפגע בלקוחות אמיתיים?

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

עד כמה נתוני המיקום הגיאוגרפי מעודכנים?

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

שותפים ושירותים בחו"ל לא ייפלו?

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

איך בודקים כלל לפני הפעלה?

קודם מצב תצפית: בקשות נרשמות בלוג אבל לא נחתכות. בלוגים רואים את הנפח, המדינות והתרחישים שנפגעו. חסימה מלאה מפעילים אחרונה, עם תוכנית rollback.

נדון במשימה ונחזור עם תוכנית הטמעה

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

• סכימת מעבר התעבורה: היכן בדיוק מסתיים החיבור, אילו צמתים עומדים לפני האפליקציה, האם יש חוליות ביניים ומאזני עומסים.
• רשימת שירותים ואזורים: אילו דומיינים ואפליקציות נכנסים תחת ההגבלה, ומאילו מדינות פותחים אותם משתמשים לגיטימיים.
• כללים קיימים: רשימות גיאו קיימות, רשתות סטטיות, כללים בשרת האינטרנט ובצד רשת ההפצה, סדר ההחלה שלהם.
• דרישות לחריגים: את מי אסור לחסום — רובוטים של מנועי חיפוש, מערכות ניטור, כתובות תשלומים ושותפים, יציאות ארגוניות של עובדים.
• דרישות להרשאות: אילו תפקידים נדרשים בפאנל הניהול ובשרתים, מי מאשר שינויים ומתאם חלון עבודה.
• מצב הפעלה: קודם תצפית בלי חסימה עם איסוף סטטיסטיקה, אחר כך הפעלה ממוקדת לפי אזורים, ואז החלה מלאה עם rollback בעריכה אחת.
• קריטריוני קבלה: אילו מדדים נחשבים להצלחה, איזה שיעור התראות שווא אנחנו מתירים ובאיזה פרק זמן מגיעים לערכי היעד.

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