Android সর্বদা-চালু VPN: এন্ডপয়েন্ট নাম কীভাবে আগে সমাধান হয়

টানেল তৈরির আগেই Android ট্র্যাফিক ব্লক করে, তবুও ক্লায়েন্টকে তার এন্ডপয়েন্ট সমাধান করতে হয়। এখানে ক্রমটি এবং যেখানে ডেডলক হয়।

ফোন রিবুট হয়, সর্বদা-চালু সক্রিয়, VPN ছাড়া সংযোগ ব্লক করুন চালু, এবং টানেল কখনোই ওঠে না। কিছুই ভুলভাবে কনফিগার করা নেই: ব্লকটি তার কাজ করছে, এবং ক্লায়েন্টের নিজের এন্ডপয়েন্টে পৌঁছানোর চেষ্টাও তার অধীন। টানেল থাকার আগেই এন্ডপয়েন্ট সমাধান করতে হবে, এমন একটি ক্লায়েন্ট দ্বারা যাকে নেটওয়ার্কের সাথে কথা বলার অনুমতি আছে যখন অন্য কোনো অ্যাপকে নেই। কোন উপাদান এটি করে এবং কোন ক্রমে, তা বোঝাই রহস্যটিকে কনফিগারেশন প্রশ্নে বদলে দেয়।

VPN বিল্ডার আসলে কী চায়

একটি Android VPN অ্যাপ প্ল্যাটফর্মকে সার্ভার ঠিকানা দেয় না। এটি একটি স্থানীয় ইন্টারফেস তৈরি করে: টানেলের জন্য ঠিকানা ও রুট, অ্যাপগুলো ভিতরে যে রিজলভার ব্যবহার করবে, এবং তারপর establish() একটি ফাইল ডেসক্রিপ্টর ফেরায় যা অ্যাপ কাঁচা IP প্যাকেট হিসেবে পড়ে ও লেখে। দূরবর্তী এন্ডপয়েন্ট সেই বিল্ডারে একেবারেই আসে না।

এটাই মূল কাঠামোগত সত্য। প্ল্যাটফর্ম একটি tun ইন্টারফেস তৈরি করে এবং তার উপর নীতি প্রয়োগ করে; অ্যাপটি পরিবহনটি ব্যবহারকারী স্পেসে বাস্তবায়ন করে, অর্থাৎ অ্যাপ নিজেই তার এন্ডপয়েন্ট নাম সমাধান করে এবং এনক্রিপ্টেড সংযোগ খোলে। তাই হোস্টনেম এন্ডপয়েন্ট সম্ভব, প্ল্যাটফর্ম নাম সমর্থন করে বলে নয়, বরং প্ল্যাটফর্ম এন্ডপয়েন্ট কখনো দেখে না বলে।

বিল্ডারের একটি ফিল্ড ঠিকানা নেয়: DNS সার্ভার। সেগুলো সংখ্যাগত রিজলভার ঠিকানা হতে হবে, সাধারণত যেগুলো অপারেটর টানেলের মধ্য দিয়ে জিজ্ঞাসা করতে চায়। সেই ফিল্ড বর্ণনা করে টানেল ওঠার পরে অ্যাপগুলো তাদের প্রশ্ন কোথায় পাঠায়। ক্লায়েন্ট কীভাবে এন্ডপয়েন্ট খুঁজে পায় সে বিষয়ে এটি কিছুই বলে না, আর দুটিকে একই সেটিং ভাবাই বিভ্রান্তির শুরু।

দুটি DNS প্রশ্ন, একটি নয়

প্রথম প্রশ্নটি হলো: টানেল ওঠার পরে অ্যাপগুলো তাদের প্রশ্ন কোথায় পাঠায়? উত্তর হলো টানেলের ভিতরে থাকা একটি রিজলভার ঠিকানা, tun ইন্টারফেস দিয়ে পৌঁছানো যায়, স্বভাবতই সংখ্যাগত।

দ্বিতীয় প্রশ্নটি হলো: সেই টানেল থাকার আগে ক্লায়েন্ট তার নিজের এন্ডপয়েন্ট কীভাবে খুঁজে পায়? সেই সন্ধান টানেলের বাইরে, অন্তর্নিহিত নেটওয়ার্কে, ক্লায়েন্টের প্রসেসে ঘটে। এটি একটি নাম ব্যবহার করতে পারে, এবং এমন রিজলভার ব্যবহার করতে হবে যা ডিভাইস VPN ছাড়াই পৌঁছাতে পারে।

