우리가 중국의 만리방화벽을 돌파한 방법(2부)

Привет!

회사의 시스템 엔지니어 Nikita가 다시 여러분과 함께합니다. SEMrush. 그리고 이 기사를 통해 우리가 해결 방법을 생각해낸 방법에 대한 이야기를 계속하겠습니다. 중국 방화벽 semrush.com 서비스를 위해.

В 이전 부분 나는 말했다:

• “중국에서 서비스를 해야 한다”라고 결정한 후 어떤 문제가 발생하는가?
• 중국 인터넷에는 어떤 문제가 있나요?
• 왜 ICP 라이센스가 필요합니까?
• Catchpoint로 테스트베드를 테스트하기로 결정한 방법과 이유
• Cloudflare China Network를 기반으로 한 첫 번째 솔루션의 결과는 무엇이었습니까?
• Cloudflare DNS에서 버그를 발견한 방법

제 생각에는 이 부분이 가장 흥미롭습니다. 왜냐하면 이 부분은 스테이징의 특정 기술 구현에 중점을 두기 때문입니다. 그리고 우리는 다음과 같이 시작하거나 계속할 것입니다. 알리바바 클라우드.

알리바바 클라우드

알리바바 클라우드 는 정직하게 클라우드 제공자라고 부를 수 있는 모든 서비스를 갖춘 상당히 큰 클라우드 제공업체입니다. 외국인 사용자를 위해 등록할 수 있는 기회가 있고 대부분의 사이트가 영어로 번역되어 있다는 점이 좋습니다(중국의 경우 이것은 사치입니다). 이 클라우드에서는 중국 본토는 물론 해양 아시아(홍콩, 대만 등) 등 전 세계 여러 지역과 협력할 수 있습니다.

IPSEC

우리는 지리학부터 시작했습니다. 테스트 사이트가 Google Cloud에 있었기 때문에 Alibaba Cloud를 GCP와 '연결'해야 했기 때문에 Google이 있는 위치 목록을 열었습니다. 당시에는 홍콩에 자체 데이터 센터가 아직 없었습니다.
가장 가까운 지역은 다음과 같습니다. 아시아-동부1 (대만). 알리는 중국 본토에서 대만과 가장 가까운 지역으로 밝혀졌습니다. cn-심천 (심천).

과 테라 포름 GCP와 Ali의 전체 인프라를 설명하고 올렸습니다. 구름 사이의 100Mbit/s 터널이 거의 즉시 올라갔습니다. 선전과 대만 측에서는 프록시 가상 머신이 등장했습니다. 심천에서는 사용자 트래픽이 종료되고 터널을 통해 대만으로 프록시 처리되며 거기서부터 당사 서비스의 외부 IP로 직접 이동됩니다. 미국 동부 (미국 동부 해안). 터널을 통한 가상 머신 간 핑 24ms, 그렇게 나쁘지는 않습니다.

동시에 우리는 테스트 영역을 다음과 같이 배치했습니다. 알리바바 클라우드 DNS. 영역을 NS Ali에 위임한 후 해결 시간이 470ms에서 50 MS. 이전에는 해당 영역이 Cloudlfare에도 있었습니다.

터널과 평행하게 아시아-동부1 심천에서 직접 또 다른 터널을 건설했습니다. 미국-동부4. 그곳에서 그들은 더 많은 프록시 가상 머신을 생성하고 두 솔루션을 모두 테스트하기 시작했으며 쿠키 또는 DNS를 사용하여 테스트 트래픽을 라우팅했습니다. 테스트 벤치는 다음 그림에 개략적으로 설명되어 있습니다.

터널의 지연 시간은 다음과 같습니다.
알리 cn-심천 <—> GCP asia-east1 — 24ms
알리 cn-심천 <—> GCP us-east4 — 200ms

Catchpoint 브라우저 테스트에서는 탁월한 개선이 보고되었습니다.

두 가지 솔루션에 대한 테스트 결과를 비교하십시오.

결정
가동 시간
중앙값
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 페이지에는 다음과 같은 내용이 표시됩니다.

• sso.semrush.com에서 그러한 js를 다운로드하십시오.
• cdn.semrush.com에서 CSS 파일을 가져오세요.
• 그리고 dab.semrush.com에서 사진을 찍으세요.
• 등.

브라우저는 응답 시간을 잡아먹는 방화벽을 통과할 때마다 이러한 리소스를 얻기 위해 "외부" 인터넷으로 이동하기 시작합니다.

하지만 이전 테스트에서는 페이지에 리소스가 없을 때의 결과가 표시됩니다. semrush.com, 오직 semrushchina.cn, *.semrushchina.cn은 터널에 들어가기 위해 선전에 있는 가상 머신의 주소를 확인합니다.

이러한 방식으로만 중국 방화벽을 신속하게 통과하기 위해 솔루션을 통해 가능한 모든 트래픽을 최대화함으로써 허용 가능한 속도와 웹 사이트 가용성 지표는 물론 솔직한 솔루션 테스트 결과를 얻을 수 있습니다.
우리는 팀의 제품 측에서 단일 코드 편집 없이 이 작업을 수행했습니다.

