VPN ও ওয়েবের জন্য একটি পাবলিক হোস্ট: ভূমিকাগুলো কীভাবে আলাদা করবেন

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

নিচেরটি একটি সিদ্ধান্তের প্রক্রিয়া, নির্মাণের ছক নয়। প্রতিটি ধাপ শেষ হয় এমন যাচাই দিয়ে যা প্রমাণ করে আপনি এইমাত্র যে ভূমিকা যোগ করেছেন তা সত্যিই বিচ্ছিন্ন।

পোর্টের আগে ঠিকানার মালিক নির্বাচন করুন

একটি টানেল এন্ডপয়েন্ট এবং একটি ওয়েব সার্ভার একটি কার্নেল শেয়ার করতে পারে; একই সময়ে একটি ঠিকানা, পোর্ট ও প্রোটোকল শেয়ার করাই হলো যা ব্যর্থ হয়। WireGuard সাধারণত UDP 51820 নেয়, OpenVPN UDP 1194 বা TCP 443 নেয়, আর একটি ওয়েব সার্ভার TCP 443 নেয়। যে জোড়াটি কষ্ট দেয় তা হলো HTTPS-এর পাশে TCP 443-এর উপর OpenVPN, কারণ দুটোই একই সকেট চায় এবং কার্নেল এটি প্রথমে বাইন্ড করা প্রক্রিয়াকে দেয়। শুধু সামনে থাকা একটি ডিমাল্টিপ্লেক্সার, যেমন sslh বা TLS-সচেতন প্রক্সি, তাদের সেই পোর্ট শেয়ার করতে দেয়, আর এটি এমন একটি উপাদান যোগ করে যার ব্যর্থতা হুবহু ফায়ারওয়াল সমস্যার মতো দেখায়।

যেকোনো কিছু পরিবর্তনের আগে মালিকদের দেখুন: ss -lntup প্রতিটি শোনা সকেটের স্থানীয় ঠিকানা, পোর্ট ও প্রক্রিয়া দেখায়। দুটি সারিতে 0.0.0.0:443 দেখা মানে দ্বিতীয় সেবাটি কখনো বাইন্ড হয়নি, তার init স্ক্রিপ্ট যতই উৎসাহী হোক। ব্রিজিং মালিককেও সরায়। যখন eth0 যোগ দেয় br0-এ, IP চলে যায় br0 এবং প্রতিটি ফায়ারওয়াল নিয়ম যা eth0 উল্লেখ করে তা আর মেলে না, তাই সেবাগুলো ব্রিজে বাইন্ড করুন এবং এটি দিয়ে নিশ্চিত করুন: ip -br addr।

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

দুটি LAN-এর মধ্যে রাউট করা বা এক পাশে NAT করা

যে দুটি LAN একে অপরকে দেখতে পায় না, তারা প্রত্যেকে পাবলিক হোস্টে ডায়াল করতে পারে, যা পরে টানেলগুলোর মধ্যে ফরওয়ার্ড করে। সেই রাউটেড নকশার জন্য তিনটি জিনিস দরকার: ফরওয়ার্ডিং চালু, প্রতিটি দূরবর্তী প্রিফিক্সের দিকে একটি রুট, এবং একটি ফরওয়ার্ড নীতি যা ট্রানজিটকে অনুমতি দেয়। sysctl -w net.ipv4.ip_forward=1 প্রথমটি ঢাকে, ip route add 10.20.0.0/24 dev wg1 দ্বিতীয়টি, এবং nftables-এর এমন একটি লাইন nft add rule inet filter forward iifname "wg0" oifname "wg1" accept তৃতীয়টি।

সোর্স NAT জুড়ে দেওয়া সহজ, ডিবাগ করা কঠিন। মাস্করেডিং ক্লায়েন্টের ঠিকানা পুনর্লিখন করে, তাই দূরের পক্ষ সত্যিকারের হোস্টের বদলে হাব দেখে, এবং তার অ্যাক্সেস নিয়ম ও লগ আর দায় নির্ধারণে কাজে আসে না। যখন দুটি নেটওয়ার্কই আপনার, রাউট করুন। যখন এক পক্ষ এমন তৃতীয় পক্ষের যারা ফেরত রুট যোগ করবে না, তখন NAT হলো এই সপ্তাহে সরবরাহযোগ্য বিকল্প। যেভাবেই হোক, ঠিকানা পরিকল্পনা লিখে রাখুন, কারণ দুটি ওভারল্যাপিং /24 কোনো পরিমাণ কনফিগারেশন দিয়েই রাউট করা যায় না।

ল্যাপটপের জন্য ইন্টারনেট এক্সিট হিসেবে কাজ করা একই বক্সকে অন্তর্মুখী টানেল সমাপ্ত করা থেকে বিরত করে না। কেবল ওভারল্যাপিং ঠিকানাই তা করে, তাই ঠিকানা পরিকল্পনাই সেই নথি যা গুরুত্বপূর্ণ।

দুটি ভূমিকা বন্ধ থাকা অবস্থায় বিভাজন পরীক্ষা করুন

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

তিনটি কমান্ড সেই পরীক্ষাকে মূর্ত করে। curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ প্রমাণ করে স্থানীয় লিসেনার বাহ্যিক DNS ছাড়াই উত্তর দেয়, wg show ক্লায়েন্টে প্রমাণ করে হ্যান্ডশেক সম্পন্ন হয়েছে, এবং tcpdump -ni any port 51820 হাবে রাউটিং সমস্যাকে কী সমস্যা থেকে আলাদা করে। যে হ্যান্ডশেক ক্যাপচারে কখনো দেখা যায় না তা হোস্টের আগেই মারা গেছে: প্রদানকারীর ফায়ারওয়াল, ভুল পাবলিক ঠিকানা, বা পথে একটি NAT নিয়ম।

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

ভূমিকা বিয়োগ করার সময় নিয়মের সেটটি পাঠযোগ্য রাখুন। nft list ruleset আপনার সত্যিই প্রয়োজনীয় প্রতিটি দিকের জন্য একটি accept নিয়ম দেখানো উচিত, আর সবকিছু গ্রহণ করা একটি forward চেইন বিচ্ছিন্নতা নয়, এটি একটি চালু ডেমো।

শুধু IPv6 অ্যাক্সেস লাইন এবং IPv4 সেবা

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

প্রতিটি পরিবার আলাদাভাবে পরীক্ষা করুন curl -4 এবং curl -6 দিয়ে, কারণ একটি সফল অনুরোধ আপনি যে পথ চেষ্টা করেননি সে সম্পর্কে কিছুই বলে না। পোর্টের মালিকানা পরিবার বদলালেও বদলায় না, কিন্তু লিসেনার বদলায়: ss -lntup IPv4 ও IPv6 সকেটকে আলাদা সারি হিসেবে দেখায়, এবং 0.0.0.0:443 ঢাকে না [::]:443 যদি না প্রক্রিয়াটি ডুয়াল-স্ট্যাক সকেট চেয়েছে।

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