AWS Client VPN کا کلائنٹ CIDR VPC کی رینج سے اوورلیپ نہیں ہو سکتا

AWS Client VPN اینڈ پوائنٹ آپ کے منتخب کردہ پول سے کلائنٹ پتے تقسیم کرتا ہے، اور AWS اینڈ پوائنٹ بنانے سے پہلے اُس پول کو ہدف نیٹ ورک کے سامنے جانچتا ہے۔ جانچ یہ نہیں کہ سب نیٹ خالی لگتا ہے یا نہیں۔ یہ ہے کہ پول VPC کی رینج سے اوورلیپ کرتا ہے یا نہیں، اور آج کوئی EC2 انسٹنس اُن پتوں کو استعمال کرے یا نہ کرے، جواب وہی رہتا ہے۔ اوورلیپ رینجز کا سوال ہے، تقسیم کا نہیں۔

پانچ جانچیں ترتیب سے کریں۔ پہلی ناکام جانچ پر رُک جائیں، کیونکہ بعد کا کوئی بھی مرحلہ پہلے کے فیصلے کو درست نہیں کر سکتا۔

اوورلیپ رینجز کا امتحان ہے، خالی پتوں کا نہیں

VPC کے CIDR سے شروع کریں، اُس سب نیٹ سے نہیں جسے آپ جوڑنا چاہتے ہیں۔ 172.20.0.0/22 کا پول 172.20.0.0/16 کے VPC کے اندر آتا ہے اور اُس وقت بھی مسترد ہوتا ہے جب کوئی سب نیٹ اُسے نہ روکے، کیونکہ اوورلیپ رینجز کی خصوصیت ہے، موجودہ تقسیم کی نہیں۔ پھر وہ منزلیں شامل کریں جن کی طرف اینڈ پوائنٹ روٹ کرتا ہے: پیئر VPC، ٹرانزٹ گیٹ وے اور سائٹ ٹو سائٹ کنکشن کے ذریعے مقامی رینجز۔ کوئی بھی رینج جس تک کلائنٹ کو پہنچنے کی ضرورت ہو سکتی ہے فہرست میں آتی ہے۔

اُنہیں یادداشت سے نہیں، اکاؤنٹ سے جمع کریں: aws ec2 describe-vpcs --query "Vpcs[].CidrBlock"، نیز اُس سب نیٹ کے روٹ ٹیبل اندراجات جسے آپ جوڑنا چاہتے ہیں۔

پول کا حجم بنانے سے پہلے طے ہوتا ہے

AWS Client VPN پر /22 سے /12 کے درمیان IPv4 کلائنٹ پول قبول کرتا ہے۔ /24 بہت چھوٹا ہے، /8 دستاویزی رینج سے باہر ہے، اور دونوں غلطیاں پول کو ورک لوڈ سب نیٹ کی طرح ناپنے سے آتی ہیں۔ متوقع بیک وقت کلائنٹس اور مارجن سے اِسے ناپیں، پھر اجازت یافتہ پریفکس تک گول کریں۔

کنسول میں لکھنے سے پہلے حساب جانچیں، کیونکہ غلط ٹائپ شدہ پریفکس بغیر کسی انتباہ کے پول کا حجم بدل دیتا ہے:

python3 -c "import ipaddress; p=ipaddress.ip_network('172.16.0.0/22'); print(p.num_addresses, p.prefixlen, p.overlaps(ipaddress.ip_network('172.20.0.0/16')))"

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

ریزولور کا اپنا پتہ کردار ہے

VPC ریزولور VPC رینج کے بنیادی پتے پر دو جمع کر کے جواب دیتا ہے، جو ضروری نہیں کہ آپ کے جوڑے گئے سب نیٹ کے اندر ہو۔ یہ سمجھنا کہ ریزولور کو کلائنٹ پول ہی میں رہنا ہے، یا اُس پتے کے گرد سب نیٹ بنانا، کچھ بدلے بغیر چیزوں کا اضافہ کرتا ہے۔ اہم یہ ہے کہ اینڈ پوائنٹ ایسی DNS سیٹنگ رکھے جو کلائنٹ لاگو کر سکے اور ریزولور ٹنل سے قابلِ رسائی ہو۔

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

بناتے وقت آپ جن چار فیلڈز کے پابند ہوتے ہیں

کلائنٹ IPv4 CIDR بناتے وقت مقرر ہوتا ہے۔ DNS سرور بدلنا، منسلکہ شامل کرنا، سیکیورٹی گروپ بدلنا، اجازت کے قواعد میں ترمیم کرنا یا split-tunnel راستے بدلنا سب عام ترامیم ہیں، اور اِن میں سے کوئی بھی پول کا نام نہیں بدلتا۔ یہی عدم توازن اِسے جائزے کے قابل بناتا ہے: سستی سیٹنگز وہ ہیں جو آپ بعد میں بدلنا چاہیں گے، اور مہنگی وہ ہے جس کے آپ پہلے پابند ہوتے ہیں۔ تبدیلی ونڈو کی منصوبہ بندی سے پہلے اینڈ پوائنٹ کی تفصیل پڑھیں۔

دوبارہ تعمیر فرض کرنے سے پہلے تعینات اینڈ پوائنٹ کا معائنہ کریں۔ aws ec2 describe-client-vpn-endpoints پول، DNS، split-tunnel پرچم اور منسلکات ایک ہی جواب میں واپس کرتا ہے، جو عام طور پر دوبارہ تعمیر کو خارج کرنے کے لیے کافی ہے۔

اینڈ پوائنٹ کو پیوند لگانے کے بجائے بدلیں

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

اُس تصدیق کے گزرنے تک پرانا اینڈ پوائنٹ چلتا رکھیں، اور ایسا انتظامی راستہ رکھیں جو نئے پر منحصر نہ ہو۔

ایک حد قابلِ ذکر ہے: یہ IPv4 کلائنٹ پول کا احاطہ کرتا ہے۔ Client VPN پر dual-stack اور IPv6 ٹریفک کی سیٹنگز اپنا الگ ایڈریسنگ ماڈل مانتی ہیں، لہٰذا اُس موڈ کی دستاویزات پڑھے بغیر اِس فہرست کی نقل نہ کریں۔