Πώς ξεπεράσαμε το Μεγάλο Κινεζικό Τείχος προστασίας (Μέρος 2)

Γεια σας!

Ο Nikita είναι ξανά μαζί σας, μηχανικός συστημάτων από την εταιρεία SEMrush. Και με αυτό το άρθρο συνεχίζω την ιστορία για το πώς καταλήξαμε σε μια λύση λύσης Κινεζικό τείχος προστασίας για την υπηρεσία μας semrush.com.

В προηγούμενο μέρος Είπα:

• ποια προβλήματα προκύπτουν μετά τη λήψη της απόφασης "Πρέπει να κάνουμε την υπηρεσία μας να λειτουργεί στην Κίνα"
• Τι προβλήματα έχει το κινεζικό Διαδίκτυο;
• γιατί χρειάζεστε άδεια ICP;
• πώς και γιατί αποφασίσαμε να δοκιμάσουμε τις δοκιμές μας με το Catchpoint
• ποιο ήταν το αποτέλεσμα της πρώτης μας λύσης που βασίζεται στο Cloudflare China Network
• Πώς βρήκαμε ένα σφάλμα στο Cloudflare DNS

Αυτό το κομμάτι είναι το πιο ενδιαφέρον, κατά τη γνώμη μου, γιατί επικεντρώνεται σε συγκεκριμένες τεχνικές υλοποιήσεις σταδιοποίησης. Και θα ξεκινήσουμε, ή μάλλον θα συνεχίσουμε, με Alibaba Cloud.

Alibaba Cloud

Alibaba Cloud είναι ένας αρκετά μεγάλος πάροχος cloud, ο οποίος διαθέτει όλες τις υπηρεσίες που του επιτρέπουν να αυτοαποκαλείται ειλικρινά πάροχος cloud. Είναι καλό που έχουν την ευκαιρία να εγγραφούν για ξένους χρήστες και ότι το μεγαλύτερο μέρος του ιστότοπου είναι μεταφρασμένο στα αγγλικά (για την Κίνα αυτό είναι πολυτέλεια). Σε αυτό το σύννεφο, μπορείτε να εργαστείτε με πολλές περιοχές του κόσμου, την ηπειρωτική Κίνα, καθώς και την Ωκεάνια Ασία (Χονγκ Κονγκ, Ταϊβάν κ.λπ.).

IPsec

Ξεκινήσαμε με τη γεωγραφία. Δεδομένου ότι ο ιστότοπος δοκιμών μας βρισκόταν στο Google Cloud, έπρεπε να "συνδέσουμε" το Alibaba Cloud με το GCP, επομένως ανοίξαμε μια λίστα με τοποθεσίες στις οποίες είναι παρούσα η Google. Εκείνη τη στιγμή δεν είχαν ακόμη το δικό τους κέντρο δεδομένων στο Χονγκ Κονγκ.
Η πιο κοντινή περιοχή αποδείχθηκε ότι ήταν ασια-ανατολη1 (Ταϊβάν). Ο Αλί αποδείχθηκε ότι ήταν η πλησιέστερη περιοχή της ηπειρωτικής Κίνας στην Ταϊβάν cn-shenzhen (Σεντζέν).

Με τεραφόρμα περιέγραψε και ανέβασε ολόκληρη την υποδομή στο GCP και στο Ali. Μια σήραγγα 100 Mbit/s ανάμεσα στα σύννεφα ανέβηκε σχεδόν αμέσως. Από την πλευρά του Shenzhen και της Ταϊβάν, δημιουργήθηκαν εικονικές μηχανές μεσολάβησης. Στο Shenzhen, η κυκλοφορία των χρηστών τερματίζεται, μέσω μιας σήραγγας στην Ταϊβάν και από εκεί πηγαίνει απευθείας στην εξωτερική IP της υπηρεσίας μας στο ημών-ανατολή (Η.Π.Α. Ανατολική Ακτή). Ping μεταξύ εικονικών μηχανών μέσω σήραγγας 24ms, το οποίο δεν είναι τόσο κακό.

Ταυτόχρονα, τοποθετήσαμε μια περιοχή δοκιμής Alibaba Cloud DNS. Μετά την ανάθεση της ζώνης στο NS Ali, ο χρόνος ανάλυσης μειώθηκε από 470 ms σε ms 50. Πριν από αυτό, η ζώνη ήταν επίσης στο Cloudlfare.

