Prohoster > Blog > quản lý > Chúng ta đã vượt qua Bức tường lửa vĩ đại của Trung Quốc như thế nào (Phần 2)

Chúng ta đã vượt qua Bức tường lửa vĩ đại của Trung Quốc như thế nào (Phần 2)

Hi!

Nikita lại ở bên bạn, một kỹ sư hệ thống của công ty SEMrush. Và với bài viết này tôi tiếp tục câu chuyện về cách chúng tôi đưa ra giải pháp khắc phục Tường lửa Trung Quốc cho dịch vụ của chúng tôi semrush.com.

В phần trước Tôi đã nói:

  • những vấn đề gì phát sinh sau khi đưa ra quyết định “Chúng tôi cần làm cho dịch vụ của mình hoạt động được ở Trung Quốc”
  • Internet Trung Quốc có vấn đề gì?
  • tại sao bạn cần giấy phép ICP?
  • làm thế nào và tại sao chúng tôi quyết định thử nghiệm các giường thử nghiệm của mình với Catchpoint
  • kết quả của giải pháp đầu tiên của chúng tôi dựa trên Cloudflare China Network là gì
  • Cách chúng tôi tìm thấy lỗi trong Cloudflare DNS

Theo tôi, phần này là thú vị nhất vì nó tập trung vào việc triển khai kỹ thuật dàn dựng cụ thể. Và chúng ta sẽ bắt đầu, hay đúng hơn là tiếp tục, với Alibaba Cloud.

Alibaba Cloud

Alibaba Cloud là một nhà cung cấp đám mây khá lớn, có tất cả các dịch vụ cho phép họ tự gọi mình là nhà cung cấp đám mây một cách trung thực. Thật tốt khi họ có cơ hội đăng ký cho người dùng nước ngoài và hầu hết trang web đều được dịch sang tiếng Anh (đối với Trung Quốc thì đây là một điều xa xỉ). Trong đám mây này, bạn có thể làm việc với nhiều khu vực trên thế giới, Trung Quốc đại lục cũng như Châu Á Đại Dương (Hồng Kông, Đài Loan, v.v.).

IPSEC

Chúng tôi bắt đầu với địa lý. Vì trang web thử nghiệm của chúng tôi được đặt trên Google Cloud nên chúng tôi cần “liên kết” Alibaba Cloud với GCP, vì vậy, chúng tôi đã mở danh sách các vị trí có sự hiện diện của Google. Vào thời điểm đó họ vẫn chưa có trung tâm dữ liệu riêng ở Hồng Kông.
Khu vực gần nhất hóa ra là Đông Á1 (Đài Loan). Ali hóa ra là khu vực gần Đài Loan nhất của Trung Quốc đại lục cn-thâm quyến (Thâm Quyến).

Với địa hình đã mô tả và nâng cao toàn bộ cơ sở hạ tầng trong GCP và Ali. Đường hầm 100 Mbit/s giữa các đám mây xuất hiện gần như ngay lập tức. Về phía Thâm Quyến và Đài Loan, máy ảo ủy quyền đã được nâng lên. Ở Thâm Quyến, lưu lượng truy cập của người dùng bị chấm dứt, được ủy quyền qua một đường hầm đến Đài Loan và từ đó nó đi thẳng tới IP bên ngoài của dịch vụ của chúng tôi ở chúng tôi-đông (Bờ Đông Hoa Kỳ). Ping giữa các máy ảo qua đường hầm 24ms, điều đó không tệ lắm.

Đồng thời, chúng tôi đặt một khu vực thử nghiệm ở DNS đám mây của Alibaba. Sau khi ủy quyền vùng cho NS Ali, thời gian phân giải giảm từ 470 ms xuống 50 ms. Trước đó, khu vực này cũng có trên Cloudlfare.

Song song với đường hầm tới Đông Á1 nâng một đường hầm khác từ Thâm Quyến trực tiếp đến chúng tôi-đông4. Ở đó, họ tạo thêm nhiều máy ảo proxy và bắt đầu thử nghiệm cả hai giải pháp, định tuyến lưu lượng truy cập thử nghiệm bằng Cookie hoặc DNS. Bàn thử nghiệm được mô tả sơ đồ trong hình sau:

Độ trễ cho các đường hầm hóa ra như sau:
Ali cn-Thâm Quyến <—> GCP asia-east1 — 24ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms

Các bài kiểm tra trình duyệt Catchpoint cho thấy sự cải thiện xuất sắc.

So sánh kết quả thử nghiệm của hai giải pháp:

phán quyết
Thời gian hoạt động
trung tuyến
75 phần trăm
95 phần trăm

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

Đây là dữ liệu từ một giải pháp sử dụng đường hầm IPSEC thông qua Đông Á1. Qua us-east4 kết quả kém hơn, còn nhiều lỗi hơn nên mình sẽ không đưa ra kết quả.

Dựa trên kết quả của cuộc thử nghiệm hai đường hầm, một trong số đó kết thúc ở khu vực gần Trung Quốc nhất và đường còn lại ở điểm đến cuối cùng, rõ ràng là điều quan trọng là phải “ra khỏi” bức tường lửa của Trung Quốc càng nhanh càng tốt. có thể, sau đó sử dụng mạng nhanh (nhà cung cấp CDN, nhà cung cấp đám mây, v.v.). Không cần phải cố gắng vượt qua tường lửa và đến đích chỉ trong một lần. Đây không phải là cách nhanh nhất.

Nhìn chung, kết quả không tệ, tuy nhiên, semrush.com có ​​điểm trung bình là 8.8 giây và 75 Percentile 9.4 giây (trong cùng một bài kiểm tra).
Và trước khi tiếp tục, tôi muốn viết một đoạn trữ tình lạc đề ngắn gọn.

Lạc đề trữ tình

Sau khi người dùng vào trang web www.semrushchina.cn, được giải quyết thông qua các máy chủ DNS Trung Quốc “nhanh”, yêu cầu HTTP sẽ đi qua giải pháp nhanh của chúng tôi. Phản hồi được trả về theo cùng một đường dẫn, nhưng tên miền được chỉ định trong tất cả các tập lệnh JS, trang HTML và các thành phần khác của trang web semrush.com để biết các tài nguyên bổ sung phải được tải khi trang được hiển thị. Nghĩa là, khách hàng giải quyết bản ghi A “chính” www.semrushchina.cn và đi vào đường hầm nhanh, nhanh chóng nhận được phản hồi - một trang HTML có nội dung:

  • tải xuống js như vậy và như vậy từ sso.semrush.com,
  • Nhận các tệp CSS từ cdn.semrush.com,
  • và cũng lấy một số hình ảnh từ dab.semrush.com
  • và như vậy.

Trình duyệt bắt đầu truy cập Internet “bên ngoài” để lấy các tài nguyên này, mỗi lần đi qua tường lửa sẽ ngốn nhiều thời gian phản hồi.

Nhưng lần kiểm tra trước hiển thị kết quả khi không có tài nguyên trên trang semrush.com, chỉ semrushchina.cnvà *.semrushchina.cn phân giải theo địa chỉ của máy ảo ở Thâm Quyến để sau đó đi vào đường hầm.

Chỉ bằng cách này, bằng cách đẩy tất cả lưu lượng truy cập có thể có lên mức tối đa thông qua giải pháp của bạn để nhanh chóng vượt qua tường lửa Trung Quốc, bạn mới có thể đạt được tốc độ chấp nhận được và các chỉ báo về tính khả dụng của trang web cũng như kết quả kiểm tra giải pháp trung thực.
Chúng tôi đã làm điều này mà không cần chỉnh sửa mã nào về phía sản phẩm của nhóm.

Bộ lọc phụ

