SSH লোকাল ফরোয়ার্ড থেকে বিদ্যমান HTTP প্রক্সি: দুটি loopback ঠিকানা

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

নির্দিষ্ট প্রক্সি আগে থেকেই আছে কি না তা ঠিক করুন

এই কৌশল এমন একটি সেবা ফরোয়ার্ড করে যা ইতিমধ্যে চলছে। রিমোট হোস্টে যদি কেবল একটি SSH ডেমন থাকে এবং প্রক্সি না থাকে, তবে যতই ফরোয়ার্ড করুন একটি তৈরি হবে না, এবং সংযোগটি রিমোট দিক থেকে প্রত্যাখ্যাত হবে। প্রক্সিটি বাঁধা আছে কি না, তার পোর্ট কী, এবং এটি 127.0.0.1-এ শোনে কি না বা নির্দিষ্ট ইন্টারফেস ঠিকানায় শোনে, তা নিশ্চিত করুন, কারণ ফরোয়ার্ডকে সেই ঠিকানাই লক্ষ্য করতে হবে।

এটি আগে নিশ্চিত করলে এমন একটি টানেল ডিবাগ করা থেকে বাঁচবেন যা কখনো কিছুর সঙ্গে যুক্তই ছিল না।

ফরোয়ার্ড তৈরি করুন ও কমান্ড পড়ুন

আপনার দরকারি রূপটি আপনার ল্যাপটপে একটি loopback পোর্ট বাঁধে এবং সার্ভারের দিক থেকে এটি প্রক্সির ঠিকানার সঙ্গে যুক্ত করে, যেমন সার্ভার সেটি দেখে।

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

-N একটি রিমোট কমান্ড দমন করে এবং -T termios বরাদ্দ দমন করে, কারণ আপনার দরকার টানেল, শেল নয়। প্রথম loopback ঠিকানাটি যেখানে ল্যাপটপ শোনে; দ্বিতীয়টি SSH সার্ভার থেকে সমাধান হয়, তাই সেখানে 127.0.0.1 মানে ওই মেশিনের প্রক্সি। ExitOnForwardFailure স্থানীয় পোর্ট আগেই দখলে থাকলে কমান্ডটিকে জোরে ব্যর্থ করে, কিছু না ফরোয়ার্ড করা সেশন শুরু করার বদলে। লক্ষ্য ঠিকানাটি সার্ভার যেভাবে সমাধান করে সেভাবে লিখুন, কারণ যে নাম কেবল আপনার ল্যাপটপ সমাধান করতে পারে তা অন্যপ্রান্তে ব্যর্থ হবে।

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

একটি অ্যাপ্লিকেশনকে ফরোয়ার্ডে নির্দেশ করুন

http://127.0.0.1:13128-এ HTTP প্রক্সি ব্যবহার করতে অ্যাপ্লিকেশনটি কনফিগার করুন, রিমোট প্রক্সির প্রয়োজন হলে শংসাপত্রসহ। HTTPS গন্তব্যের জন্য অ্যাপ্লিকেশনের নিজস্ব শংসাপত্র যাচাই রাখুন, কারণ প্রক্সি টানেল তা প্রতিস্থাপন করে না। এটি একটি সেবার স্থির ফরোয়ার্ড, তাই অ্যাপ্লিকেশনকে প্রক্সি সম্পর্কে জানাতে হবে, তাকে নিজে আবিষ্কার করতে ছাড়া যাবে না।

স্থায়ী কিছু কনফিগার করার আগে দ্রুত পরীক্ষা: curl -x http://127.0.0.1:13128 -I https://example.com, যা প্রক্সিকে যে HTTP CONNECT পদ্ধতি সমর্থন করতে হবে তা প্রয়োগ করে।

কর্তৃত্ব যেখানে ছিল সেখানেই রাখুন

রিমোট প্রক্সি এখনো ঠিক করে কোন গন্তব্য ও পদ্ধতি অনুমোদন করে, এবং একটি SSH লগইন প্রতিটি অ্যাকাউন্টকে নীরবে সাধারণ ওয়েব রিলে দেওয়া উচিত নয়। ল্যাপটপে 127.0.0.1-এ বাঁধলে পোর্টটি আপনার স্থানীয় নেটওয়ার্কে প্রকাশ করা এড়ানো যায়, এবং এটি একই মেশিনের অন্য প্রক্রিয়া থেকে পোর্টকে ব্যক্তিগত করে না। প্রক্সি ভাগ করতে সেই বাঁধনকে wildcard ঠিকানা দিয়ে প্রতিস্থাপন করাই অনিয়ন্ত্রিত উন্মুক্ত রিলে তৈরির উপায়।

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

দুই প্রান্ত যাচাই করুন, তারপর পরিষ্কার করুন

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

শেষ হলে মালিক SSH প্রক্রিয়াটি থামান, অ্যাপ্লিকেশন থেকে প্রক্সি সেটিং সরান, এবং কাজের চেয়ে বেশি বাঁচবে এমন শ্রবণকারী রেখে না গিয়ে স্থানীয় পোর্টটি চলে গেছে তা নিশ্চিত করুন।