Παράλληλα με τη σήραγγα προς ασια-ανατολη1 σήκωσε μια άλλη σήραγγα από το Shenzhen απευθείας προς ημών-ανατολή4. Εκεί δημιούργησαν περισσότερες εικονικές μηχανές μεσολάβησης και άρχισαν να δοκιμάζουν και τις δύο λύσεις, δρομολογώντας δοκιμαστική κυκλοφορία χρησιμοποιώντας Cookies ή DNS. Ο πάγκος δοκιμής περιγράφεται σχηματικά στο παρακάτω σχήμα:

Η καθυστέρηση για τις σήραγγες αποδείχθηκε ως εξής:
Ali cn-shenzhen <—> GCP asia-east1 — 24ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms

Οι δοκιμές του προγράμματος περιήγησης Catchpoint ανέφεραν εξαιρετική βελτίωση.

Συγκρίνετε τα αποτελέσματα των δοκιμών για δύο λύσεις:

Λύση
Uptime
Διάμεσος
75 εκατοστημόριο
95 εκατοστημόριο

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

Αυτά είναι δεδομένα από μια λύση που χρησιμοποιεί μια σήραγγα IPSEC μέσω ασια-ανατολη1. Μέσω us-east4 τα αποτελέσματα ήταν χειρότερα και υπήρχαν περισσότερα σφάλματα, επομένως δεν θα δώσω τα αποτελέσματα.

Με βάση τα αποτελέσματα αυτής της δοκιμής δύο τούνελ, η μία από τις οποίες τερματίζει στην πλησιέστερη περιοχή στην Κίνα και η άλλη στον τελικό προορισμό, κατέστη σαφές ότι είναι σημαντικό να «βγείτε» κάτω από το κινεζικό τείχος προστασίας το συντομότερο δυνατό. είναι δυνατό και, στη συνέχεια, χρησιμοποιήστε γρήγορα δίκτυα (παρόχους CDN, πάροχοι cloud, κ.λπ.). Δεν χρειάζεται να προσπαθήσετε να περάσετε μέσα από το τείχος προστασίας και να φτάσετε στον προορισμό σας με μια πτώση. Αυτός δεν είναι ο πιο γρήγορος τρόπος.

Γενικά, τα αποτελέσματα δεν είναι άσχημα, ωστόσο, το semrush.com έχει διάμεσο 8.8 δευτ. και 75 εκατοστιαίες μονάδες 9.4 (στην ίδια δοκιμή).
Και πριν προχωρήσω, θα ήθελα να κάνω μια μικρή λυρική παρέκβαση.

Λυρική παρέκβαση

Μετά την είσοδο του χρήστη στον ιστότοπο www.semrushchina.cn, το οποίο επιλύεται μέσω "γρήγορων" κινεζικών διακομιστών DNS, το αίτημα HTTP περνά από τη γρήγορη λύση μας. Η απάντηση επιστρέφεται στην ίδια διαδρομή, αλλά ο τομέας καθορίζεται σε όλα τα σενάρια JS, τις σελίδες HTML και άλλα στοιχεία της ιστοσελίδας semrush.com για πρόσθετους πόρους που πρέπει να φορτωθούν κατά την απόδοση της σελίδας. Δηλαδή, ο πελάτης επιλύει την «κύρια» εγγραφή Α www.semrushchina.cn και πηγαίνει στο γρήγορο τούνελ, λαμβάνει γρήγορα μια απάντηση - μια σελίδα HTML που δηλώνει:

• κατεβάστε τέτοια και τέτοια js από το sso.semrush.com,
• Λάβετε τα αρχεία CSS από το cdn.semrush.com,
• και επίσης τραβήξτε μερικές φωτογραφίες από το dab.semrush.com
• και ούτω καθεξής.

Το πρόγραμμα περιήγησης αρχίζει να πηγαίνει στο «εξωτερικό» Διαδίκτυο για αυτούς τους πόρους, κάθε φορά που περνά μέσα από ένα τείχος προστασίας που καταναλώνει χρόνο απόκρισης.

Αλλά η προηγούμενη δοκιμή δείχνει τα αποτελέσματα όταν δεν υπάρχουν πόροι στη σελίδα semrush.comμόνο semrushchina.cn, και το *.semrushchina.cn επιλύει στη διεύθυνση της εικονικής μηχανής στο Shenzhen για να μπει στη σήραγγα.

