সাইট-টু-সাইট VPN-এ দ্বিতীয় সাবনেট যোগ করা: দুই পথ
পলিসি-ভিত্তিক টানেলে দুই পাশে মিলে যাওয়া সিলেক্টর লাগে; রুট-ভিত্তিক টানেলে রুট লাগে। সঠিক পথ বেছে নিন এবং আগে ফেরার রুট ঠিক করুন।
কর্মক্ষম সাইট-টু-সাইট টানেলে দ্বিতীয় সাবনেট যোগ করতে এক ডিজাইনে পাঁচ মিনিট লাগে, অন্যটিতে প্রায় গোটা বিকেল। টানেল যখন আপনার নাম দেওয়া প্রিফিক্সের জন্য রুট ইনস্টল করে, তখন আপনি একটি রুট যোগ করেন এবং ট্রাফিক তা অনুসরণ করে। যখন এটি একটি নির্দিষ্ট সিলেক্টর জোড়া নিয়ে দরকষাকষি করে, তখন নতুন প্রিফিক্স দুই পাশে মিলে যাওয়া জোড়ায় সম্মত না হওয়া পর্যন্ত অসুরক্ষিত থাকে। তিনটি বিষয় ঠিক করে আপনি কোন অবস্থায় আছেন: প্রতিটি পাশের কনফিগারেশন আসলে কী বর্ণনা করে, দরকষাকষি করা ট্রাফিক ক্ষুদ্রতম মিলে যাওয়া জোড়ায় সংকুচিত হয় কি না, এবং নতুন রেঞ্জের ফেরার পথ কার।
স্ট্যাটাস লেবেল নয়, কার্নেল পড়ুন
সংযুক্ত বলে জানানো টানেল অন্তত একটি সন্তান সংযোগ ইনস্টল করেছে, তবে আপনি যা ভাবেন তা নয়। Linux-এ কার্নেল কী প্রয়োগ হয় দেখায়: ip xfrm policy সিলেক্টর জোড়াগুলো তালিকাভুক্ত করে, আর swanctl --list-sas (বা পুরোনো ipsec statusall) দুই পাশ কী সম্মত হয়েছে দেখায়, প্রতিটি দিকে ট্রাফিক সিলেক্টরসহ। নতুন প্রিফিক্স দুটির কোনোটিতেই না থাকলে, কনফিগ ফাইল যা-ই বলুক, এটি অসুরক্ষিত।
এটিকে রুট টেবিলের সঙ্গে তুলনা করুন। রুট-ভিত্তিক ব্যবস্থায় টানেল ডিভাইস সুরক্ষিত প্রিফিক্সের পরবর্তী হপ। পলিসি-ভিত্তিক ব্যবস্থায় প্রায়ই দূরের সাবনেটের জন্য নির্দিষ্ট রুট থাকে না, শুধু ডিফল্ট রুট, কারণ টেবিল নয়, পলিসি ট্রাফিক বেছে নেয়।
পলিসি-ভিত্তিক টানেল: দুই পাশেই নতুন প্রিফিক্স থাকতে হবে
strongSwan-এর ভাষায় সিলেক্টর থাকে সন্তান কনফিগের local_ts ও remote_ts-এ, leftsubnet ও rightsubnet-এর উত্তরসূরি। নতুন প্রিফিক্স দুই পাশে আয়নার মতো দেখা যেতে হবে: সাইট A যা স্থানীয় বলে, সাইট B তা দূর বলে। অমিল rarely পরিষ্কার ত্রুটি দেয়। পাশ দুটি ছেদে সংকুচিত হয়, পুরোনো প্রিফিক্স চলতে থাকে, নতুনটি নীরবে ব্যর্থ হয়।
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policypfSense বা OPNsense-এ এর অর্থ নতুন স্থানীয় সাবনেটকে নতুন দূরের সাবনেটের সঙ্গে জোড়া দেওয়া দ্বিতীয় Phase 2 এন্ট্রি, তারপর প্রয়োগ। পুরোনো এন্ট্রি রাখুন; প্রতিস্থাপন করলে মূল সাবনেট যোগ না হয়ে সরে যায়। যদি বিদ্যমান Phase 2 ইতিমধ্যে 0.0.0.0/0-এর মতো সুপারনেট বা সারাংশ রেঞ্জ ঢাকে, তবে পাশে সরু এন্ট্রি দেবেন না: ওভারল্যাপিং সিলেক্টর প্রতিদ্বন্দ্বী পলিসি বসায়, আর মূল্যায়নের ক্রম নির্ধারণ করে কে জিতবে।
IKEv1 প্রতিটি সাবনেট জোড়াকে নিজের Phase 2 করে, আর প্রতি বিনিময়ে একটি জোড়া নেওয়া পাশ বাকিগুলো ফেলে দেয়। IKEv2 একটি সন্তানে একাধিক সিলেক্টর জোড়া বহন করতে পারে, তবে দুই বাস্তবায়নই মানলেই। swanctl --list-sas থেকে পাওয়া তালিকা সত্য; আপনি যা লিখেছেন তা অনুরোধ।
রুট-ভিত্তিক টানেল: রুটই পলিসি
XFRM ইন্টারফেস বা VTI ডিভাইস রুট টেবিল অনুযায়ী ট্রাফিক বহন করে। নতুন প্রিফিক্স দুই সাইটে ডিভাইসের দিকে নির্দেশ করুন, এবং ইন্টারফেসের রূপান্তরের সঙ্গে বাঁধা অবস্থা প্রয়োগ হয়। মেলানোর জন্য সিলেক্টর জোড়া নেই, তাই সাবনেট বাড়লে এই ডিজাইন ভালো স্কেল করে। strongSwan ফরওয়ার্ডিং গাইড এর কার্নেল দিক বিস্তারিত ব্যাখ্যা করে।
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard একই ধারণা আরও এগিয়ে নেয়। AllowedIPs একই সঙ্গে ক্রিপ্টো অনুমতি তালিকা এবং wg-quick-এর মাধ্যমে রুট টেবিল এন্ট্রি। এক পাশেই প্রিফিক্স দিলে হ্যান্ডশেক, বহির্গামী প্যাকেট আর নীরবতা পাবেন, কারণ দূরের পাশ সেই প্যাকেট ফেলে দেয় যার উৎস তার অনুমতি তালিকায় নেই। wg set রূপটি গোটা তালিকা প্রতিস্থাপন করে, তাই আগে চলা প্রিফিক্সগুলো আবার লিখুন, নইলে সেগুলো কেটে ফেলবেন:
wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0wg-quick-এর বদলে wg set ব্যবহার করলে সেই দ্বিতীয় কমান্ড ঐচ্ছিক নয়। কার্নেল নতুন অনুমতি তালিকা সঙ্গে সঙ্গে মানে, কিন্তু কেউ তার জন্য রুট যোগ করে না, তাই স্থানীয়ভাবে তৈরি ট্রাফিক এখনও ডিফল্ট গেটওয়ে দিয়ে বেরোয়। নতুন WireGuard সাবনেট টানেল হোস্ট থেকে চললেও ল্যাপটপ থেকে না চলার সবচেয়ে সাধারণ কারণ এটি।
ফেরার পথ টানেলের চেয়ে বেশি বার ব্যর্থ হয়
নতুন দূরের সাবনেটের হোস্টগুলোকে উত্তর VPN গেটওয়ে দিয়ে ফেরত পাঠাতে হবে। যখন সেই গেটওয়ে তাদের ডিফল্ট রাউটার নয়, উত্তরটি LAN রাউটারে যায়, যা হয় ফেলে দেয় নয়তো ব্যক্তিগত উৎস ঠিকানা দিয়ে ইন্টারনেটে পাঠায়। গেটওয়ে থেকে নয়, দূরের পাশের হোস্ট থেকে পরীক্ষা করুন: Linux-এ ip route get 10.30.20.15 বা PowerShell-এ Find-NetRoute -RemoteIPAddress 10.30.20.15 হোস্ট সত্যিই যে পরবর্তী হপ ব্যবহার করবে তা দেখায়। উত্তরটি টানেলের প্রান্ত না হলে, সেখানে নতুন প্রিফিক্সের জন্য স্থির রুট যোগ করুন।
ফেরার রুট নেই এমন সাইটে সোর্স NAT বৈধ বিকল্প, এবং বহু hub-and-spoke স্থাপনা এভাবেই প্রতিটি সার্ভার স্পর্শ করা এড়ায়। গন্তব্যের দিকের গেটওয়েতেও নতুন প্রিফিক্সে এটি প্রয়োগ করুন:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEখরচ সত্যি। দূরের লগ ব্যক্তিগত উৎস ঠিকানা দেখানো বন্ধ করে, আর মূল সাবনেটের ভিত্তিতে লেখা ফায়ারওয়াল নিয়ম গেটওয়ের জন্য একটিমাত্র নিয়মে মিলিয়ে যায়। রুট না থাকার কারণে নয়, সচেতনভাবে এটি বেছে নিন।
ফায়ারওয়াল ফেরার পথের অন্য অর্ধেক। জোন-ভিত্তিক ডিভাইস বিদ্যমান টানেল ইন্টারফেসের জোন নতুন সাবনেটে স্বয়ংক্রিয়ভাবে বাড়ায় না, এবং পুরোনো প্রিফিক্সের জন্য লেখা নিয়ম মিলবে না। IPsec-কে দোষ দেওয়ার আগে নতুন সাবনেট জোনে বা দুই দিকের নিয়ম জোড়ায় যোগ করুন।
তিনটি প্রশ্নে সিদ্ধান্ত নিন, তারপর ট্রাফিক দিয়ে যাচাই করুন
সংক্ষিপ্ত রূপ: পাশের কনফিগারেশন কি প্রিফিক্সের নাম নেয় (পলিসি-ভিত্তিক), নাকি ট্রাফিক ইন্টারফেসে রুট হয় (রুট-ভিত্তিক)? দুই প্রান্তই কী নতুন প্রিফিক্স তালিকাভুক্ত করে? নতুন সাবনেট থেকে মূল উৎস রেঞ্জে ফেরার পথ আছে কি?
| Tunnel style | Where the prefix goes | What breaks if you skip it |
|---|---|---|
| Policy-based IPsec | Selector pair on both peers | Old subnets work, the new one fails with no clear error |
| Route-based XFRM or VTI | Route into the device on both sites | Packets routed but not transformed, or the state never matches |
| WireGuard | AllowedIPs on both peers plus a route | Handshake succeeds, replies are dropped |
| Overlapping supernet | Adjust the existing entry instead | A shadowed policy wins or loses by evaluation order |
যাচাই সেই জায়গা যেখানে বেশিরভাগ পরিবর্তন খুব আগে বন্ধ হয়। গেটওয়ে থেকে পিং কম প্রমাণ করে, কারণ গেটওয়ে নিজের থেকেই উৎস নেয় এবং প্রায়ই হোস্টের চেয়ে ভিন্ন পলিসিতে মেলে। নতুন সাবনেটের হোস্ট থেকে পিং করুন, তারপর যে অ্যাপ্লিকেশন পরিবর্তনটি দাবি করেছিল তা চালান, আর স্ট্যাটাস আইকন নয় কাউন্টার দেখুন।
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showপলিসি-ভিত্তিক টানেলে ip xfrm state-এর কাউন্টার দুই দিকে বাড়া উচিত; সমান কাউন্টার মানে প্যাকেট রুট হয়েছে কিন্তু নির্বাচিত হয়নি। WireGuard-এ wg show প্রতি পাশের স্থানান্তর দেখায়, আর শূন্য গ্রহণ করা বাইটের হ্যান্ডশেক দূরের পাশের অনুমতি তালিকা বা তার ফেরার রুটের দিকে ইঙ্গিত করে।
প্রিফিক্স, পাশের সিলেক্টর বা রুট, ফেরার পথের সিদ্ধান্ত এবং ফায়ারওয়াল এন্ট্রি বাকি টানেল তালিকার সঙ্গে লিখে শেষ করুন। তারপর একটি গেটওয়ে রিবুট করে আবার পরীক্ষা করুন: হাতে যোগ করা রুট হারিয়ে যায়, আর পরের মানুষকে তা আবার আবিষ্কার করতে হবে না।