Comment nous avons contourné le Grand Firewall de Chine (partie 2)

Bonjour !

C'est encore Nikita — ingénieur système chez SEMrush. Dans cet article, je poursuis l'histoire de comment nous avons conçu une solution de contournement du Firewall chinois pour notre service semrush.com.

Dans partie précédente j'ai expliqué :

• quels problèmes surgissent après la décision « Nous devons faire en sorte que notre service fonctionne en Chine »
• quels problèmes présente l'internet chinois
• pourquoi un permis ICP est nécessaire
• comment et pourquoi nous avons décidé de tester nos environnements de test avec Catchpoint
• quel résultat a donné notre première solution basée sur le Cloudflare China Network
• comment nous avons trouvé un bug dans le DNS de Cloudflare

Cette partie est, à mon avis, la plus intéressante, car elle se concentre sur des réalisations techniques concrètes des stades. Et nous allons commencer, ou plutôt continuer, par Alibaba Cloud.

Alibaba Cloud

Alibaba Cloud — un fournisseur de cloud assez important, qui dispose de tous les services lui permettant de se qualifier de cloud provider. Heureusement, ils permettent aux utilisateurs étrangers de s'inscrire, et une grande partie du site est traduite en anglais (un luxe pour la Chine). Dans ce cloud, il est possible de travailler avec de nombreuses régions du monde, de la Chine continentale ainsi que de l'Asie Pacifique (Hong Kong, Taïwan, etc.).

IPSEC

Nous avons commencé par la géographie. Comme notre site de test se trouvait dans Google Cloud, il était nécessaire de "relier" Alibaba Cloud à GCP, donc nous avons ouvert la liste des emplacements où Google est présent. À ce moment-là, ils n'avaient pas encore de centre de données à Hong Kong.
La région la plus proche était asia-east1 (Taïwan). Le plus proche pour Ali parmi les régions de la Chine continentale à Taïwan était cn-shenzhen (Shenzhen).

Avec terraform nous avons décrit et déployé toute l'infrastructure dans GCP et Ali. Un tunnel de 100 mbps entre les clouds a été établi presque instantanément. Du côté de Shenzhen et de Taïwan, nous avons monté des machines virtuelles proxy. À Shenzhen, le trafic utilisateur est terminé, est proxifié à travers le tunnel vers Taïwan, et de là il va directement vers l'IP externe de notre service à us-east (côte Est des États-Unis). Le ping entre les machines virtuelles à travers le tunnel 24 ms, ce qui n'est pas si mal.

En parallèle, nous avons placé une zone de test dans Alibaba Cloud DNS. Après avoir délégué la zone au NS d'Ali, le temps de résolution est passé de 470 ms à 50 ms. Avant cela, la zone était également sur Cloudflare.

En parallèle avec le tunnel jusqu'à asia-east1 nous avons ouvert un autre tunnel de Shenzhen directement vers us-east4. Ils ont créé d'autres machines virtuelles de proxys et ont commencé à mesurer les deux solutions, en routant le trafic de test à l'aide de Cookies ou DNS. Le banc d'essai de test est schématiquement décrit dans le dessin suivant :

La latence pour les tunnels était la suivante :
Ali cn-shenzhen GCP asia-east1 — 24ms
Ali cn-shenzhen GCP us-east4 — 200ms

Les tests de navigateur Catchpoint ont rapporté une excellente amélioration des performances.

Comparez les résultats des tests pour les deux solutions :

Solution
Uptime
Médiane
75e percentile
95e percentile

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

Voici les données de la solution utilisant un tunnel IPSEC à travers asia-east1. À travers us-east4, les résultats étaient pires, et il y avait plus d'erreurs, donc je ne vais pas les inclure.

