🥇 ہم نے چین کے عظیم فائر وال کو کیسے توڑا (حصہ 1)

ہر کسی کو خوش!

نکیتا رابطے میں ہے - کمپنی سے سسٹم انجینئر SEMrush. آج میں آپ کو بتاؤں گا کہ ہم نے چین میں اپنی semrush.com سروس کے استحکام کو یقینی بنانے کے کام کا کیسے سامنا کیا، اور اس کے نفاذ کے دوران ہمیں کن مسائل کا سامنا کرنا پڑا (امریکہ کے مشرقی ساحل پر ہمارے ڈیٹا سینٹر کے مقام کو دیکھتے ہوئے)۔

یہ ایک بڑی کہانی ہوگی جسے کئی مضامین میں تقسیم کیا گیا ہے۔ میں آپ کو بتاؤں گا کہ یہ سب ہمارے لیے کیسے ہوا: چین سے مکمل طور پر غیر فعال سروس سے لے کر امریکیوں کے لیے اس کے امریکی ورژن کی سطح پر سروس کے کارکردگی کے اشارے تک۔ میں وعدہ کرتا ہوں کہ یہ دلچسپ اور مفید ہوگا۔ تو، چلتے ہیں.

چینی انٹرنیٹ کے مسائل

یہاں تک کہ نیٹ ورک انتظامیہ کی تفصیلات سے سب سے دور شخص نے سنا ہے۔ چین کا عظیم فائر وال. واہ، اچھا لگتا ہے، ٹھیک ہے؟ لیکن یہ کیا ہے اور یہ اصل میں کیسے کام کرتا ہے ایک پیچیدہ سوال ہے۔ آپ کو انٹرنیٹ پر بہت سے مضامین مل سکتے ہیں جو اس کے لیے وقف ہیں، لیکن تکنیکی نقطہ نظر سے، اس فائر وال کی ساخت کہیں بھی بیان نہیں کی گئی ہے۔ جو کہ بہرحال حیران کن نہیں ہے۔ میں ابھی تسلیم کروں گا کہ ایک سال کے کام کے نتائج کی بنیاد پر، میں یہ نہیں کہہ سکوں گا کہ یہ کیسے کام کرتا ہے، لیکن میں آپ کو اپنے تبصروں اور عملی نتائج کے بارے میں بتا سکتا ہوں۔ اور ہم اس فائر وال کے بارے میں افواہوں کے ساتھ شروع کریں گے۔

اس فائر وال کے بارے میں بہت سی افواہیں ہیں۔ آئیے ان میں سے اہم اور سب سے دلچسپ کو ایک فہرست میں جمع کرتے ہیں:

گوگل، فیس بک، ٹویٹر اور اسی طرح کی دیگر سروسز بلاک ہیں اور چین میں کام نہیں کرتی ہیں۔
چین سے باہر اور چین کے اندر جانے والی کسی بھی ٹریفک کو مشین لرننگ (مشکوک ٹریفک کی صورت میں) کا استعمال کرتے ہوئے پارس اور محدود کیا جاتا ہے، جو سرحد سے گزرنے والی ٹریفک (ٹریفک) کو بہت سست کر دیتا ہے۔
چینی انٹیلی جنس ایجنسیاں اپنی فائر وال سے گزرنے والی کسی بھی انکرپٹڈ ٹریفک کو ہیک کر لیں گی۔
وی پی این سرنگیں، آئی پی ایس ای سی سرنگیں غیر مستحکم، کریش اور مسلسل بلاک ہیں۔
انکرپشن جتنا آسان ہوگا، ٹریفک کی توثیق/انکرپٹ کرنے کے لیے پاس کا جملہ استعمال کیا جائے گا، یہ چینی فائر وال سے اتنی ہی تیزی سے گزرے گا۔

ان افواہوں کے بارے میں ہمیں جو کچھ معلوم ہوا وہ یہ ہے:

گوگل، فیس بک، ٹویٹر اور دیگر اسی طرح کی خدمات بے شک بلاک ہیں (آپ کے کو)، لیکن بہت سے تکنیکی گوگل ڈومینز، مثال کے طور پر، ممنوع نہیں ہیں اور کام کرتے ہیں (وہی gstatic.com)۔ اس سے نتیجہ یہ نکلتا ہے: آپ کو لاپرواہی سے ان تمام گوگل اور دیگر وسائل کو نہیں کاٹنا چاہیے جو بظاہر بلاک ہیں۔
سرحد سے گزرنے والی کوئی بھی ٹریفک واقعی اپنے وقت میں شدید تاخیر کا باعث بنتی ہے۔ دو نتائج دیکھیں۔ ایک سائٹ، ایک صفحہ، سادہ GET curl کےاوم پہلی پیمائش خود چین سے کی گئی تھی (شینزین کا خوبصورت شہر)۔ دوسرے کو ہانگ کانگ سے باہر سے ماپا گیا تھا (اس کی خودمختاری ہے، اور اس کے اور دنیا کے درمیان کوئی فائر وال نہیں ہے)۔ سیدھی لائن میں شہروں کے درمیان فاصلہ تقریباً 30-40 کلومیٹر ہے۔

nikita@china-shenzhen:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  381k    0  381k    0     0  71824      0 --:--:--  0:00:05 --:--:-- 82832
time_namelookup:  0.004500
time_connect:  0.169342
time_appconnect:  0.723189
time_pretransfer:  0.723499
time_redirect:  0.000000
time_starttransfer:  1.532912
----------
time_total:  5.443407
----------
size_download:  390968 Bytes
speed_download:  71824.000B/s

nikita@china-hongkong:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  319k    0  319k    0     0  2555k      0 --:--:-- --:--:-- --:--:-- 2573k
time_namelookup:  0.029366
time_connect:  0.030742
time_appconnect:  0.047310
time_pretransfer:  0.047388
time_redirect:  0.000000
time_starttransfer:  0.120793
----------
time_total:  0.124871
----------
size_download:  326755 Bytes
speed_download:  2616740.000B/s

پر دھیان دیں time_connect. اور عام طور پر، آپ کو نتیجہ نظر آتا ہے: فائر وال میں 4 اضافی سیکنڈز کا اضافہ ہوتا ہے، جو کہ بہت طویل ہے۔

VPN اور IPSEC سرنگیں اکثر ناکام ہو جاتی ہیں۔ میں اس کے بارے میں تھوڑی دیر بعد اور مزید تفصیل سے بات کروں گا۔ VPN سرورز جو صارفین استعمال کرتے ہیں وقت کے ساتھ بلاک ہو جاتے ہیں (عام طور پر استعمال شروع ہونے کے بعد ایک دن کے اندر)۔
چین میں رہنے والے لوگوں کی طرف سے ایک رائے موصول ہوئی ہے کہ ٹریفک کی انکرپشن جتنی آسان ہوگی، اتنی ہی تیزی سے یہ سرحد سے گزرتی ہے، کیونکہ یہ سمجھنا آسان ہے کہ اس میں کوئی غیر قانونی بات نہیں ہے۔ اور اسی طرح، "صاف" ٹریفک زیادہ بینڈوڈتھ اور گزرنے کی رفتار حاصل کرتی ہے، جب کہ "گندی" ٹریفک، جس میں کچھ بھی پارس نہیں کیا جا سکتا، اس کے برعکس، ایک سست راستہ حاصل کرتا ہے۔ مثال کے طور پر میں curl to استعمال کروں گا۔ ifconfig.co HTTPS اور HTTP پروٹوکول کے ذریعے۔

curl -o /dev/null -w@curl_time "https://ifconfig.co/"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    13  100    13    0     0      2      0  0:00:06  0:00:05  0:00:01     3
time_namelookup:  0.004305
time_connect:  0.397465
time_appconnect:  5.149305
time_pretransfer:  5.149393
time_redirect:  0.000000
time_starttransfer:  5.568847
----------
time_total:  5.568893
----------
size_download:  13 Bytes
speed_download:  2.000B/s

