🥇 ڪيئن اسان عظيم چيني فائر وال کي ٽوڙيو (حصو 1)

سلام هر!

Nikita رابطي ۾ آهي - ڪمپني مان هڪ سسٽم انجنيئر SEMrush. اڄ مان توهان کي ٻڌايان ٿو ته اسان چين ۾ اسان جي semrush.com سروس جي استحڪام کي يقيني بڻائڻ جي ڪم کي ڪيئن منهن ڪيو، ۽ ان تي عمل ڪرڻ دوران اسان کي ڪهڙيون مشڪلاتون درپيش آيون (جڏهن ته اسان جي ڊيٽا سينٽر جي جڳهه آمريڪا جي اوڀر ساحل تي).

هي هڪ وڏي ڪهاڻي هوندي، ڪيترن ئي مضمونن ۾ ورهايل آهي. مان توهان کي ٻڌايان ٿو ته اهو سڀ ڪجهه اسان لاء ڪيئن ٿيو: چين کان مڪمل طور تي غير فعال سروس کان، خدمت جي ڪارڪردگي اشارن تائين ان جي آمريڪي ورزن جي سطح تي آمريڪن لاء. مان واعدو ڪندس ته اهو دلچسپ ۽ مفيد ٿيندو. سو، اچو ته هلون.

چيني انٽرنيٽ جا مسئلا

جيتوڻيڪ نيٽ ورڪ انتظاميه جي خاصيتن کان پري شخص بابت ٻڌو آهي چين جي عظيم فائر وال. واه، آواز ٿڌو، صحيح؟ پر اهو ڇا آهي ۽ اهو اصل ۾ ڪيئن ڪم ڪري ٿو هڪ بلڪه پيچيده سوال آهي. توھان انٽرنيٽ تي ڪيترائي مضمون ڳولي سگھوٿا ھن لاءِ وقف ٿيل آھي، پر ٽيڪنيڪل نقطي نظر کان، ھن فائر وال جي ڍانچي کي ڪٿي به بيان نه ڪيو ويو آھي. جيڪو، بهرحال، حيرت انگيز ناهي. مان فوري طور تي تسليم ڪندس ته ڪم جي هڪ سال جي نتيجن جي بنياد تي، مان اهو نه چئي سگھان ٿو ته اهو ڪيئن ڪم ڪري ٿو، پر مان توهان کي پنهنجي تبصرن ۽ عملي نتيجن بابت ٻڌائي سگهان ٿو. ۽ اسان هن فائر وال بابت افواهون شروع ڪنداسين.

هن فائر وال بابت ڪيتريون ئي افواهون آهن. اچو ته انهن مان مکيه ۽ سڀ کان وڌيڪ دلچسپ هڪ فهرست ۾ گڏ ڪريون:

گوگل، فيس بڪ، ٽوئٽر ۽ ٻيون ساڳيون خدمتون بلاڪ ڪيون ويون آهن ۽ چين ۾ ڪم نه ٿيون ڪن.
چين کان ٻاهر ۽ چين جي اندر وڃڻ واري ڪنهن به ٽرئفڪ کي مشين لرننگ استعمال ڪندي پارس ۽ محدود ڪيو ويندو آهي (مشڪوڪ ٽريفڪ جي صورت ۾)، جيڪو ان (ٽريفڪ) کي سرحد مان گذرڻ تمام گهڻو سست ڪري ٿو.
چيني انٽيليجنس ايجنسيون انهن جي فائر وال تان گذرندڙ ڪنهن به انڪرپٽ ٿيل ٽرئفڪ کي هيڪ ڪنديون.
VPN سرنگون، IPSEC سرنگون غير مستحڪم، حادثي ۽ مسلسل بند ٿيل آهن.
انڪرپشن جيتري سادو، ٽريفڪ جي تصديق/انڪريپٽ ڪرڻ لاءِ استعمال ٿيل پاس جملي جيتري آسان، اوترو تيزيءَ سان اهو چيني فائر وال ذريعي ٿيندو.