D'après les résultats de ce test de deux tunnels, dont l'un se termine dans la région la plus proche de la Chine et l'autre à la destination finale, il est clair qu'il est important de 'surgir' le plus rapidement possible des barrières de feu chinoises, puis d'utiliser des réseaux rapides (fournisseurs de CDN, fournisseurs de cloud, etc.). Il ne faut pas essayer de traverser le pare-feu d'un seul coup pour atteindre la destination. Ce n'est pas le chemin le plus rapide.

Globalement, les résultats sont satisfaisants ; cependant, le médian de semrush.com est de 8,8s et le 75e percentile de 9,4s (sur le même test).
Et avant d'aller plus loin, je voudrais faire une petite digression.

Parenthèse lyrique

Après qu'un utilisateur accède au site www.semrushchina.cn, qui se résout via des serveurs DNS chinois 'rapides', la requête HTTP passe par notre solution rapide. La réponse revient par le même chemin, mais dans tous les scripts JS, les pages HTML et d'autres éléments de la page web, le domaine est indiqué semrush.com pour les ressources supplémentaires qui doivent être chargées lors du rendu de la page. Cela signifie que le client résout l'enregistrement A 'principal' www.semrushchina.cn et entre dans le tunnel rapide, recevant rapidement la réponse — la page HTML, qui indique :

• télécharge ce js de sso.semrush.com,
• prends les fichiers CSS de cdn.semrush.com,
• et prends aussi des images de dab.semrush.com
• et ainsi de suite.

Le navigateur commence à aller sur l'internet 'extérieur' pour ces ressources, passant chaque fois par le pare-feu qui consomme du temps de réponse.

Mais dans le test précédent, les résultats étaient présentés quand il n'y avait pas de ressources sur la page semrush.com, seulement semrushchina.cn, et *.semrushchina.cn se résolvait à l'adresse de la machine virtuelle à Shenzhen, pour ensuite entrer dans le tunnel.

C'est seulement en maximisant le trafic via notre solution de contournement rapide du pare-feu chinois que nous pouvons obtenir des vitesses acceptables et des indicateurs de disponibilité du site, ainsi que des résultats d'essai honnêtes.
Nous avons fait cela sans aucune modification du code côté produit des équipes.

Sous-filtre

La solution est née presque immédiatement après l'émergence de ce problème. Nous avions besoin de PoC (Proof of Concept), pour prouver que nos solutions de contournement du pare-feu fonctionnent vraiment bien. Pour cela, il est nécessaire de canaliser tout le trafic du site à travers cette solution. Et nous avons appliqué sous-filtre dans nginx.

Sous-filtre C'est un module plutôt simple dans nginx, permettant de remplacer une ligne de la réponse par une autre ligne. Nous avons donc remplacé toutes les occurrences semrush.com sur semrushchina.cn dans toutes les réponses.

Et... cela n'a pas fonctionné, car nous recevions du contenu compressé des back-ends, et donc le sous-filtre ne trouvait pas la ligne requise. Nous avons dû ajouter un autre serveur local dans nginx, qui décompressait la réponse et la transmettait au serveur local suivant, qui s'occupait de substituer la ligne, de la compresser et de la remettre au prochain proxy dans la chaîne.

En fin de compte, où le client aurait reçu <subdomain>.semrush.com, il recevait <subdomain>.semrushchina.cn et se dirigeait docilement à travers notre solution.

Cependant, il n'est pas suffisant de simplement changer le domaine dans un sens, car les back-ends s'attendent toujours à recevoir semrush.com dans les requêtes suivantes du client. Ainsi, sur le même serveur où a lieu la substitution dans un sens, à l'aide d'une simple expression régulière, nous obtenons le sous-domaine de la requête, puis nous effectuons proxy_pass avec la variable $host, définie à $subdomain.semrush.com. Cela peut sembler déroutant, mais ça fonctionne. Et bien. Pour des domaines spécifiques nécessitant une autre logique, il suffit de créer des blocs de serveur distincts et de faire une configuration séparée. Ci-dessous, des configurations nginx abrégées sont présentées pour illustrer et démontrer ce schéma.

