libvirt অতিথির DNS মার্ক-ভিত্তিক VPN ফায়ারওয়াল দ্বারা ব্লক হওয়া ঠিক করুন

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

টানেল ওঠার মুহূর্তেই অতিথিরা DNS হারায়

কিছু বদলানোর আগে আকৃতিটি নিশ্চিত করুন। টানেল নামান, অতিথি থেকে dig @192.168.122.1 example.com চালান, এবং এটি উত্তর দিচ্ছে দেখুন। টানেল ওঠান, পুনরাবৃত্তি করুন, এবং এটি সময় শেষ করছে দেখুন। ফলাফলের এই জোড়া এক ধাপেই একটি ভাঙা libvirt নেটওয়ার্ক, ভুল রিজলভার ঠিকানা এবং মৃত dnsmasq বাদ দেয়।

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

কেন পরবর্তী চেইনের একটি accept নিয়ম কখনো কাজ করে না

মার্ক-ভিত্তিক VPN ফায়ারওয়াল প্যাকেট মার্ক বা সংযোগ মার্ক দেখে সিদ্ধান্ত নেয়, আপনার সোর্স ঠিকানা দেখে নয়। প্রত্যাশিত মার্ক ছাড়া ফিজিক্যাল ইন্টারফেসে আসা যেকোনো কিছু প্রত্যাখ্যাত হয়, এবং সেই প্রত্যাখ্যান ঘটে মার্ক পরীক্ষার মালিক নিয়ম-সেটে। পরবর্তী কোনো চেইনে যোগ করা একটি ip saddr 192.168.122.0/24 accept লাইন ওই প্যাকেটের জন্য কখনোই দেখা হয় না, তাই স্পষ্ট নিয়মটি সঠিক মনে হয় এবং কিছুই বদলায় না।

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

সংকীর্ণ ব্যতিক্রম সম্ভব করে যে ব্যবস্থাটি তা হলো সংযোগ ট্র্যাকিং। যখন আপনি একটি প্যাকেটে ct mark সেট করেন, মানটি শুধু প্যাকেটে নয়, conntrack এন্ট্রিতে সংরক্ষিত হয়, তাই ওই সংযোগের প্রতিটি প্যাকেট পরে এটি বহন করে, হোস্ট থেকে অতিথির কাছে উত্তরটিও সহ। এটাই পুরো কৌশল: অনুরোধটি একবার মার্ক করুন, এবং ফেরার পথ ইতিমধ্যে মার্ক করা।

VPN টেবিল এটি দেখার আগেই কুয়েরি মার্ক করুন

ব্যতিক্রমটি নিজস্ব টেবিলে রাখুন যাতে পরবর্তী পাঠক VPN নিয়ম বিশ্লেষণ না করেই এটি খুঁজে পান:

table inet allowedLocal {
  chain guest_dns {
    type filter hook input priority mangle; policy accept;
    ip saddr 192.168.122.0/24 meta l4proto { tcp, udp } \
      th dport 53 ct mark set 0x00000f41
  }
}

priority mangle ঋণাত্মক, যা এই চেইনটিকে VPN প্যাকেজ শূন্য অগ্রাধিকারে ইনস্টল করা সাধারণ ফিল্টার চেইনগুলোর আগে রাখে। হুকের ক্রমই নিয়মটিকে কার্যকর করে; VPN চেইনের পরে সাজানো চেইনে একই নিয়ম কেবল সাজসজ্জা।

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

গর্তটিকে পোর্ট 53-এর প্রস্থে রাখুন

যেমন লেখা আছে, এটি libvirt সাবনেট থেকে হোস্টে TCP বা UDP পোর্ট 53-এ DNS অনুমোদন করে এবং আর কিছু নয়। এটি অতিথিদের টানেলের বাইরে ইন্টারনেটে পৌঁছাতে দেয় না, এবং হোস্টকে অতিথিদের দিকে সংযোগ খুলতে দেয় না। যদি কোনো অতিথির পরবর্তীতে অন্য হোস্ট পরিষেবা দরকার হয়, এই নিয়মটি শিথিল করার বদলে সেই গন্তব্য পোর্টের নাম উল্লেখ করে আলাদা নিয়ম যোগ করুন।

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

এটিকে রিবুটে টিকে থাকতে দিন এবং দুই অর্ধকেই প্রমাণ করুন

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

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

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