Giải pháp đã ra đời gần như ngay lập tức sau khi vấn đề này xuất hiện. Chúng tôi cần PoC (Bằng chứng về khái niệm) rằng các giải pháp thâm nhập tường lửa của chúng tôi thực sự hoạt động tốt. Để làm điều này, bạn cần đưa tất cả lưu lượng truy cập trang web vào giải pháp này càng nhiều càng tốt. Và chúng tôi đã áp dụng bộ lọc phụ trong nginx.

Bộ lọc phụ là một mô-đun khá đơn giản trong nginx cho phép bạn thay đổi một dòng trong phần nội dung phản hồi sang một dòng khác. Vì vậy chúng tôi đã thay đổi tất cả các lần xuất hiện semrush.com trên semrushchina.cn trong tất cả các câu trả lời.

Và... nó không hoạt động vì chúng tôi đã nhận được nội dung nén từ phần phụ trợ, vì vậy bộ lọc phụ không tìm thấy dòng yêu cầu. Tôi đã phải thêm một máy chủ cục bộ khác vào nginx, máy chủ này đã giải nén phản hồi và chuyển nó sang máy chủ cục bộ tiếp theo, máy chủ này đang bận thay thế chuỗi, nén nó và gửi nó đến máy chủ proxy tiếp theo trong chuỗi.

Kết quả là, khách hàng sẽ nhận được ở đâu .semrush.com, anh ấy đã nhận được .semrushchina.cn và ngoan ngoãn thực hiện quyết định của chúng tôi.

Tuy nhiên, chỉ thay đổi miền một chiều là chưa đủ vì các chương trình phụ trợ vẫn mong đợi semrush.com trong các yêu cầu tiếp theo từ khách hàng. Theo đó, trên cùng một máy chủ nơi việc thay thế một chiều được thực hiện, bằng cách sử dụng biểu thức chính quy đơn giản, chúng tôi nhận được tên miền phụ từ yêu cầu và sau đó chúng tôi thực hiện proxy_pass với biến $ host, được trưng bày ở $tên miền phụ.semrush.com. Nó có vẻ khó hiểu, nhưng nó hoạt động. Và nó hoạt động tốt. Đối với các miền riêng lẻ yêu cầu logic khác nhau, bạn chỉ cần tạo các khối máy chủ của riêng mình và tạo cấu hình riêng. Dưới đây là các cấu hình nginx rút gọn để làm rõ và trình diễn sơ đồ này.

Cấu hình sau xử lý tất cả các yêu cầu từ Trung Quốc đến .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;
    }
}

Proxy cấu hình này để localhost tới cổng 83 và cấu hình sau đang chờ ở đó:

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

Tôi nhắc lại, đây là những cấu hình đã bị cắt.

Như thế. Nó có thể trông phức tạp, nhưng đó là bằng lời nói. Thực ra mọi thứ còn đơn giản hơn củ cải hấp :)

Kết thúc lạc đề

Trong một thời gian, chúng tôi rất vui vì huyền thoại về việc đường hầm IPSEC bị sập vẫn chưa được xác nhận. Nhưng sau đó các đường hầm bắt đầu sụp đổ. Vài lần một ngày trong vài phút. Một chút, nhưng điều đó không phù hợp với chúng tôi. Vì cả hai đường hầm đều bị chấm dứt ở phía Ali trên cùng một bộ định tuyến nên chúng tôi quyết định rằng có lẽ đây là sự cố khu vực và chúng tôi cần nâng cao khu vực dự phòng.

Họ đã nhặt nó lên. Các đường hầm bắt đầu gặp lỗi vào những thời điểm khác nhau, nhưng quá trình chuyển đổi dự phòng vẫn hoạt động tốt đối với chúng tôi ở cấp độ thượng nguồn trong nginx. Nhưng sau đó các đường hầm bắt đầu sụp đổ cùng lúc 🙂 Và 502 và 504 lại bắt đầu. Thời gian hoạt động bắt đầu kém đi, vì vậy chúng tôi bắt đầu nghiên cứu phương án với Alibaba CEN (Mạng doanh nghiệp đám mây).

CEN

