কর্পোরেট VPN-এর পেছনে অ্যাপের অনুরোধ ব্যর্থ হয়, কিন্তু ব্রাউজার কাজ করে

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

অ্যাপটি সত্যিই যে অনুরোধ পাঠায় সেটি দেখুন

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

env | grep -i proxy            # Linux/macOS
netsh winhttp show proxy       # Windows, machine-wide
curl -sv --noproxy '*' https://svc.internal/
nc -vz svc.internal 8080

শেষ দুটি একই গন্তব্যে চালান এবং দেখুন কোথায় তারা আলাদা হয়। কাজ করা ব্রাউজার যোগ কাজ করা curl যোগ যে অ্যাপ কাজ করে না—এটি সমস্যাটিকে অ্যাপ যা যোগ করে তার মধ্যে সংকুচিত করে: একটি প্রক্সি, একটি ট্রান্সপোর্ট, বা একটি বার্তার আকার।

অ্যাপটি এমন প্রক্সি উত্তরাধিকারে পেয়েছে যা কেউ কনফিগার করেনি

বেশিরভাগ HTTP স্ট্যাক ডিফল্টভাবে অপারেটিং সিস্টেম থেকে প্রক্সি কনফিগারেশন পড়ে। কর্পোরেট VPN ক্লায়েন্ট প্রায়ই তার অ্যাক্সেস প্রোফাইলের অংশ হিসেবে একটি ইনস্টল করে, তাই অনুরোধ এমন প্রক্সি দিয়ে বেরোয় যা ডেভেলপার কোডে কখনো উল্লেখ করেননি। .NET-এ ডিফল্ট হ্যান্ডলার IE/WinHTTP সেটিংস থেকে নেয়; Java পড়ে -Dhttp.proxyHost; Node-এ কোনো লাইব্রেরি যোগ না করা পর্যন্ত অন্তর্নির্মিত প্রক্সি সমর্থন নেই। ব্যর্থতা খুব কমই পরিষ্কার প্রত্যাখ্যান, তাই মানুষ সার্ভারের দিকে তাকাতে শুরু করে।

পরীক্ষাটি এক অনুরোধের খরচ: একটি হ্যান্ডলারে প্রক্সি স্পষ্টভাবে বন্ধ করুন এবং তুলনা করুন।

var handler = new HttpClientHandler { UseProxy = false };
using var client = new HttpClient(handler);

এটি সফল হলে সমাধান টানেলে নয়, অ্যাপের কনফিগারেশনে। প্রকল্পের প্রতিটি রানটাইমের জন্য নিরীক্ষাটি পুনরাবৃত্তি করুন, কারণ প্রতিটি আলাদা উৎস পড়ে এবং কেবল একটি-ই নষ্ট হতে পারে।

আপনি যে পোর্ট বেছেছেন সেটি নীতির অনুমোদিত পোর্ট নয়

রাউটেড হোস্ট মানে অনুমোদিত সার্ভিস নয়। কর্পোরেট নীতি সাধারণত বহির্গামী ওয়েব পোর্ট অনুমোদন করে বাকিগুলো ফেলে দেয়, তাই 8080 বা 1883-এ সার্ভিস পৌঁছানো যায় না, অথচ 443 ভালোই কাজ করে। ব্রাউজার এখানে কিছু প্রমাণ করে না: সে সংজ্ঞা অনুসারেই 443 ব্যবহার করে।

একই সার্ভিস 443-এর পেছনে প্রকাশ করুন এবং ব্যতিক্রম চাওয়ার আগে নাম দিয়ে সেখানে পৌঁছান। ব্যতিক্রম সত্যিই দরকার হলে তা এক উৎস-পরিসর ও এক গন্তব্যে সীমাবদ্ধ করুন এবং এটি কারও ব্যক্তিগত অস্থায়ী সমাধান নয়, সার্ভিস সংজ্ঞার অংশ হিসেবে ধরুন।

কাঁচা TCP যা পথ রিসেট করে

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

ট্রান্সপোর্ট বদলান, আবার পরীক্ষা করুন, আর একই ধাপে অন্য কিছু বদলাবেন না। এই এক-চলক পরীক্ষাই বলে দেয় রিসেটটি পথ থেকে এসেছে, না সার্ভিস থেকে।

যে সংযোগ কেবল বড় পেলোডে বন্ধ হয়

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

পেলোডটি অ্যাপ্লিকেশন স্তরে টুকরো করুন। এটি MTU-র কাজ থেকে আলাদা রাখুন: টানেলের প্যাকেট আকার কমানো তখন সাহায্য করে যখন সাধারণ TCP সেশন নির্দিষ্ট বাইট সংখ্যায় আটকে যায়, আর মধ্যস্থ যে বার্তাকে অতিরিক্ত বড় মনে করে তার জন্য এটি কিছুই করে না।

এক ধাপে চারটিকে কীভাবে আলাদা করবেন

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

প্রতি পরীক্ষায় একটি চলক রাখুন এবং আপনি যে গন্তব্য হোস্ট ব্যবহার করেছেন তা লিখে রাখুন। সেই ভিত্তিরেখা ছাড়া পরের ব্যক্তি চারটি ধাপই শুরু থেকে আবার করতে হবে।