Squid فارورڈ پراکسی کے لیے HAProxy صحت کی جانچ
ایسی HAProxy صحت کی جانچ بنائیں جو فارورڈ پراکسی سے بات کرے اور سننے والے کی رسائی، CONNECT کی قبولیت اور اصل سے حصول میں فرق کرے۔
پراکسی ہوسٹ پر /check.txt نامی فائل صحت کا واضح ہدف لگتی ہے۔ اصل بات یہ ہے کہ Squid کا واضح فارورڈ سننے والا اس ہوسٹ کی دستاویزات کی جڑ پیش کرنے والی عام ویب سائٹ نہیں ہے۔
HEAD /check.txt HTTP/1.1 جیسی اصل طرز کی درخواست فارورڈ پراکسی کے ذریعے عام HTTP درخواست کے لیے متوقع مطلق ہدف چھوڑ دیتی ہے۔ ترتیب کے مطابق یہ مسترد ہو سکتی ہے یا کوئی دوسری مقامی سروس اسے سنبھال سکتی ہے۔ دونوں نتائج ڈیش بورڈ کے اشارے سے کم بتا سکتے ہیں۔
وہ سروس منتخب کریں جو دستیاب رکھنی ہے
| جانچ | مفید ثبوت |
|---|---|
| پراکسی سننے والے سے TCP رابطہ | قابل رسائی عمل اس رابطے کو قبول کرتا ہے۔ |
| قابو شدہ ہدف سے CONNECT | پراکسی وہ سرنگ درخواست قبول کرتا ہے۔ |
| پراکسی کے ذریعے HTTP حصول | منتخب درخواست راستہ متوقع جواب واپس کر سکتا ہے۔ |
تیسری صورت میں درخواست کو ہدف چاہیے، مثلاً:
HEAD http://probe.example.internal/proxy-ready HTTP/1.1
Host: probe.example.internal
ہوسٹ نام صرف مثال ہے۔ ایسا قابو شدہ اینڈ پوائنٹ استعمال کریں جسے پراکسی حل کر سکے اور جہاں پہنچنے کی اجازت جان بوجھ کر دی گئی ہو۔ HAProxy کا http-check send طریقہ، URI، ورژن اور ہیڈر منتخب کرنے کی حمایت کرتا ہے؛ اصل سرور کی مثال کو بغیر تبدیلی ورثے میں لینے کے بجائے اس درخواست کو واضح طور پر ترتیب دیں۔
HEAD جواب کی حالت اور ہیڈر جانچ سکتا ہے۔ جو جوابی باڈی کبھی منتقل نہیں ہوتی اسے یہ جانچ نہیں سکتا۔ اگر صحت کا معاہدہ باڈی میں نشان مانگتا ہے تو موزوں GET جانچ منتخب کریں اور اس نشان کی تصدیق کریں۔
پراکسی توثیق شامل ہونے پر جانچ اکاؤنٹ اور ماخذ پابندیاں تنگ رکھیں۔ سبز نشان حاصل کرنے کے لیے پورے سننے والے کو توثیق سے استثنیٰ دینا اس سروس کو بدل دیتا ہے جس کی حفاظت کی جا رہی ہے۔
آخر میں طے کریں کہ ناکام جانچ کیا ہٹائے۔ قابو شدہ ماخذ کی رکاوٹ بیک وقت ہر پراکسی کی فارورڈنگ جانچ ناکام کر سکتی ہے۔ یہی وہ انحصار ہو سکتا ہے جسے آپ ماپنا چاہتے ہیں، یا سننے والے کی صحت اور سرے سے سرے تک دستیابی کو الگ اشارے رکھنے کی وجہ ہو سکتی ہے۔