কর্পোরেট VPN-এ কনটেইনার HTTPS আটকে যায়? DTLS অংশটি পরীক্ষা করুন

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

দুটি ট্রান্সপোর্ট, একটি বিভ্রান্তিকর উপসর্গ

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

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

অনুভূতিতে নয়, পরীক্ষায় সিদ্ধান্ত নিন

সবচেয়ে সস্তা পরীক্ষা UDP ডেটা চ্যানেল বন্ধ করে অনুরোধটি পুনরাবৃত্তি করে। ডেস্কটপ র‍্যাপারের বদলে কমান্ড-লাইন ক্লায়েন্ট ব্যবহার করুন, যাতে ফ্ল্যাগটি সত্যিই প্রয়োগ হয়: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls। আটকে থাকা অনুরোধটি যদি এখন সম্পন্ন হয়, তাহলে DTLS অংশটিই সমস্যা ছিল আর বাকিটা কোলাহল।

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

ফ্ল্যাগ সমস্যা ঠিক করলে, কারণ নির্ধারণ করুন

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

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

ওয়ার্কঅ্যারাউন্ড রাখার আগে প্যাকেটের আকার যাচাই করুন

আকারই কারণ হলে, টানেল ইন্টারফেস এমন প্যাকেট গ্রহণ করে যা পথ বহন করতে পারে না, আর পেলোড বাড়লেই সমস্যা যেকোনো ট্রান্সপোর্টে ফিরে আসে। ইন্টারফেসগুলো তুলনা করুন: হোস্টে ip link show tun0, তারপর নেটওয়ার্ক অপশনে রেকর্ড করা MTU পড়তে docker network inspect bridge। কম বহনকারী টানেলের নিচে এখনও 1500 বাইটে থাকা কনটেইনার ব্রিজই স্বাভাবিক ফলাফল।

টানেলের ভিতরে ডু-নট-ফ্র্যাগমেন্ট পরীক্ষা দিয়ে জানা-ভালো আকার থেকে উপরে প্রোব করুন, তারপর কনটেইনার নেটওয়ার্কের MTU কমান অথবা টানেলে TCP MSS ক্ল্যাম্প করুন। দুই সংশোধনের যেকোনোটি প্রায়ই UDP পথ আবার ব্যবহারযোগ্য করে তোলে এবং ফ্ল্যাগের প্রয়োজন মেটায়, যা ফিল্টারিং কারণ না হলে ভালো ফল।

কী বিনিময় করতে রাজি, তা ঠিক করুন

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

যে বিকল্পই বেছে নিন, টানেল শেষে কোন ট্রান্সপোর্ট ব্যবহার করেছে এবং কেন, তা লিখে রাখুন। কেউ মাসখানেক আগে যোগ করা ফ্ল্যাগের উপর নিঃশব্দে নির্ভর করা কনটেইনারই পরবর্তী বিভ্রাট, আর যে এটি ডিবাগ করবে সে জানবে না ফ্ল্যাগটি ফিল্টারিংয়ের ওয়ার্কঅ্যারাউন্ড ছিল, নাকি MTU পরীক্ষার অবশিষ্ট।