Μόνο με αυτόν τον τρόπο, ωθώντας στο μέγιστο όλη την πιθανή επισκεψιμότητα μέσω της λύσης σας για γρήγορη μετάβαση του κινεζικού τείχους προστασίας, μπορείτε να αποκτήσετε αποδεκτές ταχύτητες και δείκτες διαθεσιμότητας ιστότοπου, καθώς και ειλικρινή αποτελέσματα δοκιμών λύσεων.
Το κάναμε αυτό χωρίς ούτε μία τροποποίηση κώδικα από την πλευρά των προϊόντων της ομάδας.

Υποφίλτρο

Η λύση γεννήθηκε σχεδόν αμέσως μετά την εμφάνιση αυτού του προβλήματος. Χρειαζόμασταν PoC (Proof of Concept) ότι οι λύσεις διείσδυσης τείχους προστασίας μας λειτουργούν πραγματικά καλά. Για να γίνει αυτό, πρέπει να τυλίξετε όλη την επισκεψιμότητα του ιστότοπου σε αυτήν τη λύση όσο το δυνατόν περισσότερο. Και υποβάλαμε αίτηση υποφίλτρο στο nginx.

Υποφίλτρο είναι μια αρκετά απλή ενότητα στο nginx που σας επιτρέπει να αλλάξετε μια γραμμή στο σώμα απόκρισης σε μια άλλη γραμμή. Έτσι αλλάξαμε όλα τα φαινόμενα semrush.com επί semrushchina.cn σε όλες τις απαντήσεις.

Και... δεν λειτούργησε επειδή λάβαμε συμπιεσμένο περιεχόμενο από τα backend, οπότε το υποφίλτρο δεν βρήκε την απαιτούμενη γραμμή. Έπρεπε να προσθέσω έναν άλλο τοπικό διακομιστή στο nginx, ο οποίος αποσυμπίεσε την απόκριση και τη μεταβίβασε στον επόμενο τοπικό διακομιστή, ο οποίος ήταν ήδη απασχολημένος με την αντικατάσταση της συμβολοσειράς, τη συμπίεση και την αποστολή της στον επόμενο διακομιστή μεσολάβησης στην αλυσίδα.

Ως αποτέλεσμα, πού θα λάμβανε ο πελάτης .semrush.com, Ελαβε .semrushchina.cn και υπάκουα ακολούθησε την απόφασή μας.

Ωστόσο, δεν αρκεί απλώς να αλλάξετε τον τομέα με έναν τρόπο, επειδή τα backend εξακολουθούν να περιμένουν το semrush.com σε επόμενα αιτήματα από τον πελάτη. Αντίστοιχα, στον ίδιο διακομιστή όπου γίνεται η μονόδρομη αντικατάσταση, χρησιμοποιώντας μια απλή τυπική έκφραση παίρνουμε τον υποτομέα από το αίτημα και μετά κάνουμε διακομιστής μεσολάβησης με μεταβλητή $host, που εκτίθεται σε $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;
    }
}

Αυτή η διαμόρφωση γίνεται μεσολάβηση σε localhost στη θύρα 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 στον ίδιο δρομολογητή, αποφασίσαμε ότι ίσως αυτό ήταν ένα περιφερειακό πρόβλημα και έπρεπε να αυξήσουμε την περιοχή αντιγράφων ασφαλείας.

Το σήκωσαν. Τα τούνελ άρχισαν να αποτυγχάνουν σε διαφορετικές χρονικές στιγμές, αλλά το failover λειτούργησε καλά για εμάς στο upstream επίπεδο στο nginx. Αλλά μετά οι σήραγγες άρχισαν να πέφτουν περίπου την ίδια ώρα 🙂 Και άρχισαν ξανά τα 502 και 504. Ο χρόνος λειτουργίας άρχισε να επιδεινώνεται, οπότε αρχίσαμε να εργαζόμαστε για την επιλογή με Alibaba CEN (Cloud Enterprise Network).

CEN