CEN - đây là khả năng kết nối của hai VPC từ các khu vực khác nhau trong Alibaba Cloud, tức là bạn có thể kết nối các mạng riêng của bất kỳ khu vực nào trong đám mây với nhau. Và quan trọng nhất: kênh này có quy định khá nghiêm ngặt SLA. Nó rất ổn định cả về tốc độ và thời gian hoạt động. Nhưng nó không bao giờ đơn giản như vậy:

  • RẤT khó có được nếu bạn không phải là công dân Trung Quốc hoặc pháp nhân,
  • Bạn cần trả tiền cho mỗi megabit dung lượng kênh.

Có cơ hội kết nối Trung hoa đại lục и Học ở nước ngoài, chúng tôi đã tạo CEN giữa hai vùng Ali: cn-thâm quyến и us-East-1 (điểm gần nhất với chúng tôi-East4). ở Ali us-East-1 đã tạo ra một máy ảo khác để có thêm một máy ảo nữa hop.

Hóa ra như thế này:

Kết quả kiểm tra trình duyệt như bên dưới:

phán quyết
Thời gian hoạt động
trung tuyến
75 phần trăm
95 phần trăm

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

Hiệu suất tốt hơn một chút so với IPSEC. Nhưng thông qua IPSEC, bạn có thể tải xuống ở tốc độ 100 Mbit/s và chỉ qua CEN ở tốc độ 5 Mbit/s trở lên.

Nghe giống như một con lai, phải không? Kết hợp tốc độ IPSEC và độ ổn định CEN.

Đây là những gì chúng tôi đã làm, cho phép lưu lượng truy cập qua cả IPSEC và CEN trong trường hợp đường hầm IPSEC bị lỗi. Thời gian hoạt động đã cao hơn nhiều, nhưng tốc độ tải trang vẫn còn nhiều điều chưa được mong đợi. Sau đó, tôi vẽ tất cả các mạch mà chúng tôi đã sử dụng và thử nghiệm, đồng thời quyết định thử thêm một chút GCP vào mạch này, cụ thể là mũ lưỡi trai.

mũ lưỡi trai

mũ lưỡi trai - Cân bằng tải toàn cầu (hoặc Trình cân bằng tải đám mây của Google). Nó có một lợi thế quan trọng đối với chúng tôi: trong bối cảnh CDN, nó có IP bất kỳ, cho phép bạn định tuyến lưu lượng truy cập đến trung tâm dữ liệu gần khách hàng nhất để lưu lượng truy cập nhanh chóng đi vào mạng nhanh của Google và ít đi qua Internet “thông thường”.

Không cần suy nghĩ hai lần, chúng tôi đã nêu ra HTTP/HTTPS LB Chúng tôi đã cài đặt các máy ảo của mình với bộ lọc con trong GCP và làm phần phụ trợ.

Có một số kế hoạch:

  • Để sử dụng Mạng Cloudflare Trung Quốc, nhưng lần này Origin nên chỉ định toàn cầu IP GLB.
  • Chấm dứt khách hàng tại cn-thâm quyếnvà từ đó ủy quyền lưu lượng truy cập trực tiếp đến mũ lưỡi trai.
  • Đi thẳng từ Trung Quốc tới mũ lưỡi trai.
  • Chấm dứt khách hàng tại cn-thâm quyến, từ đó proxy đến Đông Á1 thông qua IPSEC (trong chúng tôi-đông4 qua CEN), từ đó vào GLB (bình tĩnh sẽ có hình và giải thích bên dưới)

Chúng tôi đã thử nghiệm tất cả các tùy chọn này và một số tùy chọn kết hợp khác:

  • Đám mây + GLB

Sơ đồ này không phù hợp với chúng tôi do lỗi thời gian hoạt động và DNS. Nhưng thử nghiệm đã được thực hiện trước khi lỗi được sửa ở phía CF, có lẽ bây giờ mọi chuyện đã tốt hơn (tuy nhiên, điều này không loại trừ thời gian chờ HTTP).

  • Ali + GLB

