איך פרצנו את חומת האש הגדולה של סין (חלק 2)

היי!

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

В החלק הקודם אמרתי:

• אילו בעיות מתעוררות לאחר קבלת ההחלטה "אנחנו צריכים לגרום לשירות שלנו לעבוד בסין"
• אילו בעיות יש לאינטרנט הסיני?
• למה אתה צריך רישיון ICP?
• איך ולמה החלטנו לבדוק את מיטות הבדיקה שלנו עם Catchpoint
• מה הייתה התוצאה של הפתרון הראשון שלנו המבוסס על Cloudflare China Network
• כיצד מצאנו באג ב- Cloudflare DNS

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

ענן אליבבה

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

IPSEC

התחלנו בגיאוגרפיה. מכיוון שאתר הבדיקה שלנו נמצא ב-Google Cloud, היינו צריכים "לקשר" את Alibaba Cloud ל-GCP, אז פתחנו רשימה של מיקומים שבהם גוגל נמצאת. באותו רגע עדיין לא היה להם מרכז נתונים משלהם בהונג קונג.
התברר שהאזור הקרוב ביותר אסיה-מזרח1 (טייוואן). עלי התברר כאזור הקרוב ביותר של סין היבשתית לטייוואן cn-שנז'ן (שנז'ן).

עם טרפה תיאר והעלה את כל התשתית ב-GCP ובעלי. מנהרה של 100 Mbit/s בין העננים עלתה כמעט מיד. בצד של שנזן וטייוואן, הועלו מכונות וירטואליות ל-proxy. בשנג'ן, תעבורת המשתמשים מופסקת, עוברת פרוקסי דרך מנהרה לטייוואן, ומשם היא עוברת ישירות ל-IP החיצוני של השירות שלנו. אותנו-מזרח (החוף המזרחי של ארה"ב). פינג בין מכונות וירטואליות דרך מנהרה 24ms, וזה לא כל כך נורא.

במקביל, מיקמנו אזור בדיקה Alibaba Cloud DNS. לאחר האצלת האזור ל-NS Ali, זמן הרזולוציה ירד מ-470 אלפיות השנייה ל- 50 ms. לפני כן, האזור היה גם ב-Cloudfare.

במקביל למנהרה ל אסיה-מזרח1 הרים מנהרה נוספת משנג'ן ישירות אל us-east4. שם הם יצרו יותר מכונות וירטואליות פרוקסי והחלו לבדוק את שני הפתרונות, ניתוב תעבורת בדיקה באמצעות Cookies או DNS. ספסל הבדיקה מתואר באופן סכמטי באיור הבא:

השהייה עבור מנהרות התבררה כדלקמן:
Ali cn-shenzhen <—> GCP asia-east1 — 24ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms

בדיקות דפדפן Catchpoint דיווחו על שיפור מצוין.

השוו את תוצאות הבדיקה עבור שני פתרונות:

החלטה
Uptime
חציון
75 אחוז
95 אחוז

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

מדובר בנתונים מפתרון שמשתמש במנהרת IPSEC דרך אסיה-מזרח1. דרך us-east4 התוצאות היו גרועות יותר, והיו יותר שגיאות, אז אני לא אתן את התוצאות.

