HAProxy 302 থেকে একটি ব্যক্তিগত অ্যাপ: দ্বিতীয় হপ কে খোলে?

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

কনফিগারেশনে একই রকম দেখানো দুটি পথ

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

GET /app        client -> proxy
302 Location    proxy  -> client   (http://10.40.0.20:8080/)
GET /app        client -> 10.40.0.20:8080   client network, no route

প্রক্সি ব্যাকএন্ড দ্বিতীয় ধাপটি সার্ভার পাশে রাখে। প্রক্সি ইতিমধ্যে যে পথ আছে তা দিয়ে এটি খোলে, আর ক্লায়েন্ট একটি পাবলিক নামেই কথা বলতে থাকে। টানেল পড়ে গেলে ক্লায়েন্ট এমন URL-এর বদলে ত্রুটি পায় যা সে অনুসরণ করতে পারে না। এই পার্থক্যই ব্যর্থতাকে নির্ণয়যোগ্য করে, কারণ ত্রুটি সেখানেই দেখা যায় যেখানে লগ থাকে:

GET /app        client -> proxy
GET /app        proxy  -> 10.40.0.20:8080   over the VPN
response        proxy  -> client

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

ব্রাউজারের যা দরকার আর সার্ভারের VPN যা তাকে দেয় না

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

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

যখন কেবল প্রক্সিই অ্যাপে পৌঁছাতে পারে

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

backend private_app
    mode http
    option httpchk GET /health
    server app1 10.40.0.20:8080 check

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

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

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

অ্যাপের নিজের রিডাইরেক্টগুলো এখনো ভিতরের দিকেই দেখায়

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

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

শুধু নির্ধারিত প্রক্সি থেকেই ফরোয়ার্ড করা মেটাডেটায় বিশ্বাস করুন। যে হেডার যেকোনো ক্লায়েন্ট সেট করতে পারে তা কখনোই অনুমোদনের মান হয়ে উঠতে পারে না, নইলে প্রক্সি কলকারীর জন্য অন্য কারো পরিচয় দাবি করার উপায় হয়ে যায়। এই নিয়মটি রিডাইরেক্ট প্রশ্ন থেকে স্বাধীন এবং পরবর্তী যেকোনো পুনঃনকশায় টিকে থাকে।

আপনার আসলে কোন ডিজাইন আছে তা ঠিক করুন

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

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

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

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