একজন ব্যবহারকারী সংযোগ করতে পারেন এবং অন্যজন পারেন না, একই পোর্টাল দিয়ে, একই দিনে। দুজনেরই সার্ভার-লক করা প্রোফাইল আছে, দুজনেই একই Access Server বিল্ডে আছেন, এবং একমাত্র পার্থক্য হলো তাঁদের প্রোফাইল কখন তৈরি হয়েছিল। এটিই সেই নিদর্শন যা চিনতে হবে, কারণ "সার্ভার-লক করা" একটি সংযোগ-ক্রম নয়, একটি নীতি বোঝায়। Access Server ওই আর্টিফ্যাক্টের দুইটি প্রজন্ম পাঠিয়েছে, এবং একটি TLS রিভার্স প্রক্সি তাদের কেবল একটি পথের সামনে বসে। তিনটি শর্ত ঠিক করে আপনি কোন শাখায় আছেন।

দুই প্রজন্ম, দুই সংযোগ-ক্রম

পুরোনো নকশায়, যা 2.8 পর্যন্ত চালু, আমদানি করা ফাইলটি একটি সিউডো-প্রোফাইল। OpenVPN Connect এটি HTTPS-এর মাধ্যমে Access Server ওয়েব API-র বিরুদ্ধে প্রমাণীকরণে ব্যবহার করে, একটি সাময়িক ব্যবহারকারী-লক করা প্রোফাইল ও একটি সেশন টোকেন পায়, এবং তারপরেই VPN স্থাপন করে। দুইটি ট্রান্সপোর্ট ক্রমান্বয়ে চলে, এবং প্রথমটি একটি সাধারণ ওয়েব অনুরোধ।

2.9-এর সঙ্গে প্রবর্তিত ফরম্যাট সেই প্রতি-সংযোগ বুটস্ট্র্যাপ করে না। এটি একটি নেটিভ প্রোফাইল যা সামঞ্জস্যপূর্ণ OpenVPN ক্লায়েন্ট ব্যবহার করতে পারে, কেবল OpenVPN Connect নয়। এটি ডাউনলোড করা বা URL দিয়ে আমদানি করা এখনও HTTPS জড়িত থাকতে পারে — এটি একটি প্রকাশনা ধাপ, প্রতি-সংযোগে সাময়িক প্রোফাইল আনয়ন নয়।

Older server-locked (≤2.8)Newer server-locked (2.9+)
Before the tunnelWeb API call with credentialsNothing; the profile is already local
Client requirementOpenVPN ConnectAny compatible client
What a TLS web proxy can breakThe bootstrap, before any VPN attemptDownload only, not the connection
Expected HTTP log on connectA request from the clientOften nothing at all

আপগ্রেড পূর্বে ইস্যু করা প্রোফাইল অগত্যা পুনর্লিখন করে না, তাই চলমান সার্ভার সংস্করণ এখনও পুরোনো আর্টিফ্যাক্ট বিতরণ করতে পারে। সার্ভার বিল্ড আপনাকে বলে কী সম্ভব, এই ব্যবহারকারী কী আমদানি করেছেন তা নয়।

তিনটি শর্ত যা আপনার শাখা বেছে নেয়

প্রথম শর্তটি আর্টিফ্যাক্টের প্রজন্ম। ফাইলটি চান, দেখুন এটি কীভাবে তৈরি হয়েছিল, এবং যে ক্লায়েন্ট সংস্করণ এটি আমদানি করেছে তা লিখে রাখুন। ফাইল থেকে প্রজন্ম নির্ধারণ করতে না পারলে, একটি পরীক্ষামূলক অ্যাকাউন্টের জন্য ইস্যু করা নতুন প্রোফাইল আপনাকে বলবে সার্ভার আজ কী তৈরি করে, যা ব্যর্থ ব্যবহারকারীর কাছে থাকা তথ্য থেকে আলাদা।

