Squid کے ذریعے ایک VPN اینڈ پوائنٹ: ایک تنگ CONNECT استثناء

Squid کسی CONNECT درخواست کا جواب پہلی http_access سطر سے دیتا ہے جو میچ کرتی ہے، اور وہ سطر انکار بھی ہو سکتی ہے۔ یہی ایک حقیقت واضح کرتی ہے کہ VPN اینڈ پوائنٹ کے لیے استثناء عموماً پہلی کوشش میں کیوں ناکام ہوتا ہے، کیونکہ درخواست کبھی اس اجازت تک نہیں پہنچتی جو کسی نے نیچے شامل کی تھی۔ ایک تنگ اصلاح موجودہ پورٹ گارڈ برقرار رکھتی ہے اور انہیں ایک جائزہ شدہ ماخذ، منزل اور پورٹ سکھاتی ہے۔ پراکسی پر باقی سب پہلے کی طرح برتاؤ کرتا ہے۔

Squid کسی CONNECT درخواست کا فیصلہ کیسے کرتا ہے

CONNECT درخواست ایک ہوسٹ اور پورٹ کا نام دیتی ہے، اور Squid http_access سطروں کو ترتیب سے طے کرتا ہے تاکہ ان میں سے کوئی میچ ہو جائے۔ میچ کرنے والا انکار فوراً جانچ ختم کر دیتا ہے اور کلائنٹ کو پراکسی سے 403 ملتا ہے۔ اسی لیے کسی قاعدے کی جگہ اس کے الفاظ سے زیادہ اہم ہے۔ اسی سطر کو ایک درجہ اوپر سرکانے سے نتیجہ مکمل بدل سکتا ہے۔

روایتی گارڈ Safe_ports سے باہر ہر چیز سے انکار کرتے ہیں اور SSL_ports سے باہر CONNECT سے انکار کرتے ہیں۔ یہ نام آپ کی اپنی ترتیب میں متعین ACL ہیں، اس لیے ان کا مواد پروٹوکول کا نہیں، آپ کا ہے۔ کوئی تقسیم Safe_ports کے طور پر پورٹ کی وسیع رینج کی اجازت دے سکتی ہے جبکہ CONNECT کو الگ محدود کرتی ہے۔ یہ ماننے سے پہلے کہ کوئی پورٹ ڈیزائن سے بند ہے، زندہ اقدار پڑھیں۔

تصدیق کریں کہ پراکسی ہی وہ جزو ہے جو درخواست سے انکار کر رہا ہے۔ Squid کا بنایا 403 VPN سرور کی TLS تنبیہ جیسا بالکل نہیں لگتا، اور دونوں کو ایک مسئلے میں ملانے سے پہلا گھنٹہ جاتا ہے۔ درخواست کے لیے رسائی لاگ کی سطر دیکھیں، کیونکہ وہ عمل اور اسے پیدا کرنے والا قاعدہ دونوں درج کرتی ہے۔

تین الگ ACL کے بجائے ایک مشترکہ میچ بنائیں

استثناء کو تین حقائق سے بنائیں: ایک منظور شدہ ماخذ رینج، ایک منظور شدہ منزل پتہ اور وہ واحد پورٹ جس پر اینڈ پوائنٹ سنتا ہے۔ دو الگ ACL اور ایک مشترکہ میچ بہت مختلف پالیسی بناتے ہیں، کیونکہ جانچ اسی امتزاج کی ہوتی ہے۔ مشترکہ ACL کا نام اس پر رکھیں جو وہ اجازت دیتا ہے، نہ کہ اس طریقے پر جو وہ اٹھاتا ہے۔

نیچے دیا گیا فارم دستاویزی رینجیں استعمال کرتا ہے جنہیں جائزہ شدہ اقدار سے بدلنا ہوگا۔ Squid ان میں سے کوئی نام اپنے لیے محفوظ نہیں رکھتا، اس لیے انہیں چننا اور یکساں رکھنا آپ کا کام ہے۔ یہ ترکیب صرف Squid 6 اور 7 تک محدود ہے، جن کی دستاویزی ترتیب all-of گروپ کی حمایت کرتی ہے۔ موجودہ حوالہ ان ہدایات کو Squid 8 میں دستیاب نہ ہونے کے طور پر نشان زد کرتا ہے، اس لیے اسے منتقلی راستہ نہیں بلکہ نسخے سے بندھی ترکیب سمجھیں، اور لاگو کرنے سے پہلے اپنے ہی نسخے کے حوالے میں ہدایت جانچیں۔

acl pvpn_src src 192.0.2.128/25
acl pvpn_dst dst 198.51.100.77/32
acl pvpn_port port 1194
acl pvpn_ok all-of CONNECT pvpn_port pvpn_dst pvpn_src

all-of گروپ صرف اس وقت میچ کرتا ہے جب ہر رکن میچ کرے، یعنی ماخذ، منزل اور پورٹ ایک ہی سطر میں جانچے جاتے ہیں۔ گروپ بذات خود کچھ نہیں دیتا، اور تین حقائق میں سے صرف دو سے میچ کرنے والی درخواست اسے پورا نہیں کر سکتی۔ یہی خصوصیت استثناء کو تنگ رکھتی ہے جب کوئی بعد میں دوسرا گیٹ وے شامل کرے۔ یا تو نیا منزل جان بوجھ کر شامل کیا جاتا ہے، یا درخواست اصل گارڈ کی طرف لوٹ جاتی ہے۔

پورٹ گارڈ ہٹائے بغیر انہیں موڑیں

اپنی موجودہ جگہوں پر دو روایتی گارڈ سطریں ایسی دکھتی ہیں۔ وہ عموماً تصدیق کے بعد اور ہر چیز کی اجازت دینے والی پالیسی سطروں سے پہلے ہوتی ہیں۔

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

ہر ایک میں منفی مشترکہ میچ شامل کریں، تاکہ میچ کرنے والا استثناء اس گارڈ سے بچ جائے جو بصورت دیگر اسے مسترد کرتا۔ صرف گارڈ سطریں بدلتی ہیں، اور ہر ایک میں صرف ایک اضافی شرط۔

http_access deny CONNECT !SSL_ports !pvpn_ok
http_access deny !Safe_ports !pvpn_ok

ایک رسائی سطر کی شرطیں مل جاتی ہیں، اس لیے سطر اب صرف ان درخواستوں سے انکار کرتی ہے جو اصل جانچ اور استثناء دونوں میں ناکام ہوں۔ منظور شدہ اینڈ پوائنٹ کی درخواست گزر جاتی ہے، اور باقی ہر درخواست پرانا پورٹ برتاؤ برقرار رکھتی ہے۔ یہ پورٹ کو عالمی SSL_ports فہرست میں شامل کرنے سے زیادہ تنگ ہے، جو اس پورٹ کو ہر منزل کے لیے اجازت دے دیتا۔ اگر پورٹ پہلے ہی اس فہرست میں ہے تو یہ ACL کچھ بھی تنگ نہیں کرتا اور پرانی، وسیع اجازت دیگر منزلوں پر لاگو رہتی ہے، اس لیے یہ دعویٰ کرنے سے پہلے کہ استثناء نے پورٹ کھولا، زندہ فہرست پڑھیں۔ یہ واپس بھی ہو سکتا ہے، کیونکہ دو سطریں اپنی سابقہ شکل میں لوٹ جاتی ہیں۔ رسائی کنٹرول حوالہ اس ترتیب اور ان روایتی گارڈ کا دستاویزی ریکارڈ ہے جن پر یہ تبدیلی منحصر ہے۔

استثناء کہاں نہیں رکھا جانا چاہیے

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

پورٹ گارڈ کے بعد درخواست کو ابھی کیا چاہیے، جانچیں۔ تصدیق شدہ اکاؤنٹ، اجازت شدہ کلائنٹ پتہ اور منزل پالیسی سب اب بھی لاگو ہیں، اور استثناء ان میں سے کچھ بھی نہیں بدلتا۔ اگر آپ کی پراکسی منظور شدہ اکاؤنٹ کو پہلے ہی من مانے منزلوں تک پہنچنے دیتی ہے، تو پورٹ گارڈ کبھی اصل کنٹرول نہیں تھا۔

غور کریں کہ اینڈ پوائنٹ بہرحال TCP ہے یا نہیں۔ CONNECT استثناء TCP رواں دھارے اٹھاتا ہے، اور UDP استعمال کرنے والی OpenVPN پروفائل اس کے ذریعے قابل رسائی نہیں بنے گی۔ پروفائل کو TCP میں صرف اس وقت بدلیں جب سرور ایسے ہی سنتا ہو اور آپریٹر برتاؤ کا فرق قبول کرے۔

پارسر اور حقیقی درخواست سے حد جانچیں

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

پھر دوبارہ لوڈ کریں اور منظور شدہ ماخذ سے پراکسی کے ذریعے ایک حقیقی CONNECT بھیجیں۔ پارسر چلانا پہلے آتا ہے، کیونکہ ٹائپنگ کی غلطی والا دوبارہ لوڈ آپ کو پالیسی کے بارے میں کچھ نہیں سکھاتا۔

squid -k parse
squid -k reconfigure
curl -v -p -x http://proxy.lab.internal:3128 https://vpn.lab.internal:1194/ --max-time 5

تین صورتیں جانچیں: منظور شدہ ماخذ اور اکاؤنٹ، غیر منظور شدہ ماخذ، اور اسی پورٹ پر مختلف منزل۔ تیسری صورت ہی ثابت کرتی ہے کہ استثناء تنگ ہے، کیونکہ وہ منزل کے میچ کے بغیر پورٹ استعمال کرتی ہے۔ کلائنٹ پیغام پر بھروسا کرنے کے بجائے تینوں کے لیے رسائی لاگ پڑھیں۔ کامیاب CONNECT صرف ایک TCP دھارہ قائم کرتا ہے اور اس سے زیادہ کچھ نہیں، اس لیے VPN مصافحہ الگ جانچ ہی رہتا ہے۔