AWS Client VPN এন্ডপয়েন্ট DNS: রিজল্ভ করা IP পিন করলে কেন ব্যর্থ হয়
AWS Client VPN এন্ডপয়েন্টের নামটি আপনার রিজল্ভ করা ঠিকানা দিয়ে বদলে দিন, পরে টানেলটি কাজ করা বন্ধ করবে। এক্সপোর্ট করা নাম ও তার র্যান্ডম প্রিফিক্স রাখুন।
গত সপ্তাহে dig +short আপনার AWS Client VPN প্রোফাইলের এন্ডপয়েন্ট নামের জন্য একটি ঠিকানা দিয়েছিল, আর টানেলটি সংযুক্ত হয়েছিল। এই সপ্তাহে একই প্রোফাইল আপনার ল্যাপটপে 'Connecting' অবস্থায় বসে আছে, অথচ সহকর্মীর অস্পৃষ্ট কপি এখনও কাজ করছে। কিছুই ব্লক হয়নি এবং সার্টিফিকেটের মেয়াদ শেষ হয়নি। কেউ এন্ডপয়েন্ট হোস্টনেমটিকে সেই রিজল্ভ করা ঠিকানা দিয়ে প্রতিস্থাপন করেছে, আর পরিষেবা এখন সেখানে উত্তর দেয় না। এক্সপোর্ট করা নামটি হলো সেই অংশ যা এই পরিবর্তন সহ্য করার জন্য তৈরি।
আপনার প্রোফাইলের নামটি হয়তো যে নামটি জিজ্ঞাসা করা হচ্ছে সেটি নয়
Client VPN থেকে এক্সপোর্ট করা প্রোফাইলে সাধারণত remote-random-hostname থাকে। সেই অপশন চালু থাকলে ক্লায়েন্ট একটি ক্ষণস্থায়ী লেবেল তৈরি করে, একটি ডট দিয়ে সেটিকে এন্ডপয়েন্ট নামের সাথে জুড়ে দেয় এবং যৌগিক নামটি রিজল্ভ করে। এন্ডপয়েন্টের জোনে থাকা ওয়াইল্ডকার্ড রেকর্ড যেকোনো লেবেলের উত্তর দেয়, তাই বানানো প্রিফিক্সও রিজল্ভ হয় এবং হাতে কোয়েরিটি পুনরুৎপাদন করার চেষ্টা করলে এই কৌশলটি অদৃশ্য থাকে।
তাই যখন আপনি টার্মিনালে এন্ডপয়েন্ট নামটি পেস্ট করে উত্তর পান, তখন আপনি ক্লায়েন্ট সংযোগের সময় যে নামটি ব্যবহার করে তার চেয়ে ভিন্ন একটি নাম রিজল্ভ করেছেন। এই অমিল প্রোফাইলে সংশোধন করার কোনো ত্রুটি নয়। লেবেলটি ইচ্ছাকৃতভাবে আবার তৈরি হয়: অপশনটি ক্যাশকে পুরোনো উত্তর ধরে রাখতে দেয় না, এবং এটি কখনও আপনার মেশিন বা সেশন শনাক্ত করে না।
আমি এমন সামঞ্জস্যতার ঘটনায় পড়েছি যেখানে ক্লায়েন্ট অপশনটি সম্পূর্ণ উপেক্ষা করে। AWS এর সমাধান নথিভুক্ত করে: আসল এন্ডপয়েন্ট নামটি রাখুন এবং সামনে একটি র্যান্ডম স্ট্রিং ও একটি ডট যোগ করুন, এটিকে পেস্ট করার মান নয় বরং একটি নামকরণ প্যাটার্ন হিসেবে দেখুন। পুরোনো ক্লায়েন্টে এটি প্রয়োগ করা যুক্তিসঙ্গত; প্রিফিক্সযুক্ত স্ট্রিংটিকে এন্ডপয়েন্ট হিসেবে হার্ডকোড করা নয়।
সংরক্ষিত উত্তর কেন সঠিক থাকতে পারে না
Client VPN এন্ডপয়েন্ট ঠিকানাগুলো AWS পরিচালনা করে এবং সময়ের সাথে পরিবর্তিত হয়, যা সেরা-অনুশীলন নথিতে স্পষ্ট বলা আছে। ধরা পড়া উত্তর একটি রিজলভিংয়ের স্ন্যাপশট। যে প্রোফাইল এটি হার্ডকোড করে, পরিষেবা সরে গেলেই সেটি একটি অবসরপ্রাপ্ত হোস্টের দিকে তাক করা প্রোফাইলে পরিণত হয়, আর ব্যর্থতা খুব কমই DNS-এর মতো দেখায়: আপনি সংযোগ টাইমআউট বা আটকে যাওয়া হ্যান্ডশেক পান, তাই মানুষ রাউটিং ও সার্টিফিকেটের পেছনে ছোটে।
/etc/hosts-এ একই উত্তর একই মেয়াদসীমা উত্তরাধিকার করে, সাথে একটি অতিরিক্ত সমস্যা। hosts এন্ট্রি রিবুট, পুনরায় এক্সপোর্ট এবং 'ক্লায়েন্ট পুনরায় ইনস্টল করুন' সমাধান থেকে টিকে থাকে, তাই ঠিকানা সরলেই ব্যর্থতা ফিরে আসে। আমি একটি এন্ট্রিকে সপ্তাহের পর সপ্তাহ নিরীহ বসে থাকতে দেখেছি, তারপর সেটি বহনকারী প্রতিটি মেশিনকে অচল করে দিতে দেখেছি, অথচ নতুন ইনস্টল সাধারণভাবে সংযুক্ত হচ্ছিল। এই বিভাজন, একই অ্যাকাউন্টে এক দল ব্যর্থ আর অন্য দল ঠিক, হলো সবচেয়ে সস্তা সূত্র যা আপনি পাবেন।
র্যান্ডমাইজেশনের পরিধিও সঠিকভাবে নির্ধারণ করুন। এটি প্রতিটি সংযোগ প্রচেষ্টায় ঘটে। প্রতিষ্ঠিত টানেল তার এন্ডপয়েন্ট আবার রিজল্ভ করে না, সেশনের মাঝখানে সার্ভার বদলায় না, এবং আলাদা অ্যাপ্লিকেশন অনুরোধগুলো প্রত্যেকে নতুন VPN হোস্ট বেছে নেয় না। শুধু পরবর্তী প্রচেষ্টাই আবার রিজল্ভ করে, তাই সারাদিন কাজ করা একটি সেশন আগামীকাল সকাল সম্পর্কে কিছুই বলে না।
টানেল ওঠার সময় পরিষেবা কী যাচাই করে
Client VPN চায় আপনি যে ঠিকানায় সংযুক্ত তার সাথে এন্ডপয়েন্টের DNS নামের জন্য রিজল্ভ করা একটি ঠিকানার মিল থাকুক। এই একটি শর্তই সম্পর্কহীন দেখতে কয়েকটি ব্যর্থতার ব্যাখ্যা দেয়: অন্য জায়গায় নির্দেশ করা কাস্টম DNS রেকর্ড, আসল এন্ডপয়েন্ট ঠিকানায় ফরওয়ার্ড করা কাস্টম ফ্রন্টএন্ড, এবং কাঁচা ঠিকানায় পুনর্লিখিত প্রোফাইল। AWS সাম্প্রতিক AWS-প্রদানকৃত ক্লায়েন্টের সাথে কাস্টম-রেকর্ড-প্লাস-ফরওয়ার্ডিং ব্যবস্থাকে ব্যর্থতা হিসেবে নথিভুক্ত করে। যাচাইটি সংকীর্ণ; এটি এই রায় নয় যে প্রতিটি উপনাম নিষিদ্ধ।
এটি VPN প্রোটোকল সম্পর্কে সাধারণ নিয়মও নয়। একটি সংখ্যাভিত্তিক remote সাধারণ OpenVPN ডিপ্লয়মেন্টে সম্পূর্ণ বৈধ, এবং অনেকগুলো এভাবেই চলে। সীমাবদ্ধতা আসে পরিচালিত ব্যবস্থা থেকে, তার নিচের প্রোটোকল থেকে নয়।
যা সার্টিফিকেট যাচাই শিথিল করাকে ভুল প্রতিক্রিয়া করে তোলে। ঠিকানা বদলের পর প্রোফাইল ব্যর্থ হলে সার্ভার যাচাই বন্ধ করা রিজলভিং বা ঠিকানা-মিলের শর্ত ঠিক করার বদলে ত্রুটিটিকে সরিয়ে নেয় এবং এমন ক্লায়েন্ট রেখে যায় যা যেকোনো কিছু বিশ্বাস করবে। এক্সপোর্ট করা CA, সার্ভার যাচাই এবং পারস্পরিক প্রমাণীকরণ সেটিংস যেভাবে এসেছে ঠিক সেভাবেই রাখুন।
অনুমোদিত তালিকা, ইগ্রেস ও প্রাইভেট DNS তিনটি আলাদা সমস্যা
ল্যাপটপ সংযুক্ত হওয়ার আগে একটি গন্তব্য অনুমোদন করতে হয় এমন ফায়ারওয়াল নিয়ম বাইরের লিসেনার সম্পর্কে। নেটওয়ার্ক মালিককে এন্ডপয়েন্ট নাম, ট্রান্সপোর্ট ও কনফিগার করা পোর্ট দিন, তারপর জিজ্ঞাসা করুন তাদের নিয়ন্ত্রণ পরিষেবার DNS আচরণ অনুসরণ করতে পারে কি না। একটি ধরা পড়া ঠিকানা ধরে রাখা নিয়ম হলো অলিখিত মেয়াদসহ একটি স্ন্যাপশট। যদি নিয়ন্ত্রণ কেবল অপরিবর্তনীয় গন্তব্য গ্রহণ করে, তবে চুপচাপ উত্তর হার্ডকোড করার বদলে রোলআউটের আগেই সেই ফাঁক মেটান।
টানেল ওঠার পর করা অনুরোধের জন্য নির্দিষ্ট সোর্স ঠিকানা দরকার এমন অংশীদারের ভিন্ন প্রয়োজন: ইগ্রেস। একটি ওয়েবসাইট কী দেখে তা অ্যাপ্লিকেশন রুট ও স্প্লিট-টানেল নীতির উপর নির্ভর করে, ক্লায়েন্ট যে ঠিকানায় সংযুক্ত হয়েছিল তার উপর নয়। স্প্লিট-টানেল ট্রাফিক AWS-কে আদৌ স্পর্শ না-ও করতে পারে।
টানেলের ভিতরের প্রাইভেট DNS তৃতীয় স্তর। ক্লায়েন্টদের দেওয়া রিজলভার সংযোগের পর অভ্যন্তরীণ নামের উত্তর দেয়; টানেল তৈরি হওয়ার আগে এটি পাবলিক এন্ডপয়েন্ট রিজল্ভ করতে পারে না। এন্ডপয়েন্ট রিজলভিং ব্যর্থতা ও অভ্যন্তরীণ অ্যাপ্লিকেশন রিজলভিং ব্যর্থতা ভিন্ন পর্যায়ে ঘটে, আর এগুলো মিশিয়ে ফেললে আপনি ভুল লগে যান।
অ্যাড্রেস ফ্যামিলি একই তালিকায় পড়ে। একটি IPv4 উত্তর IPv6 বা ডুয়াল-স্ট্যাক এন্ডপয়েন্টের অনুমোদিত পথ সম্পর্কে কিছুই বলে না, তাই এক ফ্যামিলিতে নেওয়া স্ন্যাপশট অন্য ফ্যামিলির প্রমাণ নয়।
কিছু না পিন করেই একটি সংযোগ যাচাই করুন
যেভাবে এক্সপোর্ট হয়েছে সেই প্রোফাইল থেকেই শুরু করুন এবং এটি আসলে কী চায় তা পড়ুন:
grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'তারপর তিনটি জিনিস তুলনা করুন: প্রোফাইলে থাকা এন্ডপয়েন্ট নাম, নতুন প্রচেষ্টার জন্য ক্লায়েন্ট যে ঠিকানা জানায়, এবং নামটি এখন কীতে রিজল্ভ হয়। একটি নাম রিজল্ভ হওয়া কেবল প্রমাণ করে রেকর্ডটি উত্তর দেয়; ট্রান্সপোর্ট ও প্রমাণীকরণ আলাদা, এবং এন্ডপয়েন্টকে ping-এ উত্তর দিতে হয় না। মাঝের বিষয়টির একমাত্র উৎস ক্লায়েন্টের নিজের লগ, তাই প্রচেষ্টার পরে নয়, প্রচেষ্টার সময়ই তা ধারণ করুন।
| What you see | Usual cause | Next check |
|---|---|---|
| One machine fails, others connect | Pinned address or stale hosts entry on that machine | Diff its profile and hosts file against a working copy |
| Everyone fails at once, no config change | The endpoint address rotated | Confirm the current endpoint configuration with the account owner |
| Tunnel up, internal names fail | Client DNS policy, not endpoint resolution | Inspect the resolver pushed after connection |
আজ যে ঠিকানা উত্তর দেয় তা আজকের প্রমাণ; নামটিই সেই জিনিস যা পরিষেবা বৈধ রাখে। পর্যবেক্ষণটি লিপিবদ্ধ করুন, এন্ডপয়েন্টের মালিকের কাছে পাঠান, এবং প্রোফাইলটি নামের দিকেই নির্দেশিত রাখুন।
দুটি অভ্যাস ছাড়তে হবে: আটকে যাওয়া হ্যান্ডশেক পার হতে সার্টিফিকেট যাচাই বন্ধ করা, এবং একটি আটকে যাবে আশায় এন্ডপয়েন্ট নামের সামনে লেবেল স্তূপ করা। লেবেলটি ওয়াইল্ডকার্ড রেকর্ডের মাধ্যমে রিজল্ভ হয়, নয়তো সমস্যা অন্য জায়গায়। সঠিকভাবে কনফিগার করা প্রোফাইল যদি তবুও ব্যর্থ হয়, তবে লম্বা হোস্টনেম নয়, সঠিক কোয়েরি ও সংযোগ ঘটনাটি পাঠান।
বন্ধ করার আগে: প্রোফাইলে এখনও এক্সপোর্ট করা এন্ডপয়েন্ট নাম আছে, কোনো hosts ফাইল ঠিকানা পিন করে না, ক্লায়েন্ট লগের remote বর্তমান রিজলভিংয়ের সাথে মেলে, এবং ফায়ারওয়াল নিয়ম ঠিকানার বদলে এন্ডপয়েন্টের নাম বলে। পরবর্তী ব্যক্তিকে এটাই হস্তান্তর করার অবস্থা।