Apache 2.4 کے ساتھ Subversion ہوسٹ کو VPN صارفین تک محدود کریں

Subversion مجازی ہوسٹ کو VPN پتے کی طرف موڑنے سے یہ بدلتا ہے کہ کون سی سائٹ درخواست کا جواب دیتی ہے، یہ نہیں کہ کس کو اسے بھیجنے کی اجازت ہے۔ رسائی کی جانچ بعد میں ہوتی ہے، URL سے مطابقت رکھنے والے حصے کے قواعد کے مطابق، اور ہوسٹ کا نام اس فیصلے میں کبھی داخل نہیں ہوتا۔ اگر ServerName آپ کی واحد تبدیلی تھی، تو مخزن کل کی طرح ہی قابل رسائی ہے۔ ترتیب میں دو الگ سوالوں کے جواب دینے ہوں گے: کس ساکٹ نے کنکشن قبول کیا اور درخواست کون سی شناخت لے کر آئی۔

ServerName دراصل کیا طے کرتا ہے

نام کی بنیاد پر مجازی ہوسٹنگ Host ہیڈر کا ServerName اور ServerAlias اندراجات سے موازنہ کرتی ہے، ایک ہوسٹ چنتی ہے اور اسے درخواست سنبھالنے دیتی ہے۔ کنکشن خود پہلے سرور کی ملکیت والے Listen ساکٹ نے قبول کیا تھا، ہوسٹ نے نہیں۔ اسی لیے نجی دکھنے والا نام کوئی تحفظ نہیں دیتا: ساکٹ تک پہنچنے والا کوئی بھی کلائنٹ وہ Host ہیڈر بھیج سکتا ہے۔ نام ایک روٹنگ کلید ہے، اور روٹنگ کلیدیں بلانے والا چنتا ہے۔

آپ بغیر اندازہ لگائے نقشہ دیکھ سکتے ہیں۔ apachectl -S ہر ہوسٹ، اس کا پورٹ اور نام چھاپتا ہے اور نشان زد کرتا ہے کہ پتے کے لیے کون سا طے شدہ ہے۔

RequireAll وہ کنٹینر ہے جو دونوں جانچیں لازمی بناتا ہے

Apache 2.4 ایک حصے کی Require ہدایات کو ایک مضمر RequireAny میں لپیٹتا ہے، اس لیے دو ننگی ہدایات کا مطلب ہے کہ ان میں سے کوئی ایک کافی ہے۔ کنٹینر شامل کریں اور معنی الٹ جاتا ہے:

<Location /svn/repo>
    AuthType Basic
    AuthName "Subversion"
    AuthBasicProvider file
    AuthUserFile /etc/apache2/svn.htpasswd
    <RequireAll>
        Require ip 10.8.0.0/24
        Require valid-user
    </RequireAll>
</Location>

RequireAll دونوں شرطیں مانگتا ہے: سرنگ کی رینج کے اندر ماخذ پتہ اور وہ صارف جسے مخزن قبول کرتا ہے۔ Subversion URL کے لیے صرف-VPN کا یہی مطلب ہونا چاہیے۔ mod_authz_core کا حوالہ کنٹینر کے قواعد کی دستاویز کرتا ہے۔ بلاک کو مخزن کے موجودہ Location کے اندر رکھیں اور پہلے سے کام کرنے والی DAV ہدایات کو ان کی جگہ پر رہنے دیں، کیونکہ یہ ٹکڑا نہ AuthType بدلتا ہے، نہ پاس ورڈ فائل، نہ راستے کی سطح کی اجازت۔

ماخذ کی جانچ mod_authz_host سے آتی ہے، اس لیے کچھ اور ڈیبگ کرنے سے پہلے تصدیق کریں کہ یہ لوڈ ہے: apachectl -M | grep authz_host۔

Apache جس پتے کا جائزہ لیتا ہے وہ ساکٹ کا پتہ ہے

Require ip اس پتے سے موازنہ کرتا ہے جو Apache نے کنکشن کے لیے درج کیا، اور یہ ہمیشہ وہ پتہ نہیں ہوتا جو کلائنٹ سمجھتا ہے کہ اس کے پاس ہے۔