curl -o /dev/null -w@curl_time "http://ifconfig.co/"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    13  100    13    0     0     28      0 --:--:-- --:--:-- --:--:--    28
time_namelookup:  0.004282
time_connect:  0.212457
time_appconnect:  0.000000
time_pretransfer:  0.212484
time_redirect:  0.000000
time_starttransfer:  0.450565
----------
time_total:  0.450620
----------
size_download:  13 Bytes
speed_download:  28.000B/s

5 بائٹس کے کل ڈاؤن لوڈ وقت کے لیے 13 سیکنڈ کا فرق۔ مزید برآں، اس طرح کا ٹیسٹ کئی بار کرتے وقت، آپ دیکھ سکتے ہیں کہ HTTP پر GET عام طور پر ہر بار ایک ہی وقت میں مکمل ہوتا ہے، جبکہ HTTPS پر سائٹ بعض اوقات 3، 5، 10 اور یہاں تک کہ 17 سیکنڈ میں جواب دیتی ہے۔ کبھی کبھی SSL کی خرابیاں ہوتی ہیں:

Unknown SSL protocol error in connection to ifconfig.co:443.

تو ہمارے پاس کیا ہے:

چینی فائر وال کے ذریعہ پیدا ہونے والے مسائل اوپر بیان کیے گئے ہیں۔
بیرونی وسائل اور اندر کی سرنگوں کے پنگ وقفے وقفے سے غائب ہو جاتے ہیں۔
دو پوائنٹس کے درمیان تاخیر مسلسل تبدیل ہوتی رہتی ہے، اور اکثر یہ محض غیر متوقع ہوتا ہے۔ مختلف شہروں/علاقوں کو جوڑتے وقت، آپ توقع کرتے ہیں کہ، علاقوں کے جغرافیائی محل وقوع کی بنیاد پر، تاخیر کم ہوگی، لیکن آپ کو بالکل برعکس صورت حال ملتی ہے۔
انٹرنیٹ اور مواصلاتی ذرائع یا تو تیز ہیں یا سست ہیں۔ ہفتے کے دن اور دن کے وقت پر تھوڑا سا انحصار ہے، لیکن ہمیشہ نہیں.
چین سے بیرونی دنیا کو ڈی این ایس کی درخواستیں بعض اوقات اجازت شدہ ٹائم آؤٹ سے تجاوز کر جاتی ہیں۔

ابھرنے والی تصویر صرف "بہترین" ہے۔

ڈیٹا سینٹر، جیسا کہ میں پہلے ہی کہہ چکا ہوں، مشرقی ریاستہائے متحدہ میں ہے، اور پورا SEMrush درجنوں ایک دوسرے سے منسلک مصنوعات، بیک اینڈ، فرنٹ اینڈ، ڈیٹا بیس، اور یہ سب DC اور بادلوں پر مشتمل ہے۔ ہمیں، سسٹم ایڈمنسٹریٹرز کی ایک ٹیم کے طور پر، تھوڑی محنت کے ساتھ چین میں تیزی سے کام شروع کرنے کا ٹاسک دیا گیا تھا۔

ہمیں ایک اہم سوال کا جواب دینا تھا: کیا یہ ممکن ہے کہ تھوڑے سے اخراجات سے گزرنا اور نیٹ ورک/کلاؤڈ/سرور کی سطح پر چینی انٹرنیٹ اور فائر وال سے جڑے تمام مسائل کو حل کرنا ممکن ہے؟

ہم نے وصول کرکے شروع کیا۔ آئی سی پی۔-لائسنس.

ICP لائسنس

چین (مین لینڈ چائنا) میں اپنی سروس کی میزبانی کرنے اور ٹیسٹ کروانے کے لیے، آپ کو پہلے ڈومین کے لیے ICP لائسنس حاصل کرنا ہوگا۔

