Büyük Çin Güvenlik Duvarını nasıl aştık (Bölüm 2)

Merhaba!

Şirketin sistem mühendisi Nikita yeniden sizlerle SEMrush. Bu makaleyle birlikte nasıl geçici bir çözüm bulduğumuzun hikayesine devam ediyorum. Çin Güvenlik Duvarı hizmetimiz için semrush.com.

В önceki bölüm Söyledim:

• “Hizmetimizi Çin’de çalışır hale getirmeliyiz” kararı alındıktan sonra ne gibi sorunlar ortaya çıkıyor?
• Çin İnternetinin ne gibi sorunları var?
• neden bir ICP lisansına ihtiyacınız var?
• Catchpoint ile test ortamlarımızı nasıl ve neden test etmeye karar verdik?
• Cloudflare Çin Ağını temel alan ilk çözümümüzün sonucu neydi?
• Cloudflare DNS'de nasıl bir hata bulduk?

Bana göre bu kısım en ilginç olanıdır çünkü sahnelemenin spesifik teknik uygulamalarına odaklanmaktadır. Ve başlayacağız, daha doğrusu devam edeceğiz Alibaba Bulutu.

Alibaba Bulutu

Alibaba Bulutu oldukça büyük bir bulut sağlayıcısıdır ve kendisini dürüstçe bir bulut sağlayıcısı olarak adlandırmasına olanak tanıyan tüm hizmetlere sahiptir. Yabancı kullanıcılar için kayıt olma imkanına sahip olmaları ve sitenin çoğunun İngilizceye çevrilmiş olması iyi bir şey (Çin için bu bir lüks). Bu bulutta, Çin anakarasının yanı sıra Okyanus Asya'sı (Hong Kong, Tayvan vb.) gibi dünyanın birçok bölgesiyle çalışabilirsiniz.

IPSEC

Coğrafyayla başladık. Test sitemiz Google Cloud'da bulunduğundan Alibaba Cloud'u GCP'ye "bağlamamız" gerekiyordu, bu nedenle Google'ın bulunduğu konumların bir listesini açtık. O zamanlar Hong Kong'da henüz kendi veri merkezleri yoktu.
En yakın bölge ortaya çıktı asya-doğu1 (Tayvan). Ali, Çin anakarasının Tayvan'a en yakın bölgesi olduğu ortaya çıktı Cn-Shenzhen (Shenzhen).

Ile terraform GCP ve Ali'deki tüm altyapıyı tanımladı ve geliştirdi. Bulutların arasındaki 100 Mbit/s'lik bir tünel neredeyse anında açıldı. Shenzhen ve Tayvan tarafında proxy sanal makineleri geliştirildi. Shenzhen'de kullanıcı trafiği sonlandırılır, bir tünel üzerinden Tayvan'a proxy ile aktarılır ve oradan doğrudan hizmetimizin harici IP'sine gider. ABD-doğu (ABD Doğu Yakası). Tünel aracılığıyla sanal makineler arasında ping işlemi yapma 24mski bu o kadar da kötü değil.

Aynı zamanda bir test alanı yerleştirdik. Alibaba Bulut DNS. Bölge NS Ali'ye devredildikten sonra çözüm süresi 470 ms'den XNUMX ms'ye düştü. 50 ms. Bundan önce bölge de Cloudlfare'deydi.

Tünele paralel asya-doğu1 Shenzhen'den doğrudan başka bir tünel kaldırdı us-doğu4. Orada daha fazla proxy sanal makinesi oluşturdular ve her iki çözümü de test etmeye başladılar; test trafiğini Çerezler veya DNS kullanarak yönlendirdiler. Test tezgahı aşağıdaki şekilde şematik olarak açıklanmaktadır:

Tünellerdeki gecikmenin şu şekilde olduğu ortaya çıktı:
Ali cn-shenzhen <—> GCP asya-doğu1 — 24ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms

Catchpoint tarayıcı testleri mükemmel bir iyileşme bildirdi.

İki çözüm için test sonuçlarını karşılaştırın:

karar
Çalışma Zamanı
Medyan
75 Yüzdelik
95 Yüzdelik

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

Bu, IPSEC tüneli kullanan bir çözümden gelen verilerdir. asya-doğu1. Us-east4 sayesinde sonuçlar daha kötüydü ve daha fazla hata vardı, bu yüzden sonuçları vermeyeceğim.