Kế hoạch này cũng không phù hợp với chúng tôi về mặt thời gian hoạt động, vì GLB thường bị rơi ra khỏi thượng nguồn do không thể kết nối trong thời gian hoặc thời gian chờ có thể chấp nhận được, vì đối với máy chủ ở Trung Quốc, địa chỉ GLB vẫn ở bên ngoài và do đó nằm sau địa chỉ Tường lửa Trung Quốc. Phép màu đã không xảy ra.

  • chỉ GLB

Một tùy chọn tương tự như tùy chọn trước, chỉ có điều nó không sử dụng máy chủ ở Trung Quốc: lưu lượng truy cập trực tiếp đến GLB (bản ghi DNS đã được thay đổi). Theo đó, kết quả không khả quan, vì các khách hàng Trung Quốc bình thường sử dụng dịch vụ của các nhà cung cấp Internet thông thường gặp tình huống vượt tường lửa tồi tệ hơn nhiều so với Ali Cloud.

  • Thâm Quyến -> (CEN/IPSEC) -> Proxy -> GLB

Ở đây chúng tôi quyết định sử dụng giải pháp tốt nhất:

  • sự ổn định và SLA được đảm bảo từ CEN
  • tốc độ cao từ IPSEC
  • Mạng “nhanh” của Google và chương trình phát sóng bất kỳ của nó.

Sơ đồ trông giống như thế này: lưu lượng người dùng bị chấm dứt trên một máy ảo trong ch-thâm quyến. Các luồng ngược dòng của Nginx được định cấu hình ở đó, một số trong đó trỏ đến các máy chủ IP riêng nằm ở đầu kia của đường hầm IPSEC và một số luồng ngược dòng trỏ đến địa chỉ riêng của các máy chủ ở phía bên kia của CEN. IPSEC được cấu hình theo vùng Đông Á1 tại GCP (là khu vực gần Trung Quốc nhất vào thời điểm giải pháp được tạo ra. GCP hiện cũng có mặt ở Hồng Kông). CEN - tới khu vực chúng tôi-đông1 trong đám mây Ali.

Sau đó lưu lượng truy cập từ cả hai đầu được hướng đến IP GLB bất kỳ, nghĩa là đến điểm hiện diện gần nhất của Google và đi qua mạng của nó tới khu vực chúng tôi-đông4 trong GCP, trong đó có các máy ảo thay thế (có bộ lọc con trong nginx).

Giải pháp kết hợp này, đúng như chúng tôi mong đợi, đã tận dụng được lợi ích của từng công nghệ. Nói chung, lưu lượng truy cập đi qua IPSEC nhanh, nhưng nếu có sự cố xảy ra, chúng tôi sẽ nhanh chóng loại bỏ các máy chủ này ra khỏi luồng ngược trong vài phút và chỉ gửi lưu lượng qua CEN cho đến khi đường hầm ổn định.

Bằng cách triển khai giải pháp thứ 4 trong danh sách trên, chúng tôi đã đạt được những gì mình mong muốn và những gì doanh nghiệp yêu cầu ở chúng tôi vào thời điểm đó.

Kết quả kiểm tra trình duyệt cho giải pháp mới so với giải pháp trước đó:

phán quyết
Thời gian hoạt động
trung tuyến
75 phần trăm
95 phần trăm

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

Mọi thứ đều tốt trong giải pháp chúng tôi triển khai, nhưng không có CDN nào có thể tăng tốc lưu lượng truy cập ở cấp khu vực và thậm chí cả thành phố. Về lý thuyết, điều này sẽ tăng tốc độ trang web cho người dùng cuối bằng cách sử dụng các kênh liên lạc nhanh của nhà cung cấp CDN. Và chúng tôi đã nghĩ về nó mọi lúc. Và bây giờ, đã đến lúc thực hiện bước tiếp theo của dự án: tìm kiếm và thử nghiệm các nhà cung cấp CDN ở Trung Quốc.

Và tôi sẽ kể cho bạn nghe về điều này ở phần tiếp theo, phần cuối cùng :)

Nguồn: www.habr.com

Thêm một lời nhận xét