اگر آپ کی سائٹ کا صارف ٹریفک مین لینڈ چائنا میں ختم کر دیا جاتا ہے، اور اگر آپ کے ڈومین کے پاس ICP لائسنس نہیں ہے، تو آپ کا ٹریفک ISP/ہوسٹنگ سائیڈ پر بلاک کر دیا جائے گا۔ دلچسپ بات یہ ہے کہ ICP لائسنس میں ایک مخصوص فراہم کنندہ شامل ہے، چاہے وہ Cloudflare ہو یا Alibaba Cloud۔ لہذا، اگر آپ نے Cloudflare کے لیے ICP لائسنس حاصل کیا ہے اور ان کے ساتھ اپنی ویب سائٹ کی میزبانی کی ہے، تو آپ علی بابا کلاؤڈ پر "بغیر کسی رکاوٹ" منتقل نہیں ہو پائیں گے۔ آپ کو اس لائسنس میں ایک اور ہوسٹنگ شامل کرنے کی ضرورت ہوگی۔

ڈومین کے لیے ICP لائسنس حاصل کرنے کے بعد، ہم مخصوص تکنیکی نظریات اور حل کے ساتھ آنے اور ان پر عمل درآمد کرنے کے قابل ہو گئے۔

جانچ کے حل

لیکن اس سے پہلے کہ آپ براہ راست اسٹیجنگ کے اختیارات بنائیں، نوبس کو موڑیں، سائٹ کی کارکردگی اور اس کی رفتار کو بہتر بنائیں، آپ کو اس کی جانچ کے لیے ایک ٹول کا انتخاب کرنا ہوگا تاکہ یہ معلوم ہوسکے کہ ہمارے کون سے اعمال میں بہتری آتی ہے یا اس کے برعکس، سائٹ کی کارکردگی خراب ہوتی ہے۔

ہمارے ٹیسٹنگ ٹول کو دو اہم ضروریات کو پورا کرنا تھا:

اسے چین سے ٹیسٹ چلانے کے قابل ہونا چاہیے،
اس میں براؤزر ٹیسٹ ہونا ضروری ہے۔

تو ہم نے پایا پکچ پوائنٹ! ان کے پاس دنیا بھر میں جانچ کے مقامات کی بہترین کوریج ہے۔ چین میں اس ٹول کے ذریعے 100500 صوبوں سے بھی ٹیسٹ چلائے جاسکتے ہیں۔ ہر ایک کے پاس کئی مختلف فراہم کنندگان + کرنے کی صلاحیت ہے۔ ریڑھ کی ہڈیٹیسٹ (ڈیٹا سینٹر میں ورچوئل مشین کی طرح کچھ) اور آخری-ٹیسٹ (صارف کے حالات کے جتنا قریب ہو، عرف ورک سٹیشن)۔ آخری قسم کے ٹیسٹ زیادہ مہنگے ہیں۔

ایک سالانہ معاہدہ کرنے کے بعد (کم ممکن نہیں)، ہم نے آلے کا مطالعہ شروع کیا۔ سچ کہوں تو ہمیں اس کی فعالیت سے خوشگوار حیرت ہوئی۔ آپ چلا سکتے ہیں:

DNS ٹیسٹ،
ویب ٹیسٹ (براؤزر ٹیسٹ، سادہ GET/POST، موبائل کلائنٹ ایمولیشن، وغیرہ)،
لین دین کے چیک (مثال کے طور پر لاگ ان)
API ٹیسٹ،
پنگ، ٹریسروٹ، این ٹی پی، وغیرہ۔

آپ ہر چیز کی فہرست نہیں بنا سکتے۔ اور سب سے اہم بات یہ ہے کہ ہر ٹیسٹ کو ہیڈر اور دیگر پیرامیٹرز کا ایک گروپ شامل کرکے کافی اچھی طرح سے اپنی مرضی کے مطابق بنایا جاسکتا ہے۔ آؤٹ پٹ معلومات کی ایک بڑی مقدار ہے جو آپ کے ٹیسٹ کو مکمل طور پر بیان کرتی ہے۔ اگر ہم اپنے لیے سب سے دلچسپ چیزوں کے بارے میں بات کرتے ہیں (براؤزر ٹیسٹ)، تو نتیجہ میں شامل ہیں:

جڑیں، انتظار کریں، لوڈ کریں، SSL، DNS وقت،
TTFB، TTLB، دستاویز مکمل، رینڈر کا وقت، DOM لوڈ،
رسپانس (کوئی چیز جو ٹائم ٹو فرسٹ بائٹ کے قریب ہے)، ویب پیج رسپانس (وقت سے آخری بائٹ کے قریب کوئی چیز)
کوئی بھی فیصد، اوسط، درمیانی وقت
وغیرہ

اس کے مطابق، یہ تمام میٹرکس تبدیلیوں کو دیکھنے اور یہ سمجھنے کے لیے بہترین ہیں کہ آیا چیزیں بہتر ہوئی ہیں۔ ہم نے بنیادی طور پر دیکھا جواب، ویب پیج رسپانس، میڈین، 75 اور 95 فیصد.

ایک اہم سوال جو شروع سے ہی ہوا میں تھا: کیا آپ کیچ پوائنٹ پر بھروسہ کر سکتے ہیں؟? کیا یہ ٹول چین میں مختلف شہروں سے حقیقی سائٹ کی لوڈنگ کی رفتار کو ظاہر کرتا ہے، یا یہ صرف خلا میں کسی قسم کا ٹیسٹ ہے جس کا صارف کے حقیقی تجربے سے کوئی تعلق نہیں ہے؟
یہ ایک بڑا مسئلہ ہے، کیونکہ روس میں ہونے کی وجہ سے یہ جاننا تقریباً ناممکن ہے کہ چین کی کوئی سائٹ کیسے کام کرتی ہے۔ ورچوئل مشین کے ذریعے جرابوں پراکسی کرنے سے، حتمی نتیجہ یہ نکلتا ہے کہ سائٹ چند منٹوں میں لوڈ ہو جاتی ہے، جو کہ ٹیسٹ کے لیے ناقابل قبول ہے، اس لیے دستی ٹیسٹنگ کے لیے واحد آپشن ہے کرل اور ٹائمر کے ساتھ کنسول سے سادہ GET۔ . اس سے مدد ملتی ہے کیونکہ یہ ٹیسٹ نیٹ ورک حل کی رفتار کو اچھی طرح سے ظاہر کرتا ہے، اور اگر براؤزر کے ٹیسٹ بھی ہیں، تو یہ بہت اچھا ہے۔

بعد میں ہم خود چین گئے اور اس بات کے قائل ہوئے۔ آپ کیچ پوائنٹ پر بھروسہ کر سکتے ہیں؛ یہ بالکل درست کارکردگی کے اشارے کی عکاسی کرتا ہے۔

Cloudflare چائنا نیٹ ورک

چونکہ ہم نے Cloudflare کو مرکزی ڈومین semrush.com کے لیے کامیابی کے ساتھ استعمال کیا، اس لیے ہم نے فوری طور پر ان کی خصوصیت کو آزمانے کا فیصلہ کیا۔ چائنا نیٹ ورک. یہ اختیار صرف انٹرپرائز سائٹس کے لیے علیحدہ درخواست پر اور اضافی فیس کے لیے فعال ہے۔ یہ صرف ان سائٹس کے لیے دستیاب ہے جن کے پاس مناسب ICP لائسنس ہے جو Cloudflare کو فراہم کنندہ کے طور پر درج کرتا ہے۔ اسے فعال کرنے کے بعد، Cloudflare سے "چینی CDN" سائٹ کے لیے دستیاب ہو جاتا ہے - چینی علاقوں سے ٹریفک قریب ترین PoP (Points of Presence) CF پر پہنچتا ہے، اور پھر اس کے نیٹ ورکس یا فراہم کنندگان/پارٹنرز کے نیٹ ورکس کے ذریعے اسے اصل مقام تک پہنچایا جاتا ہے۔ .