Biri Çin'e en yakın bölgede, diğeri ise nihai varış noktasında sonlandırılan iki tünel üzerinde yapılan bu testin sonuçlarına göre, Çin güvenlik duvarının altından mümkün olan en kısa sürede "çıkmanın" önemli olduğu ortaya çıktı. mümkün ve ardından hızlı ağları (CDN sağlayıcıları, bulut sağlayıcıları vb.) kullanın. Güvenlik duvarını aşıp tek hamlede hedefinize ulaşmaya çalışmanıza gerek yok. Bu en hızlı yol değil.

Genel olarak sonuçlar fena değil ancak semrush.com'un ortalama değeri 8.8 ve 75 Yüzde 9.4'tür (aynı testte).
Devam etmeden önce kısa bir lirik inceleme yapmak istiyorum.

Lirik geri çekilme

Kullanıcı siteye girdikten sonra www.semrushchina.cn"Hızlı" Çin DNS sunucuları aracılığıyla çözümlenen HTTP isteği, hızlı çözümümüz üzerinden geçer. Yanıt aynı yol üzerinden döndürülür ancak etki alanı tüm JS komut dosyalarında, HTML sayfalarında ve web sayfasının diğer öğelerinde belirtilir. semrush.com sayfa oluşturulduğunda yüklenmesi gereken ek kaynaklar için. Yani müşteri “ana” A kaydını çözer www.semrushchina.cn ve hızlı tünele girer, hızlı bir şekilde bir yanıt alır - şunu belirten bir HTML sayfası:

• sso.semrush.com'dan falan filan js'leri indirin,
• CSS dosyalarını cdn.semrush.com adresinden alın,
• ve ayrıca dab.semrush.com'dan birkaç fotoğraf çekin
• ve benzerleri.

Tarayıcı, her seferinde yanıt süresini tüketen bir güvenlik duvarından geçerek bu kaynaklar için "harici" İnternet'e gitmeye başlar.

Ancak önceki test, sayfada kaynak olmadığında sonuçları gösteriyor semrush.comsadece semrushchina.cnve *.semrushchina.cn, tünele girebilmek için Shenzhen'deki sanal makinenin adresine çözümlenir.

Ancak bu şekilde, Çin güvenlik duvarını hızlı bir şekilde geçmek için çözümünüz üzerinden mümkün olan tüm trafiği maksimuma çıkararak kabul edilebilir hızlar ve web sitesi kullanılabilirlik göstergelerinin yanı sıra çözüm testlerinin dürüst sonuçlarını elde edebilirsiniz.
Bunu ekibin ürün tarafında tek bir kod düzenlemesi yapmadan yaptık.

Alt filtre

Çözüm, bu sorun ortaya çıktıktan hemen sonra doğdu. İhtiyacımız vardı PoC (Kavram Kanıtı) güvenlik duvarı sızma çözümlerimizin gerçekten iyi çalıştığını gösteriyor. Bunun için site trafiğinin tamamını mümkün olduğunca bu çözüme sarmanız gerekiyor. Ve başvurduk alt filtre nginx'te.

Alt filtre nginx'te yanıt gövdesindeki bir satırı başka bir satırla değiştirmenize olanak tanıyan oldukça basit bir modüldür. Böylece tüm oluşumları değiştirdik semrush.com üzerinde semrushchina.cn tüm cevaplarda.

Ve... bu işe yaramadı çünkü arka uçlardan sıkıştırılmış içerik aldık, dolayısıyla alt filtre gerekli satırı bulamadı. Nginx'e başka bir yerel sunucu eklemek zorunda kaldım, bu da yanıtı açtı ve onu bir sonraki yerel sunucuya aktardı; o da zaten dizeyi değiştirmek, sıkıştırmak ve zincirdeki bir sonraki proxy sunucusuna göndermekle meşguldü.

Sonuç olarak müşteri nereden alacak? semrush.com, o aldı .semrushchina.cn ve kararımıza itaatkar bir şekilde uyduk.

Ancak etki alanını tek bir şekilde değiştirmek yeterli değildir, çünkü arka uçlar istemciden gelen sonraki isteklerde hala semrush.com'u beklemektedir. Buna göre tek yönlü değiştirmenin yapıldığı sunucuda basit bir düzenli ifade kullanarak istekten alt alan adını alıyoruz ve ardından bunu yapıyoruz. proxy_pass değişkenli $ ana bilgisayar, sergilendi $altalan.semrush.com. Kafa karıştırıcı görünebilir ama işe yarıyor. Ve iyi çalışıyor. Farklı mantık gerektiren bireysel alanlar için kendi sunucu bloklarınızı oluşturup ayrı bir konfigürasyon yapmanız yeterlidir. Aşağıda bu şemanın netliği ve gösterimi için kısaltılmış nginx yapılandırmaları verilmiştir.

