Squid একটি CONNECT অনুরোধের উত্তর দেয় প্রথম http_access লাইন দিয়ে যা মেলে, এবং সেই লাইনটি অস্বীকৃতিও হতে পারে। এই একটি তথ্যই ব্যাখ্যা করে কেন একটি VPN এন্ডপয়েন্ট ব্যতিক্রম সাধারণত প্রথম চেষ্টাতেই ব্যর্থ হয়, কারণ অনুরোধটি কেউ নিচে যোগ করা অনুমোদন পর্যন্ত কখনও পৌঁছায় না। একটি সংকীর্ণ সমাধান বিদ্যমান পোর্ট গার্ড ধরে রাখে এবং সেগুলোকে একটি পর্যালোচিত উৎস, গন্তব্য ও পোর্ট সম্পর্কে শেখায়। প্রক্সির বাকি সবকিছু আগের মতোই আচরণ করে।

Squid কীভাবে একটি CONNECT অনুরোধের সিদ্ধান্ত নেয়

একটি CONNECT অনুরোধ একটি হোস্ট ও একটি পোর্টের নাম দেয়, আর Squid http_access লাইনগুলো ক্রম অনুসারে চালিয়ে যায় যতক্ষণ না তাদের একটি মেলে। মিলে যাওয়া একটি অস্বীকৃতি মূল্যায়ন সঙ্গে সঙ্গে শেষ করে এবং ক্লায়েন্ট প্রক্সি থেকে 403 পায়। এ কারণেই একটি নিয়মের অবস্থান তার ভাষ্যের চেয়ে বেশি গুরুত্বপূর্ণ। একই লাইন এক ধাপ উপরে সরালে ফলাফল সম্পূর্ণ বদলে যেতে পারে।

প্রচলিত গার্ডগুলো Safe_ports-এর বাইরের সবকিছু অস্বীকার করে এবং SSL_ports-এর বাইরে CONNECT অস্বীকার করে। এই নামগুলো আপনার নিজের কনফিগারেশনে সংজ্ঞায়িত ACL, তাই তাদের বিষয়বস্তু প্রোটোকলের নয়, আপনার। একটি ডিস্ট্রিবিউশন Safe_ports হিসেবে বিস্তৃত পোর্ট পরিসর অনুমোদন করে CONNECT আলাদাভাবে সীমিত করতে পারে। কোনো পোর্ট ডিজাইন অনুযায়ী অবরুদ্ধ বলে ধরে নেওয়ার আগে জীবন্ত মানগুলো পড়ুন।

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

তিনটি আলগা ACL-এর বদলে একটি সম্মিলিত মিল তৈরি করুন

ব্যতিক্রমটি তিনটি তথ্য থেকে গড়ুন: একটি অনুমোদিত উৎস পরিসর, একটি অনুমোদিত গন্তব্য ঠিকানা এবং এন্ডপয়েন্ট যে একক পোর্টে শোনে সেটি। দুটি আলগা ACL আর একটি সম্মিলিত মিল খুব ভিন্ন নীতি তৈরি করে, কারণ মূল্যায়ন হয় সমন্বয়টির। সম্মিলিত ACL-এর নাম দিন এটি যা অনুমোদন করে তার ভিত্তিতে, এটি যে পদ্ধতি বহন করে তার ভিত্তিতে নয়।

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

acl pvpn_src src 192.0.2.128/25
acl pvpn_dst dst 198.51.100.77/32
acl pvpn_port port 1194
acl pvpn_ok all-of CONNECT pvpn_port pvpn_dst pvpn_src

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

পোর্ট গার্ড সরিয়ে না দিয়ে নমনীয় করুন

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

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

প্রতিটিতে নঞর্থক সম্মিলিত মিলটি যোগ করুন, যাতে একটি মেলা ব্যতিক্রম এমন একটি গার্ড থেকে বেঁচে যায় যা অন্যথায় এটি অস্বীকার করত। কেবল গার্ড লাইনগুলোই বদলায়, এবং প্রতিটিতে কেবল একটি অতিরিক্ত পদ যুক্ত হয়।

http_access deny CONNECT !SSL_ports !pvpn_ok
http_access deny !Safe_ports !pvpn_ok

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

ব্যতিক্রমটি কোথায় রাখা যাবে না

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

পোর্ট গার্ডের পরে অনুরোধটির আর কী দরকার তা যাচাই করুন। প্রমাণীকৃত অ্যাকাউন্ট, অনুমোদিত ক্লায়েন্ট ঠিকানা ও গন্তব্য নীতি—সবই এখনও প্রযোজ্য, এবং ব্যতিক্রম এদের কোনোটিই বদলায় না। আপনার প্রক্সি যদি অনুমোদিত অ্যাকাউন্টকে ইতিমধ্যেই ইচ্ছামতো গন্তব্যে পৌঁছাতে দেয়, তবে পোর্ট গার্ডটিই কখনও আসল নিয়ন্ত্রণ ছিল না।

এন্ডপয়েন্টটি আদৌ TCP কি না তা ভাবুন। একটি CONNECT ব্যতিক্রম TCP স্ট্রিম বহন করে, আর UDP ব্যবহার করা OpenVPN প্রোফাইল এর মধ্য দিয়ে পৌঁছনো যাবে না। প্রোফাইলটি TCP-তে বদলান কেবল যদি সার্ভার সেভাবেই শোনে এবং অপারেটর আচরণের পার্থক্য মেনে নেন।

পার্সার ও একটি বাস্তব অনুরোধ দিয়ে সীমা যাচাই করুন

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

তারপর পুনরায় লোড করুন এবং একটি অনুমোদিত উৎস থেকে প্রক্সি দিয়ে একটি বাস্তব CONNECT পাঠান। পার্সার চালানো আগে আসে, কারণ টাইপো থাকা পুনরায় লোড নীতি সম্পর্কে আপনাকে কিছুই শেখায় না।

squid -k parse
squid -k reconfigure
curl -v -p -x http://proxy.lab.internal:3128 https://vpn.lab.internal:1194/ --max-time 5

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

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