하위 필터

이 문제가 발생한 직후에 솔루션이 탄생했습니다. 우리는 필요했다 PoC (개념 증명) 우리의 방화벽 침투 솔루션이 실제로 잘 작동한다는 것입니다. 이렇게 하려면 가능한 한 모든 사이트 트래픽을 이 솔루션으로 래핑해야 합니다. 그리고 우리는 신청했다 하위 필터 nginx에서.

하위 필터 응답 본문의 한 줄을 다른 줄로 변경할 수 있는 nginx의 매우 간단한 모듈입니다. 그래서 우리는 모든 발생을 변경했습니다 semrush.com 에 semrushchina.cn 모든 답변에서.

그리고... 백엔드에서 압축된 콘텐츠를 수신했기 때문에 작동하지 않았으므로 하위 필터가 필요한 라인을 찾지 못했습니다. nginx에 또 다른 로컬 서버를 추가해야 했고 응답의 압축을 풀고 다음 로컬 서버로 전달했습니다. 이 서버는 이미 문자열을 교체하고 압축하여 체인의 다음 프록시 서버로 보내는 중이었습니다.

결과적으로 클라이언트는 어디서 받을 것인가? .semrush.com, 그는 받았다 .semrushchina.cn 그리고 우리의 결정을 순종적으로 진행했습니다.

그러나 단순히 도메인을 한 가지 방법으로 변경하는 것만으로는 충분하지 않습니다. 백엔드에서는 클라이언트의 후속 요청에서 여전히 semrush.com을 예상하기 때문입니다. 따라서 단방향 교체가 수행되는 동일한 서버에서 간단한 정규식을 사용하여 요청에서 하위 도메인을 가져온 다음 프록시 패스 변수가 있는 $호스트, 에 전시됨 $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;
    }
}

이 구성은 다음으로 프록시됩니다. 로컬 호스트 포트 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 터널 붕괴에 대한 신화가 확인되지 않았기 때문에 한동안 우리는 기뻤습니다. 그러나 터널이 무너지기 시작했습니다. 몇 분 동안 하루에 여러 번. 조금이지만 그것은 우리에게 적합하지 않았습니다. 두 터널 모두 동일한 라우터의 Ali 측에서 종료되었으므로 이것이 지역적 문제일 수 있다고 판단하여 백업 지역을 높여야 한다고 판단했습니다.

그들은 그것을 집어 들었습니다. 터널은 서로 다른 시간에 실패하기 시작했지만 nginx의 업스트림 수준에서는 장애 조치가 제대로 작동했습니다. 그런데 거의 동시에 터널이 무너지기 시작했습니다 🙂 그리고 502와 504가 다시 시작되었습니다. 가동 시간이 악화되기 시작하여 우리는 옵션 작업을 시작했습니다. 알리바바 CEN (클라우드 엔터프라이즈 네트워크).

CEN

CEN - 이는 Alibaba Cloud 내 서로 다른 지역의 두 VPC를 연결하는 것입니다. 즉, 클라우드 내 모든 지역의 프라이빗 네트워크를 서로 연결할 수 있습니다. 그리고 가장 중요한 것은 이 채널의 규정이 상당히 엄격하다는 것입니다. 서비스 수준 계약 (SLA). 속도와 가동 시간 모두 매우 안정적입니다. 하지만 결코 그렇게 간단하지는 않습니다.

• 중국 시민이나 법인이 아닌 경우 획득하기가 매우 어렵습니다.
• 채널 대역폭의 메가비트당 비용을 지불해야 합니다.

연결될 수 있는 기회를 갖게 됨 중국 본토 и 해외, 우리는 두 개의 Ali 지역 사이에 CEN을 만들었습니다. cn-심천 и 미국 동부 1 (us-east4에 가장 가까운 지점). 알리에서 미국 동부 1 하나 더 있도록 다른 가상 머신을 생성했습니다. 홉.

결과는 다음과 같습니다.

브라우저 테스트 결과는 다음과 같습니다.

결정
가동 시간
중앙값
75 백분위수
95 백분위수

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

성능은 IPSEC보다 약간 더 좋습니다. 그러나 IPSEC를 통해 잠재적으로 100Mbit/s의 속도로 다운로드할 수 있으며 CEN을 통해서는 5Mbit/s 이상의 속도로만 다운로드할 수 있습니다.

하이브리드처럼 들리죠? IPSEC 속도와 CEN 안정성을 결합합니다.

이것이 우리가 한 일이며, IPSEC 터널에 장애가 발생할 경우 IPSEC와 CEN을 모두 통한 트래픽을 허용하는 것입니다. 가동 시간은 훨씬 높아졌지만 사이트 로딩 속도는 여전히 아쉬운 부분이 많습니다. 그런 다음 우리가 이미 사용하고 테스트한 모든 회로를 그리고 이 회로에 GCP를 조금 더 추가하기로 결정했습니다. GLB.