La configuration suivante traite toutes les requêtes en provenance de Chine vers .semrushchina.cn:

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

Cette configuration proxy vers localhost le port 83, où attend la configuration suivante :

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

Je le répète, ce sont des configurations abrégées.

À peu près comme ça. Cela peut sembler complexe, mais c'est juste en théorie. En pratique, c'est plus simple qu'une tarte 🙂

Fin de la digression lyrique

Pendant un certain temps, nous étions heureux, car le mythe des tunnels IPSEC qui chutent ne s'est pas confirmé. Mais ensuite, les tunnels ont commencé à tomber. Plusieurs fois par jour pendant quelques minutes. Un peu, mais cela ne nous convenait pas. Étant donné que les deux tunnels étaient terminés chez Ali sur un même routeur, nous avons décidé que c'était peut-être un problème régional et qu'il fallait activer la région de secours.

Nous l'avons fait. Les tunnels ont commencé à tomber à des moments différents, mais notre basculement fonctionnait très bien au niveau de l'upstream dans nginx. Mais ensuite, les tunnels ont commencé à tomber à peu près simultanément 🙂 Et les erreurs 502 et 504 ont recommencé. Le temps de disponibilité a commencé à se détériorer, donc nous avons envisagé l'option avec Alibaba CEN (Cloud Enterprise Network).

CEN

CEN — c'est la connectivité de deux VPC de différentes régions à l'intérieur d'Alibaba Cloud, ce qui signifie que vous pouvez connecter des réseaux privés de n'importe quelle région du cloud entre eux. Et ce qui est le plus important : ce canal a des exigences assez strictes SLA. Il est très stable tant en vitesse qu'en disponibilité. Mais rien n'est jamais aussi simple :

• il est TRÈS difficile à obtenir si vous n'êtes pas un citoyen ou une entité juridique chinois(e),
• vous devez payer pour chaque mégabit de capacité de bande passante.

Ayant eu la possibilité de connecter la Chine continentale et à l'étranger, nous avons créé un CEN entre deux régions d'Ali : cn-shenzhen et us-east-1 (le point le plus proche de us-east4). Chez Ali us-east-1 nous avons lancé une autre machine virtuelle, afin d'avoir un autre hop.

Voici ce que ça donne :

Les résultats des tests de navigateur sont ci-dessous :

Solution
Uptime
Médiane
75e percentile
95e percentile

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

Les indicateurs sont un peu meilleurs que ceux d'IPSEC. Mais via IPSEC, il est potentiellement possible de télécharger à une vitesse de 100 Mbit/s, tandis qu'avec CEN, seulement à 5 Mbit/s et c'est plus cher.

On peut envisager un hybride, non ? Combiner la vitesse d'IPSEC et la stabilité de CEN.

Nous avons donc agi ainsi, en laissant passer le trafic à la fois par IPSEC et par CEN en cas de chute du tunnel IPSEC. Le temps de disponibilité est devenu beaucoup plus élevé, mais la vitesse de chargement du site laissait encore à désirer. J'ai alors dessiné tous les schémas que nous avions déjà utilisés et testés, et j'ai décidé d'essayer d'ajouter un peu de GCP, à savoir GLB.

GLB

GLB — ce sont des Global Load Balancer (ou Google Cloud Load Balancer). Il a un avantage important pour nous : dans le contexte du CDN, il possède l'IP anycast, ce qui permet de router le trafic vers le centre de données le plus proche du client, grâce à quoi le trafic entre plus rapidement dans le réseau rapide de Google et circule moins sur l'internet "normal".

Sans trop réfléchir, nous avons mis en place HTTP/HTTPS LB dans GCP, et le backend était constitué de nos machines virtuelles avec subfilter.

Il y avait plusieurs schémas :

