Comment nous avons percé le grand pare-feu chinois (partie 2)

Salut

Nikita est à nouveau avec vous - un ingénieur système de SEMrush . Et avec cet article, je continue l'histoire de la façon dont nous avons trouvé une solution pour contourner le pare-feu chinois pour notre service semrush.com.

Dans la partie précédente, j'ai dit:

• quels problèmes apparaissent après qu'une décision a été prise "Nous devons faire fonctionner notre service en Chine"
• Quels sont les problèmes d'Internet chinois
• pourquoi ai-je besoin d'une licence ICP
• comment et pourquoi nous avons décidé de tester nos bancs d'essai en utilisant le point de capture
• quel a été le résultat de notre première solution basée sur Cloudflare China Network
• comment nous avons trouvé un bogue dans DNS Cloudflare

Cette partie est la plus intéressante, à mon avis, car elle se concentre sur des implémentations techniques spécifiques de la mise en scène. Et nous allons commencer, ou plutôt continuer, avec Alibaba Cloud .

Nuage d'Alibaba

Alibaba Cloud est un fournisseur de cloud assez important, qui possède tous les services qui lui permettent de s'appeler honnêtement un fournisseur de cloud. C'est bien qu'ils aient la possibilité de s'inscrire auprès d'utilisateurs étrangers, et que la plupart du site a été traduit en anglais (pour la Chine c'est un luxe). Dans ce nuage, vous pouvez travailler avec de nombreuses régions du monde, la Chine continentale, ainsi que l'Asie océanique (Hong Kong, Taiwan, etc.).

IPSEC

Commencé par la géographie. Comme notre site de test était situé sur Google Cloud, nous avons dû «lier» Alibaba Cloud à GCP, nous avons donc ouvert une liste des emplacements où Google est présent. À ce moment-là, ils n'avaient pas encore leur propre centre de données à Hong Kong.
La région la plus proche était l' Asie-Est1 (Taïwan). Ali avait cn-shenzhen (Shenzhen) comme région la plus proche de la Chine continentale à Taiwan.

À l'aide de terraform, ils ont décrit et augmenté l'ensemble de l'infrastructure de GCP et Ali. Le tunnel de 100 Mbps entre les nuages ​​s'est élevé presque instantanément. Du côté de Shenzhen et de Taiwan, ils ont créé des machines virtuelles proxy. À Shenzhen, le trafic des utilisateurs est interrompu, acheminé via un tunnel vers Taïwan, et à partir de là, il va directement à l'adresse IP externe de notre service aux États-Unis (côte est des États-Unis). Ping entre les virtuels sur le tunnel de 24 ms , ce qui n'est pas si mal.

Dans le même temps, nous avons placé une zone de test dans Alibaba Cloud DNS . Après avoir délégué la zone à NS Ali, le temps de résolution est passé de 470 ms à 50 ms . Avant cela, la zone était également sur Cloudlfare.

Parallèlement au tunnel vers l' Asie-Est1 , un autre tunnel a été élevé de Shenzhen directement vers nous-Est4 . Là, ils ont créé plus de machines virtuelles proxy et ont commencé à mesurer les deux solutions, en acheminant le trafic de test à l'aide de cookies ou DNS. Le banc d'essai est décrit schématiquement dans la figure suivante:

La latence des tunnels est la suivante:
Ali CN-Shenzhen <--> GCP Asie-Est1 - 24ms
Ali cn-shenzhen <--> GCP us-east4 - 200ms

Les tests du navigateur Catchpoint ont signalé d'excellentes améliorations des performances.

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

Il s'agit des données de la solution utilisant le tunnel IPSEC via asia-east1 . Grâce à us-east4, les résultats étaient pires et il y avait plus d'erreurs, donc je ne donnerai pas les résultats.

Selon les résultats de ce test, deux tunnels, dont l'un est terminé dans la région la plus proche de la Chine, et l'autre à la destination finale, il est devenu clair qu'il est important de «sortir» sous le pare-feu chinois dès que possible, puis d'utiliser des réseaux rapides (fournisseurs CDN) , fournisseurs de cloud, etc.). Pas besoin d'essayer d'un seul coup pour passer par le pare-feu et arriver à destination. Ce n'est pas le moyen le plus rapide.

En général, les résultats ne sont pas mauvais, cependant, semrush.com a une médiane de 8,8 s et 75 centile de 9,4 s (sur le même test).
Et avant de continuer, je voudrais faire une digression.

Digression lyrique

Après que l'utilisateur a visité le site www.semrushchina.cn , qui se résout via les serveurs DNS chinois «rapides», la requête HTTP passe par notre solution rapide. La réponse est renvoyée de la même manière, mais dans tous les scripts JS, pages HTML et autres éléments de la page Web, le domaine semrush.com est indiqué pour les ressources supplémentaires qui doivent être chargées lors du rendu de la page. Autrement dit, le client résout l'enregistrement «principal» A www.semrushchina.c n et se rend dans le tunnel rapide, reçoit rapidement une réponse - une page HTML qui indique:

• téléchargez tel ou tel js sur sso.semrush.com,
• Prenez les fichiers CSS de cdn.semrush.com,
• et prenez plus de photos de dab.semrush.com
• et ainsi de suite.

Le navigateur commence à se rendre sur Internet «externe» pour ces ressources, passant à chaque fois par un pare-feu dévorant le temps de réponse.

Mais dans le test précédent, les résultats sont présentés lorsqu'il n'y a pas de ressources semrush.com sur la page, seul semrushchina.cn et * .semrushchina.cn sont résolus à l'adresse de la machine virtuelle à Shenzhen pour entrer dans le tunnel plus tard.

Ce n'est que de cette façon, en jetant tout le trafic possible à travers votre décision de passer rapidement au maximum le pare-feu chinois, que vous pouvez obtenir des vitesses et des indicateurs de disponibilité du site acceptables, ainsi que des résultats de test honnêtes des solutions.
Nous l'avons fait sans une seule modification de code du côté des produits de l'équipe.

Sous-filtre

La solution est née presque immédiatement après l'apparition de ce problème. Nous avions besoin de PoC (Proof of Concept) pour que nos solutions de pare-feu fonctionnent vraiment bien. Pour ce faire, vous devez maximiser tout le trafic vers le site dans cette solution. Et nous avons appliqué un sous- filtre dans nginx.

Subfilter est un module assez simple dans nginx qui vous permet de changer une ligne dans le corps d'une réponse à une autre ligne. Nous avons donc changé toutes les occurrences de semrush.com en semrushchina.cn dans toutes les réponses.

Et ... cela n'a pas fonctionné, car nous avons reçu du contenu compressé des backends, donc le sous-filtre n'a pas pu trouver la ligne nécessaire. J'ai dû ajouter un autre serveur local à nginx, ce qui a étendu la réponse et l'a transmise au serveur local suivant, qui était déjà engagé dans la substitution, la compression et la livraison de la ligne au prochain proxy de la chaîne.

Par conséquent, lorsque le client recevrait <subdomain> .semrush.com , il recevrait <subdomain> .semrushchina.cn et suivrait docilement notre décision.

Cependant, il ne suffit pas de changer le domaine dans une seule direction, car les backends attendent toujours semrush.com dans les requêtes ultérieures du client. Par conséquent, sur le même serveur où le remplacement est effectué dans une direction, en utilisant une simple expression régulière, nous obtenons le sous-domaine de la demande, puis faisons proxy_pass avec la variable $ host définie dans $ subdomain.semrush.com . Cela peut sembler déroutant, mais cela fonctionne. Et ça marche bien. Pour les domaines individuels qui nécessitent une logique différente, ils créent simplement leurs blocs de serveur et effectuent une configuration distincte. Ci-dessous sont des configurations nginx raccourcies pour la clarté et la démonstration de ce schéma.

La configuration suivante traite toutes les demandes de la Chine à .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; } } 

Cette configuration est dirigée par proxy vers localhost sur le port 83, et là, elle attend la configuration suivante:

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

Encore une fois, ce sont des configurations tronquées.

Quelque chose comme ça. Cela peut sembler compliqué, mais c'est en mots. En fait, tout est plus facile que le navet cuit à la vapeur :)

La fin de la digression lyrique

Pendant un certain temps, nous étions heureux car le mythe de la chute des tunnels IPSEC n'est pas confirmé. Mais alors les tunnels ont commencé à tomber. Plusieurs fois par jour pendant plusieurs minutes. Un peu, mais cela ne nous convenait pas. Étant donné que les deux tunnels ont été terminés du côté Ali sur le même routeur, nous avons décidé qu'il s'agissait peut-être d'un problème régional et que nous devions augmenter la région de sauvegarde.

Ramassé. Les tunnels ont commencé à tomber à différents moments, mais nous avons eu un basculement fin au niveau en amont dans nginx. Mais les tunnels ont commencé à tomber à peu près au même moment :) Et encore, 502 et 504. La disponibilité a commencé à se détériorer, nous avons donc commencé à travailler sur l'option avec Alibaba CEN (Cloud Enterprise Network).

Cen

CEN est la connectivité de deux VPC de différentes régions du cloud d'Alibaba, c'est-à-dire que vous pouvez connecter les réseaux privés de toutes les régions du cloud. Et le plus important: ce canal a un SLA plutôt strict. Il est très stable en vitesse et en disponibilité. Mais ce n'est jamais aussi simple:

• il est TRÈS difficile à obtenir si vous n'êtes pas des citoyens chinois ou des personnes morales,
• vous devez payer pour chaque mégabit de bande passante.

Ayant l'opportunité de connecter la Chine continentale et l' Outre - Mer , 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). Dans Ali us-east-1, ils ont levé une autre machine virtuelle pour avoir un autre saut .

Il s'est avéré comme ceci:

Résultats des tests du navigateur ci-dessous:

Les performances sont légèrement meilleures que IPSEC. Mais via IPSEC, vous pouvez potentiellement télécharger à une vitesse de 100 Mbps, et via CEN uniquement à une vitesse de 5 Mbps et plus cher.

Hybrid supplie, non? Combinez vitesse IPSEC et stabilité CEN.

C'est ce que nous avons fait en laissant le trafic passer par IPSEC et CEN en cas de crash d'un tunnel IPSEC. Le temps de disponibilité est devenu beaucoup plus élevé, mais la vitesse de chargement du site est médiocre. Ensuite, j'ai dessiné tous les schémas que nous avons déjà utilisés et testés, et j'ai décidé d'essayer d'ajouter un peu plus de GCP à ce schéma, à savoir GLB .

GLB

GLB est le Global Load Balancer (ou Google Cloud Load Balancer). Il a un avantage important pour nous: dans le contexte de CDN, il dispose d'une IP anycast , qui vous permet d'acheminer le trafic vers le centre de données le plus proche du client, grâce auquel le trafic arrive plus rapidement et moins sur le réseau rapide de Google via Internet "normal".

Sans y réfléchir à deux fois, nous avons augmenté HTTP / HTTPS LB à GCP et mis nos machines virtuelles avec un backend de sous-filtre.

Il y avait plusieurs régimes:

• Utilisez Cloudflare China Network , mais cette fois l'origine spécifie l' IP GLB globale.
• Terminez les clients dans cn-shenzhen , et à partir de là, le trafic proxy immédiatement vers GLB .
• Allez directement de la Chine au GLB .
• Terminez les clients à CN-Shenzhen , de là proxy à asie-est1 via IPSEC (en us-east4 via CEN), à partir de là allez à GLB (calmement, il y aura une photo et une explication ci-dessous)

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

• Cloudflare + GLB

Ce schéma ne nous convenait pas pour la disponibilité et les erreurs DNS. Mais le test a été effectué avant de corriger le bug de la part de CF, peut-être que maintenant c'est mieux (cependant, cela n'exclut pas les timeouts HTTP).

• Ali + GLB

Ce schéma ne nous convenait pas non plus pour la disponibilité, car GLB a souvent abandonné en amont en raison de l'impossibilité de se connecter à une heure ou un délai acceptable, car pour un serveur en Chine, l'adresse GLB reste à l'extérieur, et donc derrière le pare-feu chinois. La magie n'est pas arrivée.

• GLB uniquement

Une variante similaire à la précédente, mais elle n'utilisait pas de serveurs en Chine même: le trafic passait immédiatement à GLB (enregistrements DNS modifiés). En conséquence, les résultats n'étaient pas satisfaisants, car les clients chinois ordinaires utilisant les services de fournisseurs Internet ordinaires ont une situation bien pire en passant par le pare-feu qu'Ali Cloud.

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

Ici, nous avons décidé d'utiliser la meilleure des solutions:

• stabilité et garantie SLA du CEN
• haute vitesse de IPSEC
• Le réseau «rapide» de Google et son anycast.

Le schéma ressemble à ceci: le trafic utilisateur se termine sur une machine virtuelle à ch-shenzhen . Les paramètres en amont Nginx y sont configurés, dont certains se réfèrent à des serveurs IP privés situés à l'autre extrémité du tunnel IPSEC, et certaines connexions en amont à des adresses de serveurs privés de l'autre côté du CEN. IPSEC a été configuré pour la région Asie-Est1 dans GCP (c'était la région la plus proche de la Chine au moment où la solution a été créée. Maintenant, GCP est également présent à Hong Kong). CEN - dans la région us-east1 d'Ali Cloud.

De plus, le trafic des deux extrémités était dirigé vers anycast IP GLB , c'est-à-dire vers le point de présence de Google le plus proche, et traversait ses réseaux vers la région us-east4 dans GCP, dans laquelle il y avait des machines virtuelles de remplacement (avec sous-filtre dans nginx).

Cette solution hybride, comme nous nous y attendions, nous a permis de profiter de chaque technologie. En général, le trafic passe par IPSEC rapide, mais si des problèmes commencent, nous jetons rapidement et pendant plusieurs minutes ces serveurs en amont et envoyons le trafic via CEN uniquement jusqu'à ce que le tunnel se stabilise.

Après avoir implémenté la 4ème solution de la liste ci-dessus, nous avons réalisé ce que nous voulions et ce que l'entreprise exigeait de nous à l'époque.

Résultats des tests du navigateur pour la nouvelle solution par rapport aux précédents:

Cdn

Tout est bon dans la solution que nous avons mise en place, mais il n'y a pas de CDN qui pourrait accélérer le trafic au niveau des régions et même des villes. En théorie, cela devrait accélérer le site pour les utilisateurs finaux grâce à l'utilisation des canaux de communication rapides du fournisseur CDN. Et nous y pensions tout le temps. Et maintenant, le moment est venu pour la prochaine itération du projet: rechercher et tester les fournisseurs CDN en Chine.

Et je vais vous en parler dans la prochaine partie finale :)

Toutes les pièces

Partie 1
3e partie