একটি পাবলিক গেটওয়ে ইতিমধ্যেই UDP 51820-এ WireGuard, 22-এ SSH এবং ইন্টারনেট থেকে পৌঁছাতে হবে এমন একটি অ্যাপ্লিকেশন চালাচ্ছে। লোভনীয় নিয়মটি প্রতিটি পোর্ট পিয়ারে ফরোয়ার্ড করে কাজ শেষ বলে ধরে নেয়। WireGuard গেটওয়েতে সেই নিয়ম টানেলের নিজের ট্রান্সপোর্ট ধরে ফেলতে পারে এবং যে মেশিন টানেলটি শেষ করে সেখান থেকে আপনাকে লক আউট করতে পারে। প্রকাশনা হলো কন্ট্রোল প্লেন ব্যতিক্রমসহ একটি রাউটিং সিদ্ধান্ত, একটি DNAT লাইন নয়।

পাবলিক এন্ট্রি, টানেল এন্ট্রি: একটি বেছে নিন

একটি সেবা প্রকাশ করা ইন্টারনেটে নতুন প্রবেশবিন্দু তৈরি করে। এটি কোনো পিয়ারকে VPN সদস্যপদ দেওয়ার সমান নয়, কারণ দর্শনার্থী কখনো টানেলে যোগ দেয় না এবং গেটওয়ে ব্যাকএন্ডের পাবলিক মুখ হয়ে ওঠে। এই পার্থক্যই নিয়মের শ্রোতা ও তার সার্টিফিকেট নির্ধারণ করে।

প্রশাসনিক ইন্টারফেস খুব কমই ওই জায়গায় থাকে। অনুমোদিত VPN ক্লায়েন্টরা যে অ্যাডমিন পৃষ্ঠায় পৌঁছায়, তা আক্রমণ-তল টানেলের ভেতরে রাখে এবং লগইন ফর্মকে এলোমেলো স্ক্যানিংয়ের সামনে না ফেলে। পাবলিক অ্যাপ্লিকেশন এন্ডপয়েন্টের এখনো নিজের TLS সার্টিফিকেট, প্রমাণীকরণ ও রেট লিমিটিং দরকার; এনক্রিপ্টেড WireGuard হপ দর্শনার্থীর গেটওয়ে পর্যন্ত অংশটি রক্ষা করে না।

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

এক পোর্ট ভেতরে, এক ব্যাকএন্ড বাইরে

একটি পাবলিক পোর্ট ও একটি ব্যাকএন্ড সেবা ব্যবহার করুন। এই উদাহরণে eth0 পাবলিক ঠিকানা 198.51.100.20 বহন করে, গেটওয়ের টানেল ঠিকানা 10.200.0.1, আর পিয়ার অ্যাপ্লিকেশনটি 10.200.0.7-এ চালায়। পাবলিক TCP 9443 পিয়ারের TCP 8443-এ ম্যাপ হয়:

iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1

SNAT নিয়মটি অনূদিত ব্যাকএন্ড ও মূল পাবলিক গন্তব্যের সঙ্গে মেলে, তাই একই ব্যাকএন্ড সেবায় অন্য সংযোগ এই ম্যাপিংয়ের বাইরে থাকে। এটি দর্শনার্থীর ঠিকানা পিয়ার থেকে লুকায়, আর এই বিনিময়ই উৎস-সংরক্ষণকারী রাউটেড ফেরতকে আলাদা নকশা করে তোলে। iptables এক্সটেনশন রেফারেন্স উভয় টার্গেট ও তাদের মেলানোর অপশন নথিভুক্ত করে।

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

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

গেটওয়ের নিজের লিসেনার নিয়মের বাইরে রাখুন

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

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

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

প্রশস্ত TCP ও UDP ফরোয়ার্ডও সব প্রোটোকল নয়। ICMP, IPv6, পাথ-MTU ফিডব্যাক এবং বাইরের VPN ট্রান্সপোর্টের নিজস্ব নীতি দরকার, আর TCP ও UDP কভার করা নিয়ম সেই ক্ষেত্রগুলো ডিফল্ট চেইনের হাতে ছেড়ে দেয়।

নিয়ম লেখার আগে মডেল বেছে নিন

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

ModelWhat it protectsCostUse when
Narrow port forwardEvery other listener, including the VPNOne rule per serviceFew services, stable ports
Catch-all with reserved portsPorts named in the exception listRule order becomes criticalMany services and disciplined review
Separate public addressControl address fully isolatedProvider must supply the addressHigh-value publication
VPN-only accessNo public entry at allVisitors need the tunnelAdmin interfaces and internal tools

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

প্রকাশনা ও কন্ট্রোল পাথ—দুটোই প্রমাণ করুন

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

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

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