Aşağıdaki yapılandırma, Çin'den gelen tüm istekleri işler. .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;
    }
}

Bu yapılandırma proxy'leri localhost 83 numaralı bağlantı noktasına gidin ve aşağıdaki yapılandırma orada bekliyor:

    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;
    }
}

Tekrar ediyorum, bunlar kırpılmış yapılandırmalardır.

Bunun gibi. Karmaşık görünebilir ama kelimelerle ifade ediliyor. Aslında her şey buharda pişmiş şalgamdan daha basit :)

Konu dışı incelemenin sonu

Bir süreliğine mutluyduk çünkü IPSEC tünellerinin düşmesiyle ilgili efsane doğrulanmamıştı. Ancak daha sonra tüneller düşmeye başladı. Birkaç dakika boyunca günde birkaç kez. Biraz ama bu bize uymadı. Her iki tünel de aynı yönlendirici üzerinde Ali tarafında sonlandırıldığı için bunun bölgesel bir sorun olabileceğine karar verdik ve yedek bölgeyi yükseltmemiz gerektiğine karar verdik.

Onu aldılar. Tüneller farklı zamanlarda arızalanmaya başladı ancak yük devretme, nginx'te yukarı akış düzeyinde bizim için iyi çalıştı. Ama sonra tüneller hemen hemen aynı anda çökmeye başladı 🙂 Ve 502 ve 504 yeniden başladı.Çalışma süresi bozulmaya başladı, biz de bu seçenek üzerinde çalışmaya başladık. Alibaba CEN (Bulut Kurumsal Ağı).

CEN

CEN - bu, Alibaba Cloud içindeki farklı bölgelerden iki VPC'nin bağlantısıdır, yani bulut içindeki herhangi bir bölgenin özel ağlarını birbirine bağlayabilirsiniz. Ve en önemlisi: Bu kanalın oldukça katı kuralları var. SLA. Hem hız hem de çalışma süresi açısından çok kararlıdır. Ama asla bu kadar basit değil:

• Çin vatandaşı veya tüzel kişi değilseniz bunu elde etmek ÇOK zordur,
• Kanal bant genişliğinin her megabiti için ödeme yapmanız gerekir.

Bağlanma fırsatına sahip olmak Çin toprakları и denizaşırı, iki Ali bölgesi arasında bir CEN oluşturduk: Cn-Shenzhen и us-doğu-1 (bize en yakın nokta-doğu4). Ali'de us-doğu-1 bir tane daha olması için başka bir sanal makineyi kaldırdım atlama.

Şöyle ortaya çıktı:

Tarayıcı test sonuçları aşağıdadır:

karar
Çalışma Zamanı
Medyan
75 Yüzdelik
95 Yüzdelik

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

Performansı IPSEC'den biraz daha iyidir. Ancak IPSEC aracılığıyla potansiyel olarak 100 Mbit/s hızında, CEN aracılığıyla ise yalnızca 5 Mbit/s ve üzeri hızda indirme yapabilirsiniz.

Hibrit gibi görünüyor, değil mi? IPSEC hızını ve CEN kararlılığını birleştirin.

Biz de bunu yaptık ve IPSEC tünelinde bir arıza olması durumunda trafiğe hem IPSEC hem de CEN üzerinden izin verdik. Çalışma süresi çok daha yüksek hale geldi, ancak site yükleme hızı hala arzu edilenin çok altında. Daha sonra daha önce kullandığımız ve test ettiğimiz tüm devreleri çizdim ve bu devreye biraz daha GCP eklemeye karar verdim, yani GLB.

GLB

GLB - Mı Küresel Yük Dengeleyici (veya Google Cloud Yük Dengeleyici). Bizim için önemli bir avantajı var: CDN bağlamında herhangi bir yayın IP'siTrafiği müşteriye en yakın veri merkezine yönlendirmenize olanak tanır, böylece trafik hızla Google'ın hızlı ağına girer ve "normal" İnternet'ten daha az kişi geçer.

Hiç düşünmeden büyüttük HTTP/HTTPS LB GCP'de alt filtreli sanal makinelerimizi arka uç olarak kurduk.

Birkaç şema vardı:

• Kullanmak Cloudflare Çin Ağıancak bu sefer Origin'in global belirtmesi gerekiyor IP GLB.
• İstemcileri şu tarihte sonlandır: Cn-Shenzhenve oradan trafiği doğrudan proxy'ye aktarın GLB.
• Doğrudan Çin'e gidin GLB.
• İstemcileri şu tarihte sonlandır: Cn-Shenzhen, oradan proxy'ye asya-doğu1 IPSEC aracılığıyla (içinde us-doğu4 CEN aracılığıyla), oradan GLB'ye gidin (sakin bir şekilde aşağıda bir resim ve açıklama olacak)

Tüm bu seçenekleri ve birkaç hibrit seçeneği daha test ettik:

• Bulut parlaması + GLB

Bu şema, çalışma süresi ve DNS hataları nedeniyle bize uymadı. Ancak test, CF tarafındaki hata düzeltilmeden önce gerçekleştirildi; belki şimdi daha iyidir (ancak bu, HTTP zaman aşımlarını hariç tutmaz).

• Ali + GLB

Bu şema aynı zamanda çalışma süresi açısından da bize uymuyordu, çünkü GLB, kabul edilebilir bir süre veya zaman aşımı süresinde bağlantı kurmanın imkansızlığı nedeniyle sıklıkla yukarı akışın dışında kalıyordu, çünkü Çin içindeki bir sunucu için GLB adresi dışarıda ve dolayısıyla arkasında kalıyor. Çin güvenlik duvarı. Büyü gerçekleşmedi.

• Yalnızca GLB

Öncekine benzer bir seçenek, ancak Çin'deki sunucuları kullanmıyordu: trafik doğrudan GLB'ye gidiyordu (DNS kayıtları değiştirildi). Buna göre, sıradan İnternet sağlayıcılarının hizmetlerini kullanan sıradan Çinli müşterilerin güvenlik duvarını geçme konusunda Ali Cloud'dan çok daha kötü bir duruma sahip olması nedeniyle sonuçlar tatmin edici değildi.

• Shenzhen -> (CEN/IPSEC) -> Vekil -> GLB

Burada tüm çözümlerin en iyisini kullanmaya karar verdik:

• CEN'den stabilite ve garantili SLA
• IPSEC'ten yüksek hız
• Google'ın "hızlı" ağı ve her noktaya yayını.

Şema şuna benzer: kullanıcı trafiği bir sanal makinede sonlandırılır. Ch-Shenzhen. Nginx yukarı akışları burada yapılandırılır; bunlardan bazıları IPSEC tünelinin diğer ucunda bulunan özel IP sunucularına işaret eder ve bazı yukarı akışlar, CEN'in diğer tarafındaki sunucuların özel adreslerine işaret eder. IPSEC bölgeye göre yapılandırıldı asya-doğu1 GCP'de (çözümün oluşturulduğu sırada Çin'e en yakın bölgeydi. GCP'nin artık Hong Kong'da da varlığı var). CEN - bölgeye us-doğu1 Ali Bulut'ta.

Daha sonra her iki uçtan gelen trafik şuraya yönlendirildi: her noktaya yayın IP GLByani Google'ın en yakın varlık noktasına ulaştı ve ağları üzerinden bölgeye gitti us-doğu4 yedek sanal makinelerin bulunduğu GCP'de (nginx'te alt filtreyle).

Bu hibrit çözüm, beklediğimiz gibi her teknolojinin avantajlarından yararlandı. Genel olarak trafik IPSEC'den hızlı geçer, ancak sorunlar başlarsa hızlı bir şekilde ve birkaç dakikalığına bu sunucuları yukarı akıştan çıkarırız ve tünel stabil hale gelene kadar trafiği yalnızca CEN üzerinden göndeririz.

Yukarıdaki listeden 4. çözümü uygulayarak istediğimizi ve o dönemde işin bizden gerektirdiğini elde ettik.

Yeni çözüm için tarayıcı testi sonuçlarının öncekilerle karşılaştırılması:

karar
Çalışma Zamanı
Medyan
75 Yüzdelik
95 Yüzdelik

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

Uyguladığımız çözümde her şey güzel ancak bölgesel ve hatta şehir düzeyinde trafiği hızlandırabilecek bir CDN yok. Teorik olarak bu, CDN sağlayıcısının hızlı iletişim kanallarını kullanarak son kullanıcılar için siteyi hızlandırmalıdır. Ve her zaman bunu düşündük. Ve artık projenin bir sonraki aşamasının zamanı geldi: Çin'deki CDN sağlayıcılarını arama ve test etme.

Bunu da bir sonraki son bölümde anlatacağım :)

Kaynak: habr.com