আপনার VPN গেটওয়ের এখনো হালনাগাদ ইনস্টল করার একটি পথ দরকার

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

গেটওয়ে বন্ধ করা সঠিক। এটিকে এতটা কঠোরভাবে বন্ধ করা যে প্যাচ নেওয়া বন্ধ করে দেয়, সেটি ভিন্ন সিদ্ধান্ত, এবং সাধারণত অজান্তেই নেওয়া।

স্থানীয় আউটপুট ক্লায়েন্ট ফরওয়ার্ডিং নয়

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

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

ব্যর্থ হওয়া ধাপটির নাম দিন

হালনাগাদের ত্রুটি ভিন্ন ভিন্ন সীমার নাম বলে, এবং কোনটি ব্যর্থ হয়েছে তা পড়ার আগে পোর্ট নিয়মে ঝাঁপ দেওয়া একটি দুপুর নষ্ট করে। যে ভান্ডার নাম সমাধান হয় না সেটি resolver-এর প্রশ্ন, পরিবহনের প্রশ্ন নয়।

getent hosts deb.debian.org
curl -sSI https://deb.debian.org/debian/dists/stable/Release | head -n 1
apt-get -o Debug::Acquire::https=true update

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

নিয়ম যোগ করার আগে উৎস তালিকা পড়ুন

মনে থাকা উৎসের বদলে প্রকৃত উৎস URI এবং কার্যকর প্রক্সি কনফিগারেশন তালিকাভুক্ত করুন। সাধারণ HTTP-এর জন্য লেখা নিয়ম অকেজো যখন উৎস HTTPS হয়, এবং শেল যে প্রক্সি জানে তা বুটের সময় ভিন্ন পরিবেশে চালু হওয়া সেবার কাছে অদৃশ্য হতে পারে।

APT-তে HTTP পরিবহনের নথি পরিবেশগত এবং APT-নির্দিষ্ট প্রক্সি সেটিংস কভার করে, প্রতিটি হোস্টের জন্য পছন্দসহ, এবং এর HTTPS পরিবহনের নিজস্ব যাচাই সেটিংস আছে। ব্রাউজারের পথ এবং প্যাকেজ ম্যানেজারের পথ আলাদা পথ, একই মেশিনেও।

উৎসগুলি কোন ঠিকানা পরিবারে সমাধান হয় লক্ষ্য করুন। কেবল IPv4 অনুমোদনকারী নিয়ম এমন হোস্টে ব্যর্থ হতে থাকবে যার উৎস AAAA রেকর্ড পছন্দ করে, এবং ত্রুটিটি মাঝে মাঝে দেখা দেওয়ার মতো লাগে কারণ এটি কোন উত্তর আগে আসে তার উপর নির্ভর করে।

রক্ষণাবেক্ষণের একটি পথ বেছে নিন এবং তা ধরে রাখুন

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

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

যাচাই দুর্বল না করেই যাচাই করুন

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

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

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