দ্বিতীয়টি হলো আপনার ফ্রন্টএন্ড আসলে কী সমাপ্ত করে। যে সপ্তম স্তরের HTTP রিভার্স প্রক্সি TLS অফলোড করে তা চতুর্থ স্তরের TCP ফরওয়ার্ডারের সমান বস্তু নয়, এবং UDP ফরওয়ার্ডারও নয়। পোর্ট 443-এ Access Server-এর স্বাভাবিক বিন্যাসে OpenVPN TCP ডেমন ব্রাউজার ট্রাফিক চিনে তা ওয়েব সেবাগুলোতে দেয়, তাই সামনে একটি সম্পর্কহীন HTTPS টার্মিনেটর বসালে সেই ডেমনটির প্রোটোকল হ্যান্ডলিং সংরক্ষিত থাকে না। একই সংখ্যা 443 ভাগ করা দুইটি নকশাকে সমতুল্য করে না।

তৃতীয়টি হলো ব্যর্থতা কোথায় পড়ে। VPN-পূর্ব ব্যর্থতা এবং কন্ট্রোল-চ্যানেল ব্যর্থতা একটি ক্লায়েন্টে যেটি কেবল "সংযোগ হচ্ছে" বলে, একই রকম দেখায়, কিন্তু তারা ভিন্ন স্থানে প্রমাণ রেখে যায়। পুরোনো ফরম্যাট চালু থাকলে বুটস্ট্র্যাপ প্রার্থী। নতুন ফরম্যাট চালু থাকলে খালি ওয়েব অ্যাক্সেস লগ প্রত্যাশিত এবং কোনও দিকেই কিছু প্রমাণ করে না।

যখন আর্টিফ্যাক্ট পুরোনো: বুটস্ট্র্যাপ আগে ব্যর্থ হয়

ক্লায়েন্টের চূড়ান্ত অবস্থার বদলে তার প্রকৃত ত্রুটি পড়ুন। আগ্রহের ক্ষেত্রগুলি হলো HTTPS ত্রুটি, ক্লায়েন্ট যে সার্ভার পরিচয় প্রত্যাশা করেছিল, অনুরোধটি যে গন্তব্যে গিয়েছিল, এবং সার্টিফিকেট যাচাই সম্পন্ন হয়েছে কি না। তারপর সেগুলোকে সার্ভার দিকের ওয়েব সেবা ও প্রক্সি লগের সঙ্গে মিলিয়ে দেখুন।

একটি ব্রাউজার লগইন পৃষ্ঠায় পৌঁছানো এই ক্লায়েন্টের API প্রমাণীকরণ সফল হয়েছে তার প্রমাণ নয়। এগুলো ভিন্ন অনুরোধ, ভিন্ন সার্টিফিকেট প্রত্যাশা এবং প্রায়ই ভিন্ন হোস্টনেম নিয়ে। পোর্টাল সঠিকভাবে পরিবেশিত হলেও ক্লায়েন্ট ব্যর্থ হলে, অমিলটি বুটস্ট্র্যাপ পথে, ব্যবহারকারীর পাসওয়ার্ডে নয়।

TLS যাচাই বন্ধ করে বা প্রমাণীকরণ নীতি শিথিল করে তুলনাটি সফল করবেন না। এটি একটি নির্ণয়যোগ্য কনফিগারেশন অমিলকে কাজ-করা-কিন্তু-অযাচাইকৃত পথে পরিণত করে, এবং ঠিক এই পরিবর্তনই একটি সাময়িক পরীক্ষাকে স্থায়ী ফাঁকে পরিণত করে। Access Server সংযোগ-প্রোফাইল নথি উভয় প্রজন্ম ও সাময়িক-প্রোফাইল প্রবাহ বর্ণনা করে, এবং প্রক্সিকে দোষী ধরে নেওয়ার আগে এটি যাচাই করার রেফারেন্স।

যখন আর্টিফ্যাক্ট নতুন: বরং কন্ট্রোল চ্যানেল পড়ুন