בהתבסס על תוצאות בדיקה זו של שתי מנהרות, שאחת מהן מסתיימת באזור הקרוב ביותר לסין, והשנייה ביעד הסופי, התברר שחשוב "להגיח" מתחת לחומת האש הסינית במהירות האפשרית. אפשרי, ולאחר מכן השתמש ברשתות מהירות (ספקי CDN, ספקי ענן וכו'). אין צורך לנסות לעבור דרך חומת האש ולהגיע אל היעד במכה אחת. זו לא הדרך המהירה ביותר.

באופן כללי, התוצאות לא רעות, עם זאת, ל-semrush.com יש חציון של 8.8 שניות, ו-75 אחוז 9.4 שניות (באותה בדיקה).
ולפני שממשיכים הלאה, ברצוני לעשות סטייה לירית קצרה.

סטייה לירית

לאחר שהמשתמש נכנס לאתר www.semrushchina.cn, אשר פותר דרך שרתי DNS "מהירים" סיניים, בקשת ה-HTTP עוברת דרך הפתרון המהיר שלנו. התגובה מוחזרת באותו נתיב, אך הדומיין מצוין בכל סקריפטי JS, דפי HTML ורכיבים אחרים של דף האינטרנט semrush.com עבור משאבים נוספים שיש לטעון כאשר הדף מעובד. כלומר, הלקוח פותר את שיא ה-A "הראשי". www.semrushchina.cn ונכנס למנהרה המהירה, מקבל במהירות תגובה - דף HTML שאומר:

• הורד Js כאלה ואחרים מ-sso.semrush.com,
• קבל את קבצי ה-CSS מ-cdn.semrush.com,
• וגם לצלם כמה תמונות מ-dab.semrush.com
• וכן הלאה.

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

אבל הבדיקה הקודמת מציגה את התוצאות כאשר אין משאבים בדף semrush.comרק semrushchina.cn, ו-*.semrushchina.cn פותר לכתובת של המכונה הוירטואלית בשנג'ן כדי להיכנס למנהרה.

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

מסנן משנה

הפתרון נולד כמעט מיד לאחר שהבעיה הזו צצה. היינו צריכים PoC (Proof of Concept) שפתרונות החדירה של חומת האש שלנו באמת עובדים היטב. לשם כך, עליך לעטוף את כל תעבורת האתר בפתרון זה ככל האפשר. והגשנו בקשה מסנן משנה ב-nginx.

מסנן משנה הוא מודול פשוט למדי ב-nginx המאפשר לשנות שורה אחת בגוף התגובה לשורה אחרת. אז שינינו את כל ההתרחשויות semrush.com על semrushchina.cn בכל התשובות.

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

כתוצאה מכך, היכן יקבל הלקוח .semrush.com, הוא קיבל .semrushchina.cn ועבר בצייתנות את ההחלטה שלנו.

עם זאת, זה לא מספיק פשוט לשנות את הדומיין בכיוון אחד, מכיוון שה-backends עדיין מצפים ל-semrush.com בבקשות עוקבות מהלקוח. בהתאם לכך, באותו שרת שבו מתבצעת ההחלפה החד כיוונית, באמצעות ביטוי רגולרי פשוט אנו מקבלים את תת הדומיין מהבקשה, ואז אנו עושים proxy_pass עם משתנה $מארח, הוצג ב $subdomain.semrush.com. זה אולי נראה מבלבל, אבל זה עובד. וזה עובד טוב. עבור דומיינים בודדים הדורשים היגיון שונה, פשוט צור בלוקי שרת משלך ובצע תצורה נפרדת. להלן תצורות nginx מקוצרות לבהירות ולהדגמה של סכימה זו.

התצורה הבאה מעבדת את כל הבקשות מסין אל .semrushchina.cn:

    listen 80;

    server_name ~^(?<subdomain>[w-]+).semrushchina.cn$;

    sub_filter '.semrush.com' '.semrushchina.cn';
    sub_filter_last_modified on;
    sub_filter_once off;
    sub_filter_types *;

    gzip on;
    gzip_proxied any;
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;

    location / {
        proxy_pass http://127.0.0.1:8083;
        proxy_set_header Accept-Encoding "";
        proxy_set_header Host $subdomain.semrush.com;
        proxy_set_header X-Accept-Encoding $http_accept_encoding;
    }
}

תצורה זו משרתת פרוקסי ל localhost ליציאה 83, והתצורה הבאה ממתינה שם:

    listen 127.0.0.1:8083;

    server_name *.semrush.com;

    location / {
        resolver 8.8.8.8 ipv6=off;
        gunzip on;
        proxy_pass https://$host;
        proxy_set_header Accept-Encoding gzip;
    }
}

אני חוזר, אלו תצורות חתוכות.

כמו זה. זה אולי נראה מסובך, אבל זה במילים. למעשה, הכל פשוט יותר מלפת מאודה :)

סוף הסטייה

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

הם הרימו את זה. המנהרות התחילו להיכשל בזמנים שונים, אבל הכשל עבד מצוין עבורנו ברמה במעלה הזרם ב-nginx. אבל אז התחילו ליפול המנהרות בערך באותו זמן 🙂 ושוב התחילו 502 ו-504. זמן הפעילות התחיל להתדרדר, אז התחלנו לעבוד על האופציה עם עליבאבא CEN (רשת ענן ארגונית).

CEN

CEN - זוהי הקישוריות של שני VPCs מאזורים שונים בתוך Alibaba Cloud, כלומר, אתה יכול לחבר רשתות פרטיות של כל אזור בתוך הענן אחד עם השני. והכי חשוב: בערוץ הזה יש קפדנית למדי צד"ל. זה מאוד יציב הן במהירות והן בזמן פעולה. אבל זה אף פעם לא כל כך פשוט:

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