পর্যায়কে সমাধান করেপথব্যর্থতা কেমন দেখায়
এন্ডপয়েন্ট সন্ধানVPN অ্যাপঅন্তর্নিহিত নেটওয়ার্ক, সুরক্ষিত সকেটকখনো সংযোগ হয় না; tun ইন্টারফেসে ট্র্যাফিক নেই
পিয়ার প্রমাণীকরণক্লায়েন্ট ও সার্ভারটানেল পরিবহনসংযোগ হয় তারপর বিচ্ছিন্ন; সার্টিফিকেট বা কী ত্রুটি
ব্যক্তিগত নাম সন্ধানটানেলের মধ্য দিয়ে অ্যাপtun-এর ভিতরে রিজলভারটানেল ওপরে, অভ্যন্তরীণ সাইট সমাধান হয় না

তিন পর্যায়, তিন ভিন্ন লক্ষণ। সংযোগ করা যাচ্ছে না এমন একটি ত্রুটি বার্তা সেগুলোকে একত্র করে, তাই মানুষ DNS সার্ভার ফিল্ড সম্পাদনা করে এমন সমস্যা ঠিক করতে চায় যা সেই ফিল্ড পড়ার আগেই ঘটে।

বুটস্ট্র্যাপ কেন ডেডলক হতে পারে

ব্লক সক্রিয় রেখে সর্বদা-চালু মানে VPN-এর ভিতরে নেই এমন ট্র্যাফিক বাদ পড়ে, VPN-এর মালিক অ্যাপের ট্র্যাফিকসহ। বেরোনোর পথ স্পষ্ট: অ্যাপ একটি সকেটে protect() ডাকে, যা এটিকে অন্তর্নিহিত নেটওয়ার্কে বাঁধে যাতে এটি টানেল এড়িয়ে বাইরে যেতে পারে। প্রতিটি VPN ক্লায়েন্টকে নিজের পরিবহনের জন্য এটি করতে হবে, নইলে কখনো সার্ভারে পৌঁছাতে পারবে না।

এখন এমন একটি ডিপ্লয়মেন্ট ভাবুন যেখানে এন্ডপয়েন্ট নাম জানে একমাত্র রিজলভারটিই টানেলের ভিতরে। নাম সমাধান করতে ক্লায়েন্টের টানেল দরকার, আর টানেল তৈরিতে নাম দরকার। এটি সত্যিকারের বৃত্তাকার নির্ভরতা, এবং কোনো ক্লায়েন্ট কনফিগারেশন এটি সমাধান করে না। এটি ডিজাইনের ত্রুটি, বাগ নয়।

সময় একই নির্ভরতাকে মৃদু রূপে প্রকাশ করে। প্রথম আনলকের আগে বুটের সময় ডিভাইসের ব্যবহারযোগ্য নেটওয়ার্ক নাও থাকতে পারে; ক্যাপটিভ পোর্টালে নেটওয়ার্ক থাকে কিন্তু পোর্টাল ছাড়া সব ব্লক করে; Wi-Fi থেকে সেলুলারে হ্যান্ডওভারে সুরক্ষিত সকেটের অন্তর্নিহিত নেটওয়ার্ক বদলে যায় এবং ক্লায়েন্টকে তা লক্ষ্য করে আবার সমাধান করতে হয়। প্রত্যেকটিই বুটস্ট্র্যাপ ঘটনা, এবং রাত 3টায় আবিষ্কার করার বদলে সচেতনভাবে পরীক্ষা করা উচিত।

উত্তরটি পিন করা কেন সমাধান নয়

প্রলুব্ধকর উপায় হলো নামটি একবার সমাধান করে প্রাপ্ত ঠিকানাটি সংখ্যাগত ফিল্ডে পেস্ট করা, বা কাস্টম বিল্ডে হার্ডকোড করা। এটি কাজ করে বলে মনে হয়, এবং একটি নামকে স্ন্যাপশটে পরিণত করে। অপারেটর এন্ডপয়েন্ট সরালে, মাইগ্রেশন, anycast পরিবর্তন বা নতুন আঞ্চলিক ঠিকানার মাধ্যমে, ক্লায়েন্ট পুরনোটিই ডায়াল করতে থাকে এবং ইন্টারফেসে কিছুই কারণ ব্যাখ্যা করে না।