2.9-ধাঁচের প্রোফাইলে ক্লায়েন্ট সোজা নেটিভ VPN এন্ডপয়েন্টে যায়। প্রোফাইলের এন্ডপয়েন্ট, ব্যবহৃত ট্রান্সপোর্ট, এবং কন্ট্রোল-চ্যানেল ত্রুটি তদন্ত করুন। ক্লায়েন্ট যদি কখনও HTTP অনুরোধ না পাঠায়, তা নকশার সঙ্গে সামঞ্জস্যপূর্ণ, লক্ষণ নয়।

এখানেই প্রক্সি প্রশ্নটির আকৃতি বদলায়। একটি HTTPS অফলোড কেবল-TCP স্ট্রিম ভাঙতে পারে না যা সে কখনও দেখে না, তবে এটি প্রোফাইল প্রকাশকারী ডাউনলোড ভাঙতে পারে, এবং কেবল-TCP ফরওয়ার্ডার UDP একেবারেই বহন করবে না। ফ্রন্টএন্ড অপ্রাসঙ্গিক বলে সিদ্ধান্ত নেওয়ার আগে প্রোফাইল কোন ট্রান্সপোর্ট চায় তা দেখুন।

একটি একক স্ট্রিমের জন্য TLS পাসথ্রু একটি সংকীর্ণ বিন্যাস। এটি UDP ফরওয়ার্ডিং দেয় না, এবং 443-এ ডেমনটির নিজস্ব সেবা-ফরওয়ার্ডিং আচরণ পুনরুৎপাদন করে না। আপনার ফ্রন্টএন্ড এর একটি করে থাকলে বলুন কোনটি, কারণ প্রতিকার আলাদা।

সংকীর্ণ থাকা প্রতিকার

সবচেয়ে কম বিঘ্নকারী পরীক্ষা হলো একটি পরীক্ষামূলক অ্যাকাউন্টের জন্য নতুন সমর্থিত প্রোফাইল তৈরি করা এবং একই প্রমাণীকরণ প্রয়োজনীয়তা নিয়ে অভীষ্ট নেটিভ এন্ডপয়েন্ট দিয়ে সংযোগ করা। তা কাজ করলে এবং রক্ষিত পুরোনো প্রোফাইল না করলে, আপনি এক ধাপে আর্টিফ্যাক্টকে সার্ভার ও প্রক্সি থেকে আলাদা করেছেন।

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

তারপর প্রকাশনা বিন্যাস ঠিক করুন যাতে প্রতিটি প্রয়োজনীয় পথ থাকে: ডাউনলোড ও পোর্টাল ব্যবহারের জন্য ওয়েব পথ, এবং প্রোফাইল যে ট্রান্সপোর্ট প্রত্যাশা করে তার উপর নেটিভ VPN পথ। প্রক্সির কাজ এক স্তরে রাখুন। কাজ-করা ব্যবহারকারী-লক করা টানেল প্রমাণ করে সেই পথ কাজ করে; এটি প্রমাণ করে না প্রতিটি প্রক্সি বিন্যাস প্রতিটি প্রজন্ম সমর্থন করে, এবং পুরোনো বুটস্ট্র্যাপ ব্যর্থতা নতুন ফরম্যাটের নিন্দা করে না।

  • প্রক্সি স্পর্শ করার আগে আর্টিফ্যাক্টের প্রজন্ম চিহ্নিত করুন।
  • ব্যর্থতা টানেলের আগে ঘটে নাকি তার ভিতরে তা নির্ধারণ করুন।
  • ফ্রন্টএন্ড কী সমাপ্ত করে নিশ্চিত করুন: HTTP, TCP স্ট্রিম, বা UDP।
  • নীতি অপরিবর্তিত রেখে নতুন ইস্যু করা প্রোফাইল নেটিভ এন্ডপয়েন্টের বিরুদ্ধে পরীক্ষা করুন।

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