اس ٹیسٹ بینچ کا خاکہ ذیل میں پیش کیا گیا ہے۔

یہ ہمارے لیے ایک بہترین آپشن ہے۔ یہ پتہ چلتا ہے کہ دوسرا ڈومین بھی CF کے لئے ہو گا، جو کمپنی میں استعمال ہونے والے حل کی تعداد میں اضافہ نہیں کرتا، اور عملی طور پر بنیادی ڈھانچے کو پیچیدہ نہیں کرتا.

ہم نے براؤزر ٹیسٹ چلائے اور یہ ہوا:

سرخ ہیرے امتحان میں ناکام ہیں۔ نیچے دی گئی فائلیں DNS کی خرابیاں ہیں (ٹائم آؤٹ کو حل کریں)۔ سب سے اوپر کی ناکامیاں ٹائم آؤٹ ہیں۔

اپ ٹائم: 86.6
میڈین: 18 سیکنڈ
75 فیصدی: 29.3 سیکنڈ
95 فیصدی: 60 سیکنڈ

میڈین، لوڈنگ کے بعد ہٹا دیا گیا تھا۔ دوبارہ کیپچا (چین میں گوگل سروس بلاک) 28 سے 18 سیکنڈ تک کم ہوگئی۔ لیکن یہ اب بھی خوفناک نتائج ہیں، اس بات پر غور کرتے ہوئے کہ semrush.com (امریکہ سے) کے اسی ٹیسٹ نے ایک ہی صفحہ (جامد + متحرک) پر 10٪ صارفین (امریکہ سے) کے لیے 95 سیکنڈ سے بھی کم وقت دیا۔

آپ ہر ٹیسٹ میں جا کر دیکھ سکتے ہیں۔ آبشار اور دیگر مزید تفصیلی پیرامیٹرز۔ ہم نے غلطیوں کی وجوہات کی چھان بین شروع کی، اور اگر ٹائم آؤٹ کے لیے سب کچھ کم و بیش واضح ہے: چین میں انٹرنیٹ "اندر اور آؤٹ" ہے، اس کی وجہ سے بیرون ملک سے وسائل کے کنکشن اور لوڈنگ کی رفتار غیر مستحکم اور ناہموار ہے، پھر DNS کی غلطیوں نے ہمیں بہت حیران کر دیا۔ ہم نے یہ پایا پی او پی۔ Cloudflare اصل میں چین میں واقع ہیں، سائٹ کا پتہ کسی بھی کاسٹ آئی پی کو حل کرتا ہے، لیکن DNS سرورز امریکی ہیں، یہی وجہ ہے کہ DNS درخواستوں کو سرحد پار جانے پر مجبور کیا جاتا ہے، لہذا بعض اوقات وہ ناکام ہو جاتے ہیں۔

CF کے ساتھ اس سوال کی وضاحت کرنے کے بعد، یہ پتہ چلا کہ چین میں ان کے اپنے DNS سرور نہیں ہیں۔، اور یہ کب ہوگا ابھی تک نامعلوم ہے۔

لہذا، ہم نے صرف Cloudflare DNS کی جانچ کرنے کا فیصلہ کیا اور اپنی سائٹ کے لیے Cloudflare آپریٹنگ میکانزم کو "صرف DNS" یہ ایک موڈ ہے جب Cloudflare ٹریفک کو اپنے ذریعے پراکسی نہیں کرتا ہے، جس کا مطلب ہے کہ یہ DDoS تحفظ، CDN اور دیگر خصوصیات فراہم نہیں کرتا ہے، اور ایک باقاعدہ DNS سرور کے موڈ میں کام کرتا ہے۔

اس موقف کو مندرجہ ذیل تصویر میں منصوبہ بندی کے ساتھ دکھایا گیا ہے۔ اعداد و شمار ابھرتے ہوئے علم کو مدنظر رکھتے ہیں کہ Cloudflare کے DNS سرورز فائر وال کے پیچھے ہیں۔

کیچ پوائنٹ پر ہم نے سادہ جی ای ٹی ٹیسٹ چلائے (براؤزر ٹیسٹ نہیں)، جس میں بہت ساری ناکامیاں دکھائی گئیں۔ وہ اسی DNS غلطیوں کی وجہ سے ہوئے تھے۔

ہم نے استعمال کرتے ہوئے ان غلطیوں کو ڈیبگ کرنا شروع کیا۔ کھودنے اور پتہ چلا کہ پہلی درخواست پر پتہ کا درست تعین کیا گیا ہے، اور بار بار درخواست کرنے پر ہمیں ہر بار موصول ہوتا ہے۔ سروس فیل и نہیں ملا. یہ اچانک کیوں ہو رہا ہے؟

root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)

Cloudflare NS سرورز سے براہ راست استفسار کرتے وقت ایسی کوئی خرابیاں نہیں ہیں:

root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases: 

semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases: 

semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192

اس کا مطلب ہے کہ مسئلہ "مقامی" DNS سرور یا فراہم کنندہ کے سرور کی طرف ہے۔
مزید تفتیش میں یہ بات سامنے آئی سروس فیل ہم حل کرتے ہیں AAAA-ریکارڈز۔

یہ پتہ چلا کہ Cloudflare سے درخواست کرتے وقت اے اے اے اے-ریکارڈ جو ڈومین میں موجود نہیں ہے، کلاؤڈ فلیئر نے جواب دیا۔ А-ایک اندراج جو کہ آر ایف سی کے ساتھ غلطی اور عدم تعمیل ہے۔ مقامی حل کرنے والا کیوں کرتا ہے (xxxx) مجھے یہ پسند نہیں آیا، اور اس نے جواب دیا۔ سروس فیل. یہ رویہ نیچے دیے گئے لاگ میں واضح طور پر نظر آتا ہے:

root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @x.x.x.x

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @x.x.x.x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;semrushchina.cn.               IN      AAAA

;; Query time: 334 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Tue Aug 14 23:38:50 CST 2018
;; MSG SIZE  rcvd: 44

root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @dana.ns.cloudflare.com.

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;semrushchina.cn.               IN      AAAA

;; ANSWER SECTION:
semrushchina.cn.        300     IN      A       220.170.186.192

;; Query time: 185 msec
;; SERVER: 173.245.58.105#53(173.245.58.105)
;; WHEN: Tue Aug 14 23:43:03 CST 2018
;; MSG SIZE  rcvd: 60

ہم نے Cloudflare کو ایک بگ رپورٹ پیش کی، اور انہوں نے کچھ دیر بعد اسے ٹھیک کر دیا۔ یہ دلچسپ نکلا: اس وقت چین میں IPv6 سپورٹ نہیں ہے، اس لیے Cloudflare درخواست کے جواب میں اپنا IPv6 ایڈریس وہاں جاری نہیں کر سکا۔ اے اے اے اے-ریکارڈز۔ آخر میں، سب کچھ اس طرح حل ہوا کہ Cloudflare نے چین کو جواب دینا شروع کر دیا کوئی مواد نہیں اس طرح کی درخواستوں پر.

اس طرح، کیچ پوائنٹ ٹیسٹوں میں DNS کی غلطیاں تیزی سے کم ہوئیں، لیکن مکمل طور پر نہیں۔ ٹائم آؤٹ اب بھی یہاں ہے:

اور ہم نے دوسرا حل تلاش کرنا شروع کر دیا۔

اگلے حصے میں میں آپ کو بتاؤں گا کہ ہم نے چینی بادل کو کیسے آزمایا علی بابا کلاؤڈ، کس طرح، Nginx کے ایک چھوٹے سے "جادو" کی مدد سے، ہم تیزی سے PoC (تصور کا ثبوت) حل بنانے میں کامیاب ہوئے، ہم نے ملٹی کلاؤڈ حل کیسے بنائے، جن میں سے ایک نے بالآخر سروس کے کام کو تیز کرنے میں بہت مدد کی۔ چین سے.

دیکھتے رہنا!