جب VPN اپنے پتے بغیر ترجمے کے روٹ کرتا ہے، Apache سرنگ کا پتہ دیکھتا ہے اور 10.8.0.0/24 مماثل ہوتا ہے۔ جب گیٹ وے ترجمہ کرتا ہے، Apache گیٹ وے دیکھتا ہے اور قاعدہ خاموشی سے کسی سے مماثل نہیں ہوتا؛ یہی ہوسٹ کے سامنے TLS ختم کرنے والے لوڈ بیلنسر کے پیچھے بھی ہوتا ہے۔ اس صورت کے لیے mod_remoteip موجود ہے۔ بیلنسر کے لیے RemoteIPTrustedProxy کے ساتھ RemoteIPHeader X-Forwarded-For درج پتہ بدلتا ہے، اور تبھی رینج کے پاس موازنے کے لیے کچھ ہوتا ہے۔

کسی بھی من مانی فارورڈنگ ہیڈر پر بھروسہ کرنا کسی قاعدے کے نہ ہونے سے بھی بدتر ہے۔ کوئی بھی کلائنٹ 10.8.0.9 والا X-Forwarded-For بھیج کر ایسی رینج جانچ پوری کر سکتا ہے جو کبھی کسی قابل اعتماد چھلانگ سے منسلک نہیں تھی۔

سننے والے اور مخزن کی پالیسی کو تہوں میں رکھیں

بائنڈنگ ایک الگ کنٹرول ہے اور اکثر آسان تر۔ Listen 10.8.0.1:443 طے کرتا ہے کہ کون سے ساکٹ موجود ہیں، اور درخواست کبھی نہ کھلے ساکٹ پر ہوسٹ نہیں چن سکتی۔ قیمت اسٹارٹ اپ ترتیب ہے: اگر Apache شروع ہوتے وقت سرنگ کا انٹرفیس بند ہو، تو بائنڈنگ ناکام ہو جاتی ہے اور سروس اوپر نہیں آتی۔ اسے یونٹ ترتیب کے ساتھ جوڑیں، یا ایسے پتے پر بائنڈ کریں جو سرنگ سے آزاد موجود ہو۔

راستے کی اجازتیں AuthzSVNAccessFile میں رہتی ہیں۔ سائٹ کے لیے درست اکاؤنٹ منصوبے کے راستے پر لکھنے کی اجازت کے برابر نہیں، اور نیٹ ورک قاعدہ اسے نہیں بدلتا۔

جب بلاک شامل فائل میں ہو تو حصوں کے انضمام پر دھیان دیں۔ Apache نیسٹڈ حصوں میں اجازت کے کنٹینر ملاتا ہے اور سب سے مخصوص مماثل حصہ ضرورت کو شامل کرنے کے بجائے بدل سکتا ہے، اس لیے /svn پر قاعدہ /svn/repo/trunk تک نہ پہنچ سکے جب تنگ حصہ اپنا قاعدہ متعین کرے۔

مکمل کہنے سے پہلے دونوں انکار ثابت کریں

ایک نہیں، چار درخواستیں جانچیں۔ VPN کے اندر درست اکاؤنٹ کے ساتھ آپ کو مخزن کی فہرست ملنی چاہیے۔ VPN کے اندر غلط پاس ورڈ کے ساتھ فہرست کے بجائے 401 ملنا چاہیے۔ VPN سے باہر درست اسناد کے ساتھ 403 ملنا چاہیے، اور متبادل ہوسٹ نام پر وہی عوامی درخواست بھی اسی طرح ناکام ہونی چاہیے۔

ہر صورت کے لیے ایک حکم کافی ہے: curl -sI -u user:pass https://svn.example.com/svn/repo/، پھر اسٹیٹس لائن پڑھیں۔ کام کرنے والی صورت کو اصل کلائنٹ کے ذریعے بھی دہرائیں، کیونکہ svn info ان DAV طریقوں کی مشق کرتا ہے جو commit اور اپ ڈیٹس استعمال کریں گے۔

اگر چار میں سے کوئی نتیجہ آپ کی مطلوبہ پالیسی سے مطابقت نہ رکھے، تو ترتیب مکمل نہیں، اور ہوسٹ کا نام بدلنے سے وہ نہیں بدلے گا۔