• Utiliser Cloudflare China Network, mais cette fois indiquer comme origine le IP GLB.
• Terminer les clients dans cn-shenzhen, puis proxy le trafic directement vers GLB.
• Aller directement de la Chine vers GLB.
• Terminer les clients dans cn-shenzhen, et de là proxy vers asia-east1 via IPSEC (ou us-east4 via CEN), puis aller vers GLB (rassurez-vous, il y aura une image et une explication plus bas)

Nous avons testé toutes ces options et encore quelques hybrides :

• Cloudflare + GLB

Ce schéma ne nous a pas satisfaits en termes de temps de disponibilité et d'erreurs DNS. Mais le test a été effectué avant la correction d'un bug du côté de CF, il est donc possible que cela soit meilleur maintenant (cependant, cela n'exclut pas les timeout HTTP).

• Ali + GLB

Ce schéma ne nous a également pas satisfaits en termes de temps de disponibilité, car GLB tombait souvent du upstream à cause de l'impossibilité de se connecter dans un délai acceptable ou de timeout, car pour le serveur en Chine, l'adresse GLB reste à l'extérieur, ce qui signifie derrière le pare-feu chinois. Il n'y a pas eu de magie.

• GLB only

Une option similaire à la précédente, sauf qu'elle ne comportait pas de serveurs en Chine même : le trafic allait directement vers le GLB (nous avons changé les enregistrements DNS). Par conséquent, les résultats ne nous ont pas satisfaits, car pour les clients chinois ordinaires utilisant des fournisseurs d'accès internet standards, la situation concernant le passage du pare-feu est bien pire que celle d'Ali Cloud.

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

Ici, nous avons décidé d'utiliser le meilleur de toutes les solutions :

• stabilité et SLA garanti de CEN
• haute vitesse d'IPSEC
• le réseau "rapide" de Google et son anycast.

Le schéma ressemble à peu près à ceci : le trafic des utilisateurs est terminé sur une machine virtuelle dans ch-shenzhen. Des upstreams Nginx sont configurés, dont certains pointent vers des serveurs IP privés situés de l'autre côté d'un tunnel IPSEC, tandis qu'une partie des upstreams est dirigée vers des adresses privées de serveurs de l'autre côté du CEN. L'IPSEC a été configuré pour la région asia-east1 dans GCP (c'était la région la plus proche de la Chine au moment de la création de la solution. Maintenant, GCP est également présent à Hong Kong). CEN - pour la région us-east1 dans Ali Cloud.

Ensuite, le trafic des deux extrémités était redirigé vers anycast IP GLB, c'est-à-dire vers le point de présence le plus proche de Google, et passait par ses réseaux vers la région us-east4 dans GCP, où se trouvaient des machines virtuelles de substitution (avec subfilter dans nginx).

Cette solution hybride, comme nous l'avions prévu, a permis de tirer parti des avantages de chaque technologie. En général, le trafic passe par un IPSEC rapide, mais si des problèmes surviennent, nous évacuons rapidement ces serveurs des upstreams pendant quelques minutes et redirigeons le trafic uniquement via le CEN, en attendant que le tunnel se stabilise.

En mettant en œuvre la quatrième solution de la liste ci-dessus, nous avons atteint ce que nous voulions et ce que l'entreprise nous demandait à ce moment-là.

Les résultats des tests de navigateur pour la nouvelle solution comparés aux précédentes :

Solution
Uptime
Médiane
75e percentile
95e percentile

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

Dans la solution que nous avons mise en œuvre, tout fonctionne bien, sauf qu'il n'y a pas de CDN capable d'accélérer le trafic au niveau des régions et même des villes. En théorie, cela devrait accélérer le fonctionnement du site pour les utilisateurs finaux grâce à l'utilisation de canaux rapides du fournisseur de CDN. Et nous y avons constamment pensé. Et maintenant, le moment est venu pour la prochaine itération du projet : rechercher et tester des fournisseurs de CDN en Chine.

Et j'en parlerai dans la prochaine partie, qui sera la dernière 🙂

Source : habr.com