هتي اسان کي انهن افواهن بابت معلوم ڪيو آهي:

گوگل، فيس بوڪ، ٽويٽر ۽ ٻيون ساڳيون خدمتون يقيناً بند ٿيل آهن (توهان جو ڪو)، پر ڪيترائي ٽيڪنيڪل گوگل ڊومينز، مثال طور، منع ٿيل نه آهن ۽ ڪم ڪن ٿا (ساڳي gstatic.com). ان مان نتيجو نڪرندو آهي: توهان کي لاپرواهي سان سڀني گوگل ۽ ٻين وسيلن کي نه ڪٽڻ گهرجي جيڪي بلاڪ ٿيڻ لڳي.
ڪنهن به ٽريفڪ جي سرحد گذرڻ واقعي پنهنجي وقت ۾ سنجيده دير وڌائي ٿي. ٻه نتيجا ڏسو. ھڪڙي سائيٽ، ھڪڙو صفحو، سادي GET زندهاوم. پهرين ماپ خود چين (شينزين جي خوبصورت شهر) مان هئي. ٻيو نمبر هانگ ڪانگ کان ٻاهر کان ماپيو ويو هو (ان ۾ خودمختاري آهي، ۽ ان ۽ دنيا جي وچ ۾ ڪوبه فائر وال ناهي). هڪ سڌي لڪير ۾ شهرن جي وچ ۾ فاصلو لڳ ڀڳ 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

ڌيان ڏيڻ وقت_ رابطو. ۽ عام طور تي، توهان نتيجو ڏسو ٿا: فائر وال 4 اضافي سيڪنڊن کي شامل ڪري ٿو، جيڪو انتهائي ڊگهو آهي.

VPN ۽ IPSEC سرنگون اڪثر ناڪام ٿين ٿيون. مان ان بابت ٿوري دير بعد ۽ وڌيڪ تفصيل سان ڳالهائيندس. وي پي اين سرورز جيڪي استعمال ڪيا ويندا آهن استعمال ڪندڙ وقت سان گڏ (عام طور تي استعمال جي شروعات کان پوءِ هڪ ڏينهن اندر).
چين ۾ رهندڙ ماڻهن کان هڪ راءِ ملي آهي ته ٽريفڪ جي انڪرپشن کي جيترو آسان ڪيو ويندو، اوتري ئي تيزيءَ سان اهو سرحد تان گذري ٿو، ڇاڪاڻ ته اهو سمجهڻ آسان آهي ته ان ۾ ڪا به غير قانوني ڳالهه ناهي. ۽ ساڳيءَ طرح، ”صاف“ ٽريفڪ وڌيڪ بينڊوڊٿ ۽ گذرڻ جي رفتار حاصل ڪري ٿي، جڏهن ته ”گندي“ ٽريفڪ، جنهن ۾ ڪا به شيءِ سمجهي نه ٿي سگهي، حاصل ٿئي ٿي، ان جي ابتڙ، هڪ سست لنگهه. مثال طور آئون استعمال ڪندس 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.

تنهنڪري اسان وٽ ڇا آهي:

چيني فائر وال پاران پيدا ڪيل مسئلا مٿي بيان ڪيا ويا آهن.
ٻاهرين وسيلن ڏانهن پنگ ۽ اندر جي سرنگن وقتي طور تي غائب ٿي ويندا آهن.
ٻن پوائنٽن جي وچ ۾ ويڪرائي مسلسل تبديل ٿي رهي آهي، ۽ اڪثر ڪري اهو صرف غير متوقع آهي. جڏهن مختلف شهرن/علائقن کي ڳنڍيندي، توهان توقع ڪندا ته، علائقن جي جاگرافيائي مقام جي بنياد تي، دير گهٽ ٿيندي، پر توهان کي بلڪل برعڪس صورتحال ملندي.
انٽرنيٽ ۽ مواصلاتي چينل يا ته تيز يا سست آهن. هفتي جي ڏينهن ۽ ڏينهن جي وقت تي ٿورو انحصار آهي، پر هميشه نه.
چين کان ٻاهرين دنيا ڏانهن DNS درخواستون ڪڏهن ڪڏهن اجازت ڏنل وقت کان وڌي وينديون آهن.