CEN - αυτή είναι η συνδεσιμότητα δύο VPC από διαφορετικές περιοχές στο Alibaba Cloud, δηλαδή, μπορείτε να συνδέσετε ιδιωτικά δίκτυα οποιωνδήποτε περιοχών εντός του νέφους μεταξύ τους. Και το πιο σημαντικό: αυτό το κανάλι έχει μια αρκετά αυστηρή SLA. Είναι πολύ σταθερό τόσο σε ταχύτητα όσο και σε χρόνο λειτουργίας. Αλλά ποτέ δεν είναι τόσο απλό:

• είναι πολύ δύσκολο να το αποκτήσετε εάν δεν είστε Κινέζοι πολίτες ή νομική οντότητα,
• Πρέπει να πληρώσετε για κάθε megabit εύρους ζώνης καναλιού.

Έχοντας την ευκαιρία να συνδεθείτε ηπειρωτική Κίνα и Υπερπόντιος, δημιουργήσαμε ένα CEN μεταξύ δύο περιοχών Ali: cn-shenzhen и ΗΠΑ-ανατολή-1 (πλησιέστερο σημείο σε εμάς-ανατολή4). Στον Αλί ΗΠΑ-ανατολή-1 ανέβασε μια άλλη εικονική μηχανή, ώστε να υπάρχει μια ακόμη λυκίσκος.

Αποδείχθηκε έτσι:

Τα αποτελέσματα των δοκιμών του προγράμματος περιήγησης είναι τα παρακάτω:

Λύση
Uptime
Διάμεσος
75 εκατοστημόριο
95 εκατοστημόριο

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

Η απόδοση είναι ελαφρώς καλύτερη από το IPSEC. Αλλά μέσω του IPSEC μπορείτε ενδεχομένως να κάνετε λήψη με ταχύτητα 100 Mbit/s και μέσω CEN μόνο με ταχύτητα 5 Mbit/s και άνω.

Ακούγεται σαν υβρίδιο, σωστά; Συνδυάστε ταχύτητα IPSEC και σταθερότητα CEN.

Αυτό κάναμε, επιτρέποντας την κυκλοφορία τόσο μέσω IPSEC όσο και CEN σε περίπτωση βλάβης της σήραγγας IPSEC. Ο χρόνος λειτουργίας έχει γίνει πολύ υψηλότερος, αλλά η ταχύτητα φόρτωσης του ιστότοπου εξακολουθεί να αφήνει πολλά να είναι επιθυμητά. Στη συνέχεια σχεδίασα όλα τα κυκλώματα που είχαμε ήδη χρησιμοποιήσει και δοκιμάσει, και αποφάσισα να προσπαθήσω να προσθέσω λίγο περισσότερο GCP σε αυτό το κύκλωμα, δηλαδή καπάκι.

καπάκι

καπάκι - Είναι Global Load Balancer (ή Google Cloud Load Balancer). Έχει ένα σημαντικό πλεονέκτημα για εμάς: στο πλαίσιο ενός CDN έχει anycast IP, το οποίο σας επιτρέπει να δρομολογείτε την επισκεψιμότητα στο κέντρο δεδομένων που βρίσκεται πιο κοντά στον πελάτη, έτσι ώστε η κίνηση να εισέρχεται γρήγορα στο γρήγορο δίκτυο της Google και να περνά λιγότερο από το «κανονικό» Διαδίκτυο.

Χωρίς να το σκεφτούμε δύο φορές, μεγαλώσαμε HTTP/HTTPS LB Εγκαταστήσαμε τις εικονικές μας μηχανές με υποφίλτρο στο GCP και ως backend.

Υπήρχαν πολλά σχήματα:

• Χρήση Cloudflare China Network, αλλά αυτή τη φορά το Origin θα πρέπει να καθορίσει το καθολικό IP GLB.
• Τερματισμός πελατών στο cn-shenzhen, και από εκεί μεσολάβησε την κίνηση απευθείας στο καπάκι.
• Πηγαίνετε κατευθείαν από την Κίνα προς καπάκι.
• Τερματισμός πελατών στο cn-shenzhen, από εκεί πληρεξούσιος προς ασια-ανατολη1 μέσω IPSEC (σε ημών-ανατολή4 μέσω CEN), από εκεί πηγαίνετε στο GLB (ήρεμα, θα υπάρχει εικόνα και επεξήγηση παρακάτω)

Δοκιμάσαμε όλες αυτές τις επιλογές και αρκετές ακόμη υβριδικές:

• Cloudflare + GLB