יש הזדמנות להתחבר בסין и חוּץ לָאָרֶץ, יצרנו CEN בין שני אזורי עלי: cn-שנז'ן и us-east-1 (הנקודה הקרובה ביותר לנו-מזרח4). באלי us-east-1 העלה עוד מכונה וירטואלית כך שתהיה עוד אחת לקפוץ.

זה יצא כך:

תוצאות בדיקת הדפדפן להלן:

החלטה
Uptime
חציון
75 אחוז
95 אחוז

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

הביצועים מעט טובים יותר מ-IPSEC. אבל דרך IPSEC אפשר להוריד בפוטנציה במהירות של 100 Mbit/s, ודרך CEN רק במהירות של 5 Mbit/s ויותר.

נשמע כמו היברידי, נכון? שלב מהירות IPSEC ויציבות CEN.

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

כובע

כובע - האם מאזן עומסים גלובלי (או Google Cloud Load Balancer). יש לזה יתרון חשוב עבורנו: בהקשר של CDN יש לו Anycast IP, המאפשרת לנתב תעבורה למרכז הנתונים הקרוב ללקוח, כך שהתנועה נכנסת במהירות לרשת המהירה של גוגל ופחות עוברת דרך האינטרנט ה"רגיל".

בלי לחשוב פעמיים, העלינו HTTP/HTTPS LB התקנו את המכונות הווירטואליות שלנו עם subfilter ב-GCP וכ-backend.

היו מספר תוכניות:

• להשתמש Cloudflare China Network, אבל הפעם Origin צריך לציין גלובלי IP GLB.
• סיום לקוחות ב cn-שנז'ן, ומשם פרוקסי את התעבורה ישירות אל כובע.
• לך ישר מסין ל כובע.
• סיום לקוחות ב cn-שנז'ן, משם פרוקסי ל אסיה-מזרח1 דרך IPSEC (in us-east4 דרך CEN), משם עבור ל-GLB (בנחת, תהיה תמונה והסבר למטה)

בדקנו את כל האפשרויות הללו ועוד כמה היברידיות:

• Cloudflare + GLB

סכימה זו לא התאימה לנו בגלל זמן פעולה ושגיאות DNS. אבל הבדיקה בוצעה לפני שהבאג תוקן בצד ה-CF, אולי זה עדיף עכשיו (עם זאת, זה לא שולל פסקי זמן של HTTP).

• עלי + GLB

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

• GLB בלבד

אפשרות דומה לקודמתה, רק שהיא לא השתמשה בשרתים בסין עצמה: התעבורה עברה ישירות ל-GLB (רשומות ה-DNS שונו). לפיכך, התוצאות לא היו משביעות רצון, מאחר שללקוחות סיניים רגילים המשתמשים בשירותים של ספקי אינטרנט רגילים יש מצב הרבה יותר גרוע עם מעבר חומת האש מאשר Ali Cloud.

• שנזן -> (CEN/IPSEC) -> פרוקסי -> GLB

כאן החלטנו להשתמש בפתרונות הטובים ביותר:

• יציבות ו-SLA מובטח מ-CEN
• מהירות גבוהה מ-IPSEC
• הרשת ה"מהירה" של גוגל וה-Anycast שלה.

הסכימה נראית בערך כך: תעבורת משתמשים מופסקת במחשב וירטואלי ב צ'-שנג'ן. שם מוגדרים זרמים של Nginx, שחלקם מצביעים על שרתי IP פרטיים הממוקמים בקצה השני של מנהרת ה-IPSEC, וחלק ממעלים מצביעים על כתובות פרטיות של שרתים בצד השני של ה-CEN. IPSEC מוגדר לאזור אסיה-מזרח1 ב-GCP (היה האזור הקרוב ביותר לסין בזמן יצירת הפתרון. ל-GCP יש כעת נוכחות גם בהונג קונג). CEN - לאזור us-east1 ב עלי קלאוד.

לאחר מכן הופנתה התנועה משני הקצוות anycast IP GLB, כלומר, לנקודת הנוכחות הקרובה ביותר של גוגל, ועברה דרך הרשתות שלה לאזור us-east4 ב-GCP, שבו היו מכונות וירטואליות חלופיות (עם subfilter ב-nginx).

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

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

תוצאות בדיקת דפדפן עבור הפתרון החדש בהשוואה לקודמים:

החלטה
Uptime
חציון
75 אחוז
95 אחוז

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

CEN/IPsec + GLB
99.79
13s
16s
25s

CDN

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

ואני אספר לכם על זה בחלק הבא, האחרון :)

מקור: www.habr.com