VPN পুনরায় সংযোগের পরে প্রক্সি কি এখনও পুরোনো টানেল ঠিকানায় আছে?
পুনরায় সংযোগ আপনার ফরওয়ার্ডারকে এমন ঠিকানায় বাঁধা রেখে যেতে পারে যা আর টানেলের নয়। চারটি ক্রমিক পরীক্ষা, একটি নম্বরযুক্ত হস্তান্তর এবং একটি বাস্তব পরীক্ষামূলক অনুরোধ।
VPN ক্লায়েন্ট পুনরায় চালু করা শুধু প্রমাণ করে যে টানেল ফিরে এসেছে। এটি সেই প্রক্সি সম্পর্কে কিছুই বলে না, যাকে তার মধ্য দিয়ে বের হওয়ার নির্দেশ দেওয়া হয়েছিল। Squid, tinyproxy এবং বেশিরভাগ অন্য ফরওয়ার্ডার শুরুতে যে স্থানীয় উৎস ঠিকানা নির্ধারণ করেছিল তা ধরে রাখে, যতক্ষণ না কিছু তাদের পুনরায় লোড করতে বাধ্য করে। পুনরায় সংযোগ নতুন টানেল ঠিকানা দিলে ফরওয়ার্ডার হয় প্রতিটি বহির্গামী সংযোগে ব্যর্থ হয়, নয়তো আপনার সাধারণ রুট দিয়ে বের হতে শুরু করে।
দ্বিতীয় ব্যর্থতাটিই বিপজ্জনক: টানেল চালু, পাতা লোড হচ্ছে, শুধু প্রস্থান ঠিকানাটাই ভুল।
টানেল দিয়ে নয়, লিসেনার দিয়ে শুরু করুন
খেলায় তিনটি ঠিকানা আছে, আর পুনরায় সংযোগ তার কয়েকটিকেই সরায়। লিসেনার হলো যেখানে আপনার ব্রাউজার নির্দেশ করে, সাধারণত 127.0.0.1 বা একটি LAN ঠিকানা, এবং টানেল বদলেছে কি না তা নিয়ে তার কিছু যায় আসে না। বহির্গামী স্থানীয় উৎস হলো যা ফরওয়ার্ডার পরের হপে ডায়াল করার সময় কার্নেলকে ব্যবহার করতে বলে, এবং তা টানেল ডিভাইসের সাথে বাঁধা। আর পাবলিক প্রস্থান হলো যা একটি ওয়েব সার্ভার লগ করে, যা কয়েক হপ দূরের অনূদিত ঠিকানা হতে পারে।
পাবলিক IP খোঁজা শুধু শেষ প্রশ্নের উত্তর দেয়। এটি বলতে পারে না কোন স্থানীয় ঠিকানায় ফরওয়ার্ডারের বাঁধা উচিত, কারণ একটি পাবলিক প্রস্থান একাধিক অভ্যন্তরীণ উৎস লুকাতে পারে। ঠিকানাটি পড়ুন তার কাছ থেকে যার সংযোগটির মালিকানা আছে: ক্লায়েন্টের স্ট্যাটাস আউটপুট, ইন্টারফেস নিজেই, বা যে নেমস্পেসে টানেল থাকে। নাম দেখতে টানেলের মতো এমন প্রথম ইন্টারফেস ধরা দ্বিতীয় প্রোফাইল থাকলেই ভুল উত্তর দেয়।
কন্টেইনার ও নেমস্পেস বিন্যাস এই অনুমানটি নিঃশব্দে ভেঙে দেয়। এক নেটওয়ার্ক নেমস্পেসের ফরওয়ার্ডার অন্য নেমস্পেসে থাকা টানেলে বাঁধতে পারে না, আর কনফিগারেশন সম্পাদনার কোনো পরিমাণই তা সারায় না।
কিছু সম্পাদনার আগে চারটি পরীক্ষা
এগুলো ক্রম অনুসারে করুন। যে পরীক্ষাটি প্রথমে ব্যর্থ হয় সেখানেই থামুন, কারণ পরেরগুলো আগেরগুলো সত্য ধরে নেয়।
- নিশ্চিত করুন যে ব্যবহৃত টানেলটি সেই প্রোফাইল যার জন্য প্রক্সি তৈরি হয়েছিল, নিজে থেকে সংযুক্ত হওয়া দ্বিতীয় প্রোফাইল নয়।
- ওই ডিভাইসে এখন যে ঠিকানা আছে তা প্রিন্ট করুন এবং চলমান কনফিগারেশনের ঠিকানার সাথে তুলনা করুন।
- ডিস্কের ফাইল যা দাবি করে তা নয়, ফরওয়ার্ডারকেই জিজ্ঞাসা করুন সে কোন উৎস নির্ধারণ করেছে।
- নিশ্চিত করুন যে ফরওয়ার্ডার থেকে আসা ট্রাফিক সত্যিই আপনার প্রত্যাশিত রাউটিং ও ফায়ারওয়াল নীতির অধীন।
ডিভাইসের ঠিকানা সহজ: ip -4 addr show dev tun0 বর্তমানটি প্রিন্ট করে, আর ip -4 route get 1.1.1.1 দেখায় কার্নেল ওই গন্তব্যের জন্য কোন ইন্টারফেস বেছে নেবে। যে ফরওয়ার্ডার নির্দিষ্ট ঠিকানায় বাঁধে, ঠিকানাটি হারিয়ে গেলে সে জোরালোভাবে ব্যর্থ হয়। যে ফরওয়ার্ডার ডিভাইসে বাঁধে, বা ডিফল্ট উৎসে ফিরে যায়, সে কাজ করতে থাকে ও ফাঁস করে, আর এটাই নিঃশব্দ পরিণতি।
ডকুমেন্টেশন মেলান আপনি যে সংস্করণ চালান তার সাথে, শীর্ষ সার্চ ফলাফলের সাথে নয়। Squid-এর আউটগোয়িং-ঠিকানা নির্দেশিকাটি v7 এবং আগের জন্য নথিভুক্ত, আর v8 ডকুমেন্টেশন স্পষ্ট বলে সেখানে নির্দেশিকাটি নেই, তাই এটি ঘিরে গড়া স্ক্রিপ্ট ওই সীমা পেরোয় না (দেখুন Squid tcp_outgoing_address রেফারেন্স)। কিছু পুনরায় লোড করার আগে পণ্যের নিজের পার্সার দিয়ে যাচাই করুন: squid -k parse ত্রুটি জানায় এবং চলমান প্রক্রিয়া স্পর্শ না করেই বেরিয়ে যায়।
প্রতিটি টানেল নম্বর করুন এবং পুরোনো বদল বাতিল করুন
পুনরায় সংযোগ একটি হস্তান্তর, আর হস্তান্তরের ক্রম দরকার। প্রতিটি পর্যবেক্ষিত সংযোগে একটি কাউন্টার বা টাইমস্ট্যাম্প দিন যা প্রতিটি সফল প্রতিষ্ঠায় বাড়ে, তারপর সেই ট্যাগ প্রার্থী কনফিগারেশনের ভিতরে বহন করুন। প্রার্থীর ট্যাগ বর্তমানের চেয়ে পুরোনো হলে প্রয়োগ না করে প্রার্থীটি ফেলে দিন, কারণ আগের টানেলের জন্য লেখা ধীরগতির হালনাগাদ অন্যথায় বর্তমানের সেটিংস মুছে দেবে। ঘটনার ঝাঁক একত্র করুন যাতে দোলায়মান লিঙ্ক পনেরোটির বদলে একটিমাত্র রূপান্তর দেয়।
কাজটি চার ধাপে সাজান: পুরোনো ইগ্রেস অবস্থা অকার্যকর করুন, সংযোগের মালিকের সম্পন্নতার প্রতিবেদনের জন্য অপেক্ষা করুন, শুধু ব্যবস্থাপিত অংশটি তৈরি করুন, তারপর সেবা ব্যবস্থাপকের মাধ্যমে যাচাই ও সক্রিয় করুন। দুটি ঠিকানা মান থেকে পুরো ফাইল পুনরায় তৈরি করাই হলো লিসেনার নিষেধাজ্ঞা, প্রমাণীকরণ ও গন্তব্য নীতি নিঃশব্দে হারিয়ে যাওয়ার উপায়। ইচ্ছাকৃত বন্ধকেও সম্মান করুন। ব্যবহারকারীর বন্ধ করা টানেলে বারবার ডায়াল করা সহায়ক সহনশীলতা নয়, বরং ত্রুটি।
খোলা সকেট নতুন ঠিকানা অনুসরণ করবে না
ফরওয়ার্ডার পুনঃকনফিগার করা ইতিমধ্যে প্রতিষ্ঠিত সংযোগ সম্পর্কে কিছুই বলে না। সেগুলো নিঃশেষ হবে না মরবে তা পণ্যের উপর নির্ভর করে, তাই ধরে নেওয়ার বদলে আচরণ পর্যবেক্ষণ করুন।
বদলের আগে খোলা সকেটে পরিবেশিত অনুরোধ নতুন কনফিগারেশন সঠিক হলেও পুরোনো পথ দিয়েই বের হয়। এটি গুরুত্বপূর্ণ হলে স্পষ্ট সিদ্ধান্ত নিন: সংক্ষিপ্ত নিঃশেষণ উইন্ডো দিন এবং নতুন কাজ গ্রহণ বন্ধ করুন, অথবা পুরোনো সকেট বন্ধ করুন এবং ত্রুটিগুলো মেনে নিন। তারপর নতুন সংযোগ দিয়ে পরীক্ষা করুন এবং সেই ফলাফল নিঃশেষণ পরীক্ষা থেকে আলাদা রাখুন। উৎসে বাঁধাও নিরাপত্তার সীমা নয়। যখন ট্রাফিক কখনোই সাধারণ রুট স্পর্শ করবে না, তখন চিহ্ন ও ফায়ারওয়াল নিয়ম দিয়ে তা বলবৎ করুন, DNS ও IPv6 সহ, যাতে ব্যর্থ পুনঃলোড প্রক্সিকে খোলা না রেখে স্পষ্টভাবে বন্ধ রাখে।
নতুন ইগ্রেস প্রমাণ করুন একটি নতুন অনুরোধ দিয়ে
গুরুত্বপূর্ণ হলো সক্রিয়করণের পরে খোলা অনুরোধ, ping নয় এবং আগেই ক্যাশ করা পাতা নয়। প্রক্সিকে একটি বাস্তব URL চান এবং দূর প্রান্ত যে প্রস্থান ঠিকানা জানায় তা পড়ুন, তারপর প্রদানকারী একটি দেখালে ক্লায়েন্টের নিজের টানেল-দৃষ্টিভঙ্গির সাথে তুলনা করুন।
পার্স, পুনঃলোড ও অনুরোধকে আলাদা কমান্ড রাখুন যাতে ব্যর্থতা একটিমাত্র ধাপ দেখায়। প্রথম দুটি ব্যর্থ হলে কিছুই বদলায় না, আর ঠিক সেজন্যই এগুলো পুনরায় চালুর আগে চলে।
squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.comপুনঃলোড ব্যর্থ হলে সেবা বন্ধ করুন এবং অংশটি ঠিক করুন; পুরোনো ইগ্রেস দিয়ে সেবা দেওয়া প্রক্সি সংক্ষিপ্ত বিভ্রাটের চেয়েও খারাপ। পুনঃলোড সফল হলেও নতুন অনুরোধ অপ্রত্যাশিত জায়গা দিয়ে বের হলে আবার ঠিকানা সম্পাদনার বদলে রাউটিং পরীক্ষায় ফিরুন। যে টানেল প্রজন্মের বিপরীতে যাচাই করেছেন তা লিপিবদ্ধ করুন, যাতে পরের পুনঃসংযোগের তুলনার জন্য নির্দিষ্ট কিছু থাকে।