اها تصوير جيڪا ظاهر ٿئي ٿي، اها صرف "بهترين" آهي.

ڊيٽا سينٽر، جيئن مون اڳ ۾ ئي چيو آهي، اوڀر آمريڪا ۾ آهي، ۽ سڄو SEMrush ڪيترن ئي هڪٻئي سان ڳنڍيل مصنوعات، پس منظر، فرنٽ اينڊ، ڊيٽابيس، ۽ اهو سڀ ڪجهه ڊي سي ۽ بادل تي مشتمل آهي. اسان، سسٽم ايڊمنسٽريٽرن جي هڪ ٽيم جي حيثيت سان، چين ۾ ٿوري ڪوشش سان جلدي ڪم شروع ڪرڻ جو ٽاسڪ ڏنو ويو.

اسان کي هڪ اهم سوال جو جواب ڏيڻو هو: ڇا اهو ٿورڙي خرچ سان حاصل ڪرڻ ممڪن آهي ۽ چيني انٽرنيٽ سان لاڳاپيل سڀني مسئلن کي حل ڪرڻ ۽ نيٽ ورڪ/ڪلائوڊ/سرور سطح تي فائر وال؟

اسان وصول ڪرڻ شروع ڪيو آء سي- لائسنس.

ICP لائسنس

چين (مين لينڊ چين) ۾ توهان جي خدمت جي ميزباني ڪرڻ ۽ ٽيسٽ ڪرڻ جي قابل ٿيڻ لاءِ، توهان کي پهريان ڊومين لاءِ ICP لائسنس حاصل ڪرڻ گهرجي.

جيڪڏهن توهان جي سائيٽ جي صارف ٽرئفڪ کي مينلينڊ چين ۾ ختم ڪيو ويو آهي، ۽ جيڪڏهن توهان جي ڊومين وٽ ICP لائسنس نه آهي، توهان جي ٽرئفڪ کي بلاڪ ڪيو ويندو ISP/هسٽنگ پاسي. دلچسپ ڳالهه اها آهي ته، ICP لائسنس ۾ هڪ مخصوص فراهم ڪندڙ شامل آهي، اهو هجي Cloudflare يا Alibaba Cloud. تنهن ڪري، جيڪڏهن توهان Cloudflare لاءِ ICP لائسنس حاصل ڪيو ۽ انهن سان پنهنجي ويب سائيٽ ميزباني ڪئي، ته توهان علي بابا ڪلائوڊ ڏانهن ”بغير بغير“ وڃڻ جي قابل نه هوندا. توھان کي ھن لائسنس ۾ ٻي ھوسٽنگ شامل ڪرڻ جي ضرورت پوندي.

ڊومين لاءِ ICP لائسنس حاصل ڪرڻ کان پوءِ، اسان مخصوص ٽيڪنيڪل خيالن ۽ حلن سان گڏ اچڻ ۽ ان تي عمل ڪرڻ جي قابل هئاسين.

جاچ جا حل

پر ان کان اڳ جو توھان سڌي طرح اسٽيجنگ جا اختيار ٺاھيو، نوبس کي ڦيرايو، سائيٽ جي ڪارڪردگي ۽ ان جي رفتار کي بھتر بڻايو، توھان کي ان کي جانچڻ لاءِ ھڪڙو اوزار چونڊڻو پوندو، اھو ڏسڻ لاءِ ته اسان جا ڪھڙا عمل سڌرن ٿا يا، ان جي برعڪس، سائيٽ جي ڪارڪردگي کي خراب ڪن ٿا.

اسان جي جاچ واري اوزار کي ٻه مکيه گهرجن کي پورا ڪرڻو پوندو:

اهو چين کان ٽيسٽ هلائڻ جي قابل هوندو،
ان کي برائوزر ٽيسٽ هجڻ گهرجي.