Αυτό το σχήμα δεν μας ταιριάζει λόγω σφαλμάτων χρόνου λειτουργίας και DNS. Αλλά η δοκιμή πραγματοποιήθηκε πριν επιδιορθωθεί το σφάλμα στην πλευρά της CF, ίσως είναι καλύτερα τώρα (ωστόσο, αυτό δεν αποκλείει τα χρονικά όρια HTTP).

• Ali + GLB

Αυτό το σχήμα δεν μας ταίριαζε επίσης όσον αφορά το χρόνο λειτουργίας, καθώς το GLB συχνά έπεφτε εκτός ροής λόγω της αδυναμίας σύνδεσης σε αποδεκτό χρόνο ή χρονικό όριο, επειδή για έναν διακομιστή εντός Κίνας, η διεύθυνση GLB παραμένει εκτός και επομένως πίσω από το Κινεζικό τείχος προστασίας. Η μαγεία δεν έγινε.

• Μόνο GLB

Μια επιλογή παρόμοια με την προηγούμενη, μόνο που δεν χρησιμοποιούσε διακομιστές στην ίδια την Κίνα: η κίνηση πήγε απευθείας στο GLB (οι εγγραφές DNS άλλαξαν). Συνεπώς, τα αποτελέσματα δεν ήταν ικανοποιητικά, καθώς οι απλοί Κινέζοι πελάτες που χρησιμοποιούν τις υπηρεσίες κοινών παρόχων Διαδικτύου έχουν πολύ χειρότερη κατάσταση με το πέρασμα του τείχους προστασίας από το Ali Cloud.

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

Εδώ αποφασίσαμε να χρησιμοποιήσουμε την καλύτερη από όλες τις λύσεις:

• σταθερότητα και εγγυημένο SLA από την CEN
• υψηλή ταχύτητα από το IPSEC
• Το «γρήγορο» δίκτυο της Google και το anycast του.

Το σχήμα μοιάζει κάπως έτσι: η κυκλοφορία των χρηστών τερματίζεται σε μια εικονική μηχανή στο ch-shenzhen. Οι παράμετροι Nginx έχουν ρυθμιστεί εκεί, ορισμένοι από τους οποίους οδηγούν σε ιδιωτικούς διακομιστές IP που βρίσκονται στο άλλο άκρο της σήραγγας IPSEC και ορισμένες ανοδικές διευθύνσεις οδηγούν σε ιδιωτικές διευθύνσεις διακομιστών στην άλλη πλευρά του CEN. Το IPSEC έχει ρυθμιστεί στην περιοχή ασια-ανατολη1 στο GCP (ήταν η πλησιέστερη περιοχή στην Κίνα τη στιγμή που δημιουργήθηκε η λύση. Το GCP έχει πλέον παρουσία και στο Χονγκ Κονγκ). CEN - στην περιοχή ημών-ανατολή1 στο Ali Cloud.

Στη συνέχεια η κυκλοφορία και από τις δύο άκρες κατευθύνθηκε προς anycast IP GLB, δηλαδή στο πλησιέστερο σημείο παρουσίας της Google, και πέρασε μέσω των δικτύων της στην περιοχή ημών-ανατολή4 στο GCP, στο οποίο υπήρχαν εικονικές μηχανές αντικατάστασης (με υποφίλτρο στο nginx).

Αυτή η υβριδική λύση, όπως περιμέναμε, εκμεταλλεύτηκε τα οφέλη της κάθε τεχνολογίας. Γενικά, η κίνηση περνάει γρήγορα μέσω IPSEC, αλλά αν ξεκινήσουν προβλήματα, γρήγορα και για λίγα λεπτά κλωτσάμε αυτούς τους διακομιστές από το upstream και στέλνουμε κίνηση μόνο μέσω CEN μέχρι να σταθεροποιηθεί η σήραγγα.

Εφαρμόζοντας τη λύση 4 από την παραπάνω λίστα, πετύχαμε αυτό που θέλαμε και αυτό που απαιτούσε η επιχείρηση από εμάς εκείνη τη στιγμή.

Αποτελέσματα δοκιμής προγράμματος περιήγησης για τη νέα λύση σε σύγκριση με προηγούμενες:

Λύση
Uptime
Διάμεσος
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 στην Κίνα.

Και θα σας πω για αυτό στο επόμενο, τελευταίο μέρος :)

Πηγή: www.habr.com