GLB

GLB -가요 글로벌 로드 밸런서 (또는 Google Cloud 로드 밸런서). 이는 우리에게 중요한 이점을 제공합니다. CDN의 맥락에서는 다음과 같은 이점이 있습니다. 애니캐스트 IP, 클라이언트와 가장 가까운 데이터 센터로 트래픽을 라우팅할 수 있으므로 트래픽이 Google의 빠른 네트워크로 빠르게 유입되고 '일반' 인터넷을 통과하는 트래픽이 줄어듭니다.

두 번 생각하지 않고 키웠어 HTTP/HTTPS LB 우리는 GCP에 하위 필터가 있는 가상 머신을 백엔드로 설치했습니다.

몇 가지 계획이있었습니다.

• 사용 Cloudflare 중국 네트워크하지만 이번에는 Origin이 전역을 지정해야 합니다. IP GLB.
• 클라이언트 종료 시간: cn-심천, 거기에서 트래픽을 직접 프록시로 프록시합니다. GLB.
• 중국에서 바로가기 GLB.
• 클라이언트 종료 시간: cn-심천, 거기에서 프록시로 아시아-동부1 IPSEC를 통해( 미국-동부4 CEN을 통해), 거기에서 GLB로 이동합니다. ( 침착하게, 아래에 사진과 설명이 있을 것입니다.)

우리는 이러한 모든 옵션과 몇 가지 하이브리드 옵션을 테스트했습니다.

• 클라우드플레어 + GLB

이 방식은 가동 시간 및 DNS 오류로 인해 우리에게 적합하지 않았습니다. 그러나 테스트는 CF 측에서 버그가 수정되기 전에 수행되었으며 아마도 지금은 더 나을 것입니다(단, HTTP 시간 초과는 제외되지 않습니다).

• 알리 + GLB

이 체계는 또한 가동 시간 측면에서 우리에게 적합하지 않았습니다. GLB는 허용 가능한 시간 또는 시간 초과에 연결할 수 없기 때문에 종종 업스트림에서 벗어났기 때문입니다. 왜냐하면 중국 내부 서버의 경우 GLB 주소가 외부에 남아 있기 때문입니다. 중국 방화벽. 마법은 일어나지 않았습니다.

• GLB만 해당

이전 옵션과 유사한 옵션이지만 중국 자체의 서버를 사용하지 않았습니다. 트래픽이 GLB로 직접 이동했습니다(DNS 레코드가 변경됨). 이에 따라 일반 인터넷 제공업체의 서비스를 이용하는 일반 중국 고객들의 경우 방화벽 통과 상황이 알리 클라우드보다 훨씬 열악해 결과가 만족스럽지 못했다.

• 심천 -> (CEN/IPSEC) -> 프록시 -> GLB

여기에서 우리는 모든 솔루션 중 최고의 솔루션을 사용하기로 결정했습니다.

• CEN의 안정성 및 보장된 SLA
• IPSEC의 고속
• Google의 "빠른" 네트워크와 애니캐스트.

구성표는 다음과 같습니다. 사용자 트래픽은 가상 머신에서 종료됩니다. ch-심천. Nginx 업스트림은 거기에 구성되어 있으며, 그 중 일부는 IPSEC 터널의 반대편 끝에 있는 개인 IP 서버를 가리키고, 일부 업스트림은 CEN 반대편에 있는 서버의 개인 주소를 가리킵니다. 리전으로 구성된 IPSEC 아시아-동부1 GCP(솔루션이 생성될 당시 중국과 가장 가까운 지역이었습니다. 현재 GCP는 홍콩에도 있습니다). CEN - 지역별 미국-동부1 알리 클라우드에서.

그런 다음 양쪽 끝의 트래픽이 다음으로 전달되었습니다. 애니캐스트 IP GLB, 즉, Google의 가장 가까운 지점으로 이동하여 네트워크를 통해 해당 지역으로 이동했습니다. 미국-동부4 GCP에는 대체 가상 머신이 있었습니다(nginx에 하위 필터 포함).

우리가 예상한 대로 이 하이브리드 솔루션은 각 기술의 이점을 활용했습니다. 일반적으로 트래픽은 빠른 IPSEC를 통과하지만 문제가 시작되면 신속하게 몇 분 동안 이러한 서버를 업스트림에서 제거하고 터널이 안정화될 때까지 CEN을 통해서만 트래픽을 보냅니다.

위 목록의 4번째 솔루션을 구현함으로써 우리는 그 시점에서 우리가 원했던 것과 비즈니스에서 우리에게 요구한 것을 달성했습니다.

이전 솔루션과 비교한 새로운 솔루션의 브라우저 테스트 결과:

결정
가동 시간
중앙값
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 제공업체 검색 및 테스트를 수행할 때가 되었습니다.

이에 대해서는 다음 마지막 부분에서 알려 드리겠습니다. :)

출처 : habr.com