تنهنڪري اسان کي مليو ڪيچ پوائنٽ! انهن وٽ پوري دنيا ۾ جانچ جي جڳهن جي بهترين ڪوريج آهي. چين ۾ به هن ٽول ذريعي 100500 صوبن مان ٽيسٽ هلائي سگهجن ٿيون. هر هڪ ۾ ڪيترائي مختلف مهيا ڪندڙ آهن + ڪرڻ جي صلاحيت پسبوٽيسٽ (ڪجهه شيءِ جهڙوڪ هڪ ورچوئل مشين ڊيٽا سينٽر ۾) ۽ آخري دفعوٽيسٽ (جيترو ممڪن حد تائين صارف جي حالتن جي ويجهو، عرف ڪم اسٽيشن). آخري قسم جا امتحان وڌيڪ قيمتي آهن.

هڪ سالياني معاهدو ختم ڪرڻ کان پوء (انهي کان گهٽ ممڪن ناهي)، اسان اوزار جو مطالعو ڪرڻ شروع ڪيو. سچ پچ، اسان ان جي ڪارڪردگي کان خوشگوار حيران ٿي ويا. توهان هلائي سگهو ٿا:

DNS ٽيسٽ،
ويب ٽيسٽ (براؤزر ٽيسٽ، سادي GET/POST، موبائل ڪلائنٽ ايموليشن، وغيره)،
ٽرانزيڪشن چيڪ (مثال طور، لاگ ان)،
API ٽيسٽ،
پنگ، ٽريڪروٽ، اين ٽي پي، وغيره.

توهان هر شي جي فهرست نه ٿا ڪري سگهو. ۽ سڀ کان وڌيڪ اهم، هر ٽيسٽ کي چڱي طرح ترتيب ڏئي سگهجي ٿو هيڊرز ۽ ٻين پيٽرولن جو هڪ گروپ شامل ڪندي. پيداوار معلومات جو هڪ وڏو مقدار آهي جيڪو مڪمل طور تي توهان جي ٽيسٽ کي بيان ڪري ٿو. جيڪڏهن اسان اسان لاءِ سڀ کان وڌيڪ دلچسپ شين جي باري ۾ ڳالهايون (براؤزر ٽيسٽ)، نتيجن ۾ شامل آهن:

ڳنڍيو، انتظار ڪريو، لوڊ ڪريو، SSL، DNS وقت،
TTFB، TTLB، دستاويز مڪمل، وقت پيش ڪرڻ، DOM لوڊ،
جواب (ڪجهه ويجھو وقت جي پهرين بائيٽ تائين)، ويب پيج جو جواب (ڪجهه ويجھو وقت تائين آخري بائيٽ)،
ڪو به سيڪڙو، سراسري، وچين وقت
وغيره.

ان جي مطابق، اهي سڀئي ميٽرڪ تبديلين کي ڏسڻ ۽ سمجهڻ لاءِ عظيم آهن ته ڇا شيون بهتر ٿي چڪيون آهن. اسان بنيادي طور تي ڏٺو جواب، ويب پيج جو جواب، ميڊين، 75 ۽ 95 سيڪڙو.

هڪ اهم سوال جيڪو شروع کان ئي هوا ۾ هو: ڇا توهان ڪيچ پوائنٽ تي اعتبار ڪري سگهو ٿا؟؟ ڇا هي اوزار چين ۾ مختلف شهرن مان حقيقي سائيٽ لوڊ ڪرڻ جي رفتار کي ظاهر ڪري ٿو، يا اهو صرف هڪ خلا ۾ ڪجهه قسم جو امتحان آهي جنهن جو حقيقي صارف تجربو سان ڪو به تعلق ناهي؟
اهو هڪ وڏو مسئلو آهي، ڇاڪاڻ ته روس ۾ هجڻ جي ڪري اهو تقريبا ناممڪن آهي ته معتبر طور تي معلوم ٿئي ته چين مان هڪ سائيٽ ڪيئن ڪم ڪري ٿي. هڪ ورچوئل مشين ذريعي هڪ جراب-پراڪسي ڪرڻ سان، آخري نتيجو اهو آهي ته سائيٽ چند منٽن ۾ لوڊ ٿئي ٿي، جيڪا صرف ٽيسٽ لاءِ ناقابل قبول آهي، تنهن ڪري دستي جاچ لاءِ واحد آپشن آهي ڪرل ۽ سادو حاصل ڪريو ڪنسول مان ٽائمر سان. . اهو مدد ڪري ٿو ڇو ته هي ٽيسٽ نيٽ ورڪ حل جي رفتار کي چڱي طرح ظاهر ڪري ٿو، ۽ جيڪڏهن برائوزر ٽيسٽ پڻ آهن، پوء اهو تمام سٺو آهي.

بعد ۾ پاڻ به چين وياسون ۽ ان ڳالهه جا قائل هئاسين توهان ڪيچ پوائنٽ تي ڀروسو ڪري سگهو ٿا؛ اهو بلڪل صحيح طور تي حقيقي ڪارڪردگي اشارن کي ظاهر ڪري ٿو.

Cloudflare چائنا نيٽورڪ

جتان اسان ڪاميابيءَ سان استعمال ڪيو Cloudflare مکيه ڊومين لاءِ semrush.com، اسان فيصلو ڪيو ته فوري طور تي انهن جي خصوصيت کي آزمايو چين نيٽ ورڪ. هي اختيار فعال آهي صرف انٽرپرائز سائيٽن لاءِ الڳ درخواست تي ۽ اضافي فيس لاءِ. اهو پڻ صرف انهن سائيٽن لاءِ دستياب آهي جن وٽ مناسب ICP لائسنس آهي جيڪا Cloudflare کي فراهم ڪندڙ جي طور تي لسٽ ڪري ٿي. ان کي فعال ڪرڻ کان پوءِ، Cloudflare مان ”چيني سي ڊي اين“ سائيٽ لاءِ دستياب ٿي وڃي ٿي - چيني علائقن مان ٽريفڪ ويجھي PoP (Points of Presence) CF تي اچي ٿي، ۽ پوءِ ان جي نيٽ ورڪن ذريعي يا مهيا ڪندڙن/پارٽنرز جي نيٽ ورڪن ذريعي ان کي اصل تائين پهچايو وڃي ٿو. .

ھن ٽيسٽ بينچ جو خاڪو ھيٺ ڏنل آھي.

هي اسان لاء هڪ بهترين اختيار آهي. اهو ظاهر ٿئي ٿو ته ٻيو ڊومين پڻ CF لاء هوندو، جيڪو ڪمپني ۾ استعمال ٿيل حلن جي تعداد ۾ اضافو نٿو ڪري، ۽ عملي طور تي انفراسٹرڪچر کي پيچيده نٿو ڪري.

اسان برائوزر جا امتحان ورتا ۽ اھو ئي ٿيو:

لال هيرا امتحان ۾ ناڪام آهن. ھيٺ ڏنل فائلون DNS غلطيون آھن (حل ڪرڻ وقت ختم). مٿي تي ناڪاميون ٽائم آئوٽ آهن.

اپ ٽائم: 86.6
وچين: 18s
75 سيڪڙو: 29.3s
95 سيڪڙو: 60s

ميڊين، لوڊ ٿيڻ کان پوء هٽايو ويو ٻيهر ڪئپچا (چين ۾ گوگل سروس بلاڪ ٿيل) 28 کان 18 سيڪنڊن تائين گهٽجي وئي. پر اهي اڃا به خوفناڪ نتيجا آهن، انهي ڳالهه تي غور ڪندي ته semrush.com لاءِ ساڳيو امتحان (آمريڪا کان) 10 سيڪنڊن کان گهٽ ڏنو 95٪ استعمال ڪندڙن لاءِ (آمريڪا کان) ساڳئي صفحي تي (جامد + متحرڪ).

توهان هر امتحان ۾ وڃو ۽ ڏسو آبشار ۽ ٻيا وڌيڪ تفصيلي پيرا ميٽر. اسان غلطين جي سببن جي تحقيق ڪرڻ شروع ڪيو، ۽ جيڪڏهن وقت ختم ٿيڻ لاء سڀ ڪجهه گهٽ ۾ گهٽ واضح آهي: چين ۾ انٽرنيٽ "اندر ۽ ٻاهر" منتقل ٿئي ٿي، ان جي ڪري ڪنيڪشن جي رفتار ۽ ٻاهرين وسيلن جي لوڊشيڊنگ غير مستحڪم ۽ غير برابر آهي، پوءِ ڊي اين ايس جي غلطين اسان کي حيران ڪيو. اسان اهو مليو پي پي Cloudflare اصل ۾ چين ۾ واقع آهن، سائيٽ جو پتو ڪنهن به ڪاسٽ IP کي حل ڪري ٿو، پر DNS سرور آمريڪي آهن، ڇو ته DNS درخواستون سرحد پار وڃڻ تي مجبور آهن، تنهنڪري ڪڏهن ڪڏهن اهي ناڪام ٿيندا آهن.

CF سان هن سوال کي واضح ڪرڻ کان پوء، اهو نڪتو انهن وٽ چين ۾ پنهنجا DNS سرور نه آهن، ۽ جڏهن اهو ٿيندو اڃا تائين اڻڄاتل آهي.

تنهن ڪري، اسان صرف Cloudflare DNS کي جانچڻ جو فيصلو ڪيو ۽ اسان جي سائيٽ لاء Cloudflare آپريٽنگ ميڪانيزم کي تبديل ڪيو.صرف DNS" هي هڪ موڊ آهي جڏهن Cloudflare پنهنجي ذريعي ٽرئفڪ کي پراکسي نٿو ڪري، جنهن جو مطلب آهي ته اهو DDoS تحفظ، CDN ۽ ٻيون خاصيتون مهيا نٿو ڪري، ۽ باقاعده DNS سرور جي موڊ ۾ هلندي آهي.

هي موقف هيٺ ڏنل شڪل ۾ schematically ڏيکاريل آهي. انگ اکر اڀرندڙ علم کي مدنظر رکي ٿو ته Cloudflare جي DNS سرورز فائر وال جي پويان آهن.

ڪيچ پوائنٽ تي اسان سادو GET ٽيسٽ ورتا (نه برائوزر ٽيسٽ)، جنهن ۾ ڪيتريون ئي ناڪاميون ڏيکاريون ويون. اهي ساڳيا 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 کان درخواست ڪئي وئي AAAA-record جيڪو ڊومين ۾ موجود ناهي، 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 پتو جاري نه ڪري سگهيو. AAAA- رڪارڊ. آخر ۾، هر شي کي اهڙي طرح حل ڪيو ويو ته Cloudflare چين لاء جواب ڏيڻ شروع ڪيو NODATA اهڙين درخواستن تي.

اهڙيء طرح، ڪيچ پوائنٽ ٽيسٽ ۾ DNS غلطيون تيزيء سان گهٽجي ويون، پر مڪمل طور تي نه. ٽائم آئوٽ اڃا تائين هتي آهن:

۽ اسان هڪ ٻيو حل ڳولڻ شروع ڪيو.

ايندڙ حصي ۾ آئون توهان کي ٻڌائيندس ته اسان چيني بادل کي ڪيئن آزمايو علي بابا ڪڪر، ڪيئن، نينگڪس جي ٿورڙي "جادو" جي مدد سان، اسان جلدي PoC (تصور جو ثبوت) حل ٺاهڻ جي قابل ٿي ويا، اسان ڪيئن ملٽي ڪلائوڊ حل ٺاهيا، جن مان هڪ آخرڪار خدمت جي ڪم کي تيز ڪرڻ ۾ مدد ڪئي. چين کان.

ڏند رهو!

ايندڙ حصا

2 حصو

جو ذريعو: www.habr.com