DNS রেকর্ড সময়-থেকে-জীবন বহন করে ঠিক যাতে উত্তর বদলাতে পারে; ক্যাশিং সেই জীবনকাল দিয়ে সংজ্ঞায়িত, চিরকালের জন্য নয়। উত্তর পিন করা নামকে ঠিকানার চেয়ে ভালো করে যে প্রক্রিয়াটি তা বাদ দেয়, কিন্তু নাম ব্যবহারের পরিচালন ব্যয় ধরে রাখে।

পিন করা প্রায়ই দ্বিতীয় খারাপ অভ্যাসের সাথে যায়: সংযোগ এখন ভিন্নভাবে ব্যর্থ হয় বলে পরিচয় যাচাই শিথিল করা। সার্ভার পরিচয় যাচাই বুটস্ট্র্যাপ সমস্যার অংশ নয়, এবং এটি দুর্বল করা DNS অসুবিধার বিনিময়ে আটকানোর ঝুঁকি দেয়।

রিবুট সহ্য করে এমন ডিজাইন

টেকসই ব্যবস্থাটি অনাকর্ষণীয়। এমন ক্লায়েন্ট ব্যবহার করুন যা সুরক্ষিত সকেট সঠিকভাবে বাস্তবায়ন করে এবং অন্তর্নিহিত নেটওয়ার্কে তার এন্ডপয়েন্ট সমাধান করে, এবং তাকে এমন এন্ডপয়েন্ট নাম দিন যা প্রকাশ্যে বা টানেলের আগে পৌঁছানো যায় এমন রিজলভার দিয়ে সমাধান হয়। ব্লক সক্রিয় রাখুন; DNS কাজ করার জন্য এটি সম্পূর্ণ বন্ধ করা ডিপ্লয়মেন্ট যে বৈশিষ্ট্যের জন্য আছে তা সরিয়ে দেয়।

যেখানে এন্ডপয়েন্ট গোপন থাকতে হবে, প্ল্যাটফর্ম ব্যবহার করতে পারে এমন স্পষ্ট বুটস্ট্র্যাপ পথ দিন, যেমন টানেল ছাড়াই পৌঁছানো যায় এমন রিজলভার বা অপারেটরের রক্ষণাবেক্ষণ করা ম্যানেজমেন্ট সংযোগ, এবং সেই ব্যতিক্রম সংকীর্ণ রাখুন এবং ব্যবহারকারী টগলের বদলে নীতি দ্বারা পরিচালিত রাখুন। Android VpnService ডকুমেন্টেশন হলো প্ল্যাটফর্ম সুরক্ষা ও জীবনচক্র নিয়ে কী নিশ্চিত করে তার তথ্যসূত্র, এবং VpnService.Builder রেফারেন্স নিশ্চিত করে যে DNS ফিল্ড সংখ্যাগত ঠিকানা নেয়।

তারপর তিন পর্যায়ে, ক্রমে, রিবুটের পরে নতুন সংযোগে যাচাই করুন: এন্ডপয়েন্ট নাম সমাধান হয়, টানেল প্রতিষ্ঠিত হয় ও পিয়ার প্রমাণিত হয়, এবং টানেলের রিজলভার দিয়ে ব্যক্তিগত নাম সমাধান হয়। প্রথম পর্যায় ব্যর্থ হলে পরের কিছুই কাজ করতে পারে না, এবং সমাধান বুটস্ট্র্যাপ পথে, কখনো রিজলভার ফিল্ডে নয়।

  • এন্ডপয়েন্ট সমাধান অ্যাপে, টানেলের বাইরে, সুরক্ষিত সকেটে ঘটে।
  • বিল্ডারের DNS ফিল্ড টানেলের ভিতরের অ্যাপের জন্য, ক্লায়েন্টের নিজের এন্ডপয়েন্টের জন্য নয়।
  • শুধু টানেল দিয়ে পৌঁছানো যায় এমন রিজলভার ডেডলক, ধীর সূচনা নয়।
  • রিবুটের পরে এন্ডপয়েন্ট, প্রমাণীকরণ ও ব্যক্তিগত সন্ধান আলাদাভাবে পরীক্ষা করুন।

সম